AnsweredAssumed Answered

Activiti transaction commit time

Question asked by lmollea on Apr 15, 2014
Latest reply on Apr 22, 2014 by jbarrez
Hi all.

Has anyone experienced processes becoming stuck due to missed signals caused by Activiti engine write times? If yes, any suggestion on how to handle this situation at best?

Scenario is this: we have process that is in a wait state (user task or signal catch handler). This process gets woken up, execute a Java Service task, moves to another wait state (another signal handler) where it will wait for an external signal (say received via a JMS message).

What is happening is that the Java Service task calls a remote service who will then send the JMS message back that will wake up the process. We're experiencing that after the task is executed, Activiti is updating the various tables (execution, history, …) but the remote service may be way faster (not the normal case but some edge cases that can happen) and the Process Engine receves the response message before Activiti has committed the first transaction and thus the process is not woken up again.
We solved calling signalProcess and not signalProcessAsync and forcing one message read from the JMS queue at a time. This is a bit dangerous as it serializes all our operations creating latencies in processing messages (something that is not currently an issue but that it's undesirable).
Plus this forces us to go single-instance as clustering the process engine would simply create again the issue if JMS messages are round-robin'd among the instances.

We're talking about times in the range of 100ms here. Activiti takes about 100ms to commit the transaction while the remote service sends the reply message in about 30-50ms. Transaction is not committed so the JMS message sees the "old" state in the database and misses the process waiting on the new signal.

First thing that comes to mind is that Activiti seems issuing a query at a time to the database, effectively losing time for all the round trips. On an average, it's issuing about 20 queries (or more) and thus losing approx 3ms per query in round trips. Can't say if ibatis can use batched queries (not much experience about it), but could be interesting if it could, so that those times will be reduced. This doesn't eliminate the issue but will lower much more the time window (and the chance) in which this could happen.

Besides, I'd like to know if there may be a better way to handle this delicate issue without serializing processing like we did.