Igor, I had been travelling and could not answer your question earlier.
Process author has the control to define the timeout within the process using the onAlarm in EventHandler or Pick activities. Processes can be long running without a time bound Async processes. Sync processes are expected to return a response and hence the engine uses the mex.timeout which defaults to 2minutes and this is configurable. In what scenario is the process continue executing after a failure and what failure is it? One scenario that comes to my mind is this could happen when the transport channel in the IL will timeout (probably due to the SO_TIMEOUT) but since the mex.timeout is 2min the process will continue. In case if the customer has deployed a process with infinite loop, one could use the PMAPI terminate(kill) or suspend function to kill or temporarily suspend the execution of that instance, there is no need for restarting the server. There is also a check for processes which continue processing for a long time at one go https://github.com/apache/ode/blob/ode-1.3.x/bpel-runtime/src/main/java/org/apache/ode/bpel/engine/BpelRuntimeContextImpl.java#L977 Seems like _maxReductionTimeMs is not configurable. We can make it configurable. regards, sathwik On Fri, Feb 5, 2016 at 6:13 PM, Igor Vorobiov <igorvorobio...@gmail.com> wrote: > Can we configure process execution timeout? > I noticed that there is mex.timeout property but it is used for sync > processes to reply with failure response but process still executing after > that. We need to terminate process execution after timeout is reached for > sync and async processes. > There is following reason to terminate process: > Our product allows different users to develop and deploy processes that > are running on the same application server. There are situations when user > developed process and there is some condition causes infinite loop. If this > process is called once it will never be ended. Even when customer > understood > his mistake and redeployed fixed process we need to restart server in this > case any way. We have also onDemand environments where there are a lot of > users that deploy their process apps and there is no guaranty that some of > them will not make a mistake. This timeout can be configured by customers > according to their needs. If they know that there is some long running > process(it is not recommended) then they can increase timeout. And if > process fails due to timeout error it will be in the log and we can easily > detect this process and fix it. In this case we don't need to restart > server. > > > > -- > View this message in context: > http://apache-ode.996305.n3.nabble.com/Process-execution-timeout-tp18072.html > Sent from the Apache Ode Dev mailing list archive at Nabble.com. >
