Workflows terminated: message submission rate

asked on July 17, 2015

We have occasional issues where multiple workflow instances which send an email might be kicked off close together. When this happens, we sometimes see some of those instances terminating, and returning an error of: "Service not available, closing transmission channel. The server response was: 4.4.2 Message submission rate for this client has exceeded the configured limit."

We have tried to find what might be throttling the ability to send multiple emails in a short span of time, but so far all of the settings appear to be ok. In the meantime, I have found a workaround, by setting up a Task Error Handler on the WF Admin Console.

I am looking for some information regarding the below items:

1 - Does anyone have a suggestion as to what might be causing the error in the first place and how to correct it?

2 - I have that Task Error Handler set up currently with just the Error Message, as there is not an Error Code or Type being reported. Does it hurt to just have the Message, or can someone point me to the proper Code/Type?

Thank you for your help.

0 0

SELECTED ANSWER

replied on July 17, 2015

You could look into whether your particular mail server allows you to customize the rate for individual accounts. It's not an error per se, it's a feature on the mail server to protect it from being used for spamming . Beyond that the task error handler is the way to go, there's no need for an error code or type. They're there to allow filtering between similar messages from different sources. But it's unlikely you'll get this exact message from anything other than the mail servers.

0 0

View 2 previous replies

replied on April 18, 2018

Hi We have a similar scenario with our email activities causing the Workflow to Terminate. the error code is just slightly different to the one mentioned in the original post. We actually have 2 separate ones that have been occurring in the past 2 weeks.

"Service not available, closing transmission channel. The server response was: 4.4.1 Connection timed out. Total session duration:"

"Error in processing. The server response was: 4.7.0 Timeout waiting for client input"

My question however is around the setup of the message in the Task Handler as it does not seem to work as expected. The Workflow is not retrying the activity, and fails after the first encounter of the error.

Seeing as the first connection time out error contains a duration that might vary, would it work to ad the message with wildcards like follows:

"*4.4.1 Connection timed out*" and then same with the second error?

Current Configuration looks like this:

Any suggestions would be appreciated.

0 0

replied on April 18, 2018

Partial matches are not supported. Just add separate handlers for each one.

0 0

replied on April 19, 2018

Hi Miruna,

Thank you for the feedback however I don't think this will work in our case. Here is the entire message being reported on Workflow:

Service not available, closing transmission channel. The server response was: 4.4.1 Connection timed out. Total session duration: 00:10:40.3573917

As you can see there is time stamp in min and seconds. This will be near to impossibly to go and create a message to cater for every possibly nanosecond that the message could contain.

Is there no other way in which we can handle these failures to get the Workflow to retry the activity? I know the option exists to add Try catch steps around the email activity, but considering we have more than 80 potential workflows with anything from 1-6 different type of email notification steps, this does not seem to be a option we would be able to change and role out that quickly.

In discussions with our Exchange Administrator, he confirmed that the error comes from the Exchange server that has a default setting of closing a open connection after being open for 10 min. So for instance Workflow would send the first mail, creating the open connection. any subsequent workflow that needs to send another email in the 10 min time period would use the same connection as it comes from the same server. After 10 min the connection is closed however irrespective if anything was still transmitting. Laserfiche is the only application in our environment that does not have a native built in retry mechanism when it comes to sending emails. all the other supported applications retry by default, and they do not sit with the same failures we do on the workflow side.

0 0

replied on April 19, 2018

Workflow does have a built-in retry mechanism because there is a default task error handler for SMTP exceptions. It is, however, set to match both on exception type (SMTPException) and message ("The operation has timed out."). You can take out the message and it will retry on all SMTP errors. Or we can look at the stack trace for the error message for more information and tailor a new handler more appropriately.

0 0

replied on April 20, 2018

Thanks for the feedback Miruna,

I have done as suggested and will monitor over the next couple of days to see if there is any improvement and will revert.

0 0

Question

Question

Workflows terminated: message submission rate

Answer

Replies

Sign in to reply to this post.