Email Receiver QPAC - On timeout property

[Former Community Member]

Hello,



Can anyone give a better explanation of what options for "On timeout" under the Retry tab of the Email Receiver QPAC. The documentation doesn't really explain what these happens. The options are Stall and Continue with Error.



I assume the stall does just stall the entire Workflow, but what about Continue with Error option. Does this attempt to continue to the next step in the work flow without receiving the email or does if an error occurs, does the workflow just stay at the Email Receiver?



The problem I am having is Connection timeouts. So, when I set On timeout to stall, of course my workflow would stall. When set On timeout to the Continue with Error option, the workflow did appear to stay at the Email Receiver QPAC, but it seemed to stop polling for emails.



I am trying to review the JBoss server.log file now to try and figure out what is going on (I set up the DEBUG per Howard's post on my other post), but it just looks like the Email Receiver stops polling for messages and I don't see any error upon a quick glance.



Thank you for any input.

-Jennifer

[HowardTreisman]

Hi Jennifer



"Stall" means that the QPAC will throw an exception, which will cause the workflow to stall. It will then show up on the "Stalled Actions" in the adminui. The only option you have is to retry the action, which will cause it to "start again from the beginning".



"Continue with Error" is perhaps a little poorly named. It really should just say "Continue". This means that if the timeout period is reached, the QPAC will just complete, which means that the workflow will continue on to the next action. (If there are multiple routes coming out of the QPAC, the first one that evaluates to true will be followed, as normal.)



The "Continue With Error" option is useful if you want the Workflow designer to be able to handle the error, rather than causing the workflow to stall. For example, if you were waiting for a customer to send a response to your outbound email, you might design the workflow to do something like the following:

- Wait for 2 days for a response email.

- If the two days elapse without receiving the response, send another email, then wait for another 2 days for a response email.

- If the additional 2 days elapse without receiving the response, assign a task to a customer support rep to call the customer to get the required information.



In short, Continue with error allows you to set a "soft" error - it's not an error that a System administrator needs to correct, it's just something that needs to be accomodated for in the workflow. A stall, on the other hand, is a "hard" error, that can only be rectified by a system administrator fixing the underlying problem and retrying.



I hope this explanation helps.



Howard

http://www.avoka.com



PS Technically, the "Continue with error" option does actually return an error code to the workflow engine, indicating exactly what the error is. However, the workflow engine does not expose this error code to the workflow design. This would be a useful feature which we hope may arrive in the next version.

[Former Community Member]

Thank you for the detailed explaination.



So, I understand now why in my first workflow - when I set Continue with Error and I look up in the adminui, the workflow remains at my Email Receiver, which is great. But, once the error occurs, my emails never get received again, even though the workflow appears. If I invoke the workflow a second time, those emails that were sent before are received.



I'm at a loss on what is happening and how to rectify this problem. I submitted something to support, but haven't heard back yet.



Maybe it will work in production better with different email servers, but I hate moving forward with this ongoing issue.



Thanks again,

Jennifer

[Former Community Member]

What is the length of time you tend to keep the "Retry every" set to?



I initially kept it blank (which I believe the default is every 60 second?). Then changed it to every 5 seconds, but then changed it back to 60 seconds. I wonder if I should set the "Retry every" to a few a minutes, possible descreasing the chances of the timeouts (although not so much fun in waiting to see is that works...).



Thanks,

Jennifer

[HowardTreisman]

Hi Jennifer

For testing, I would suggest something like:

- Retry every 1 minute

- Stall on error (that way you're find out exactly what errors are occcurring, if any)

- Timeout = -1 ... which means that it will keep trying forever until it gets something.



In production, the retry time is based on how many emails you receive, and how long you can afford to wait between checks, vs the amount of load you will place on the server checking for emails that aren't there. Every 5 seconds is probably too often, unless the volume of emails you're trying to process is very large - the server

will be spending a lot of time checking.



Hope this helps...

howard