AnsweredAssumed Answered

Camel tasks and Concurrency issues

Question asked by brianok on Dec 10, 2013
Latest reply on Jul 21, 2014 by karl.berger
Hi all,

I am using the Camel tasks heavily in a proof of concept for a workflow solution and I have a couple issues that I would like to know if there are best practices in Activiti for overcoming.

1.  The Apache Camel engine does not seem to deal well with asychronous operations.  For example, I have a process that writes to a JMS queue (via Camel task) and then listens for a response from a second queue ("InOnly" in Camel terms).  I had to essentially modify my Camel route to write the Activiti Process ID into the message being sent to the queue, and then query it out when it returns and set the PROCESS_ID_PROPERTY.  This is because out of the box the Camel task seems to just set a Camel Route Property that contains the Process ID.  As a result, when it receives the message, the original property is out of scope and it cannot determine which process the return message correlated to.  I suspect this is a necessity based upon the documentation about having to perform your own correlation with signaling, but it is a tough case to make when that type of functionality is integrated into something like Oracle BPM.

2.  Apache Camel tasks do not seem to deal well with concurrent operations (whether multiple engines or in non-sequential loops).  Based upon other threads in this forum, and inspecting the code, I suspect the issue is that org.activiti.camel.ActivitiProducer.signal(ActivitiProducer.java:95) is not wrapped in a try/catch block that can recover from org.activiti.engine.ActivitiOptimisticLockingException.  As a result, it causes the Camel Route to crash and the message is lost.  I know one workaround is to make the route transactional and having the JMS listeners pick it up again, but it seems that given other advice in this forum, this should be able to be handled by the ActivitiProducer component.  Am I missing something?

Thanks,

Brian

Outcomes