Ive been playing with timer interrupting event subprocesses and I noticed the following interesting behaviours;
Consider the following process model;
The second process is just a way to simulate a blocking REST API, it basically sleeps for 60s. It is initiated via the master process making a REST API call. The interrupting subprocess is set to trigger after 10s and the maxWait in the job executor is set to 10s so the timer agressively fires…
Behaviour 1 - As it stands, the timer will never fire as its never persisted to the database. The main proces has no async continuations, hence at run time, the process insatnce is only flushed to the database at process completion. Hence there is not timer job in the database for the job executor to acquire.
Behaviour 2 - Ok lets make the Call Blocked task async before such that process instance state is flushed to the database. The behaviour is suprising. Once again the interrupting time does not fire. I suspect the reason why is because by default, the async continuation is set to exclusive. Thus whilst the blocked thread is running, the job executor aquisition thread will not acquire the timer job as this will violate the exclusive flag.
Behaviour 3 - OK lets make the async Call Blocked task non-exclusive. In this case, I expect the interrupt timer to occur, possibly resulting in an optimistic locking exception when the main call thread returns from its blocked state. Rather than an optimistic locking exception, I get a null pointer exception! (I suspect this is a bug…). In addition, the cockpit history looks fine and there are no incidents logged!
Behaviour 4 - Ok, so now let me make the main end event async before in case the null pointer is a manifestation of an optimistic locking exception. In this case I get a referential integrity exception trying to insert a variable into the ACT_RU_VARIABLE table (I suspect this is a bug?)
Hence interesting behaviour, I have attached the sample process model configured for behaviour 4…
Blockee.bpmn (12.5 KB)