Hi all
We have a few tasks that are run as continuous processing (multi-company direct and the like). When we moved to 10.2.200.6 a few months ago, they now time out after running for exactly 3 days and 9 hours.
There must be a setting somewhere controlling this, but I have yet to find it.
Can anybody direct me to where that might be?
Thanks
Marty
Startup schedule tasks should never be used if an interval schedule can be used. Not to say that continuous processing cannot be used or that this issue cannot be resolved, but, I would personally never use continuous, ever.
Found this out the hard way when backflush stopped working on a continuous schedule in 10.1.500.something or other. Changed it to an interval like you suggested here (which is short) and everything has worked perfectly. Did something change or has using continuous processing always been discouraged?
The following rant is my opinion and not that of my employer.
I am of a minority opinion on continuous processing among most developers and support people–c’est la vie.
https://goo.gl/kSRB1f
UNOFFICIALLY:
The reason I am outspoken and unabashedly against continuous processing is for one reason: if that process derps in an ungraceful/catastrophic failure kind of way (e.g. crazy .NET-y SQL-y error messages all over the process log), the only way to get that process working again is to restart the taskagent configuration–that takes down printing and background processing for things that are actually working. If you ask me, that is not ideal in a production environment if one actually worries about their users being able to do things like print all the time.
If that same process derps in ungraceful/catastrophic failure with an interval schedule, the next time that process is supposed to execute(as in, the next interval), more times than not it will process just fine–perhaps you might need to update/delete a specific ice.systask agent record maybe, but, still an order of magnitude more “self-healing” than continuous processing as there are corrections one can make without taking down the entire background processing side of the product.
If I had my druthers, we’d get rid of continuous processing altogether as a concept as it’s a carryover from the Progress OpenEdge days.
OFFICIALLY:
I love all the functions in our product equally, and all things have their place. I will never tell you not to use continuous process through a support case (as there is an audit trail and I’m not supposed to recommend changing schedule types from continuous to interval anymore–I’ve been spoken to about it 
). So, if you have issues with continuous, please let Support know and we’ll definitely dig into it.
I think I am going to start using that phrase. It makes me giggle… 
Makes sense, we haven’t had any issues using an interval.
MC in 10.2.400 continuous times out often. 
We have had the same issue, including 10.2.400. The only workaround is schedule these overnight on 30 minute intervals. Also, I think there is a bug in one of the connection protocols (UsernameSSL I believe) where it loses connections that is not documented well, that was addressed in Update #9.
We switched back to UserNameWindowsChannel, made the MC run on 30-minute intervals and things have not failed for weeks now.
Maybe the fix is INFINITE 
@tomdomurat thx for the info.
EDIT:
Infinite doesn’t work it limits you to 24hrs, its hard-coded in Epicor Hosting Dll. FYI
@JeffLeBert just an FYI that Epicor states in their help you can use Infinite for Continious processing task, but in your dll you overwrite it.
