Hi all,
I noticed that in some cases that an exception occurs the process is rerun three times, but in other cases the process is stopped and that’s it, without being retried.
Why in some service tasks it is retried 3 times and in others it is stopped and that’s it?
There is the same service task called two times named “Throw Exception” .
The first time when the exception is started the service task is not repeated 3 times. While the second time, the service task which is near the end, if it fails it is retried 3 times. The point is that it is the same service task, why the first time is not retried 3 times while the second time it?
Maybe because “in other cases” the call succeeded the second time? By default, each step is tried three times. If that still does not result in a success, an incident is created. The process state is rolled back to the last async point.
If a service task fails some times it is retried 3 times, in other cases the process is stopped and that’s it, without being retried.
Why in some service tasks it is retried 3 times and in others it is stopped and that’s it?Thanks
There is the same service task called two times named “Throw Exception” .
The first time when the exception is started the service task is not repeated 3 times. While the second time, the service task which is near the end, if it fails it is retried 3 times. The point is that it is the same service task, why the first time is not retried 3 times while the second time it?
Perhaps the first service call is running in the context of a client thread, the second in the context of a job executor thread. The job executor by default will retry 3 times (configurable)… If an exception is thrown in a client thread context, there is no retry strategy in place so the client receives the exception to deal with…
Check if in the process model there is an Async continuation before the second service task…
The jobexecutor has its own threadpool to run process executions. Consider timer. A client of the process engine does not trigger the timer, hence the jobexecutor reacts to the timer becoming due and allocates a thred to run the associated process execution. Hence we refer to these threads as backgroud threads. Now consider a client of the engine starting a new process instance. The start o he process instance execution will run in the context of what we call a client thread. This client thread wil continues to execute the process until either the process ends or a wait state is reached. A wait state can be a user task, a receive message task a receive event etc, in other words any task which needs to wait for something external to happen. It is also possible to mark tasks such as service tasks as asynchronous eg async before/after. Hence a service task marked as async will execute in the context of the jobexecutor or background thread.
You may need to examine all the upstream tasks to see if one of them is marked as async as this can effectively propagate through to the service task of interest. Another way is there is a modeller plugin which highlights transaction boundaries…
Yes the message receive creates an Async checkpoint. However, on message delivery, the process could run to completion in the message delivery or client thread. Hence looking for an asyc continuation on one of the preceding tasks…
Hmm I think I understand. Yesterday I said that there was no async before on message received on the gateway, but probably I had not reloaded the bmpn in the java resources folder and there was still the version with async before active, while on camunda modeler it was not async.
So, in summary, in case of timers or executions with async before / after, the execution of the process is fed to the JobExecutor where the 3 attempts rule applies.
