Camel tasks and Concurrency issues

[brianok]

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

[karl_berger]

Sorry to play thread necromancer, but I'm having the exact problem that brianok describes in his first point and would love to know what that workaround looks like.

The User Guide claims that "In starting every camel route, the Process Instance ID will be copied into a camel property with the specific name of "PROCESS_ID_PROPERTY". It is later used for correlating the process instance and camel route. Also it can be exploited in the Camel route. "
But that doesn't seem to be the case in my Activiti->Camel->ActiveMQ integration, or at least it isn't being put to use by Camel.  If I try to have an Camel task post to a queue followed by a Receive task, when the Camel route that receives from a "work done" queue and tries to reconnect to my instance I get a "Business Key is null" exception.  I looked in the Activiti/Camel code and it only even looks for the Business Key if it doesn't find PROCESS_ID_PROPERTY first.

Help!