Activiti/Activiti — pull request #126 by smirzai (2013-09-05 12:40:27+00:00)
Title: Sync camel

This pull request is for Camel integration component. The problem in current implementation is that all calls to activiti are synchronous. This creates some problems. Just to show the problem, consider AsyncProcessTest test case. In this test case, In this test case camel service task serviceTaskAsync1 starts a new route in camel. The next step is to recieve a signal in receive1 receive task.
Now the problem is that call to camel is synchron and activiti blocks in calling camel. Camel route wants to signal receieve1, but there it is not created yet.
As a workaround, Maciej had to change the route to add an unnecessary seda route, which is actually an asynch call. See
```java
from("activiti:asyncCamelProcess:serviceTaskAsync1").setHeader("destination", constant("activiti:asyncCamelProcess:receive1")).to("seda:asyncQueue");

from("seda:asyncQueue").to("bean:sleepBean?method=sleep").to("seda:receiveQueue");
```
the route finishes by calling "seda:receiveQueeu", activiti process continies and related recieve task is created. Now camel runs the rest in another thread and will see the related receive task.

Again to put the destination some where, he had to put the destination in header.

There is also another problem with this approach and that is timing. One should make sure that receive task is created before activiti reaches the signalling point. Here his problem does not happen, because of proper wait states. This is not always easy in real projects.

What I propose is to use already existing "asynch" property of camel service. something like:
```xml

```
now the call to camel is done asynchronous, and activiti process just continues after triggering camel route. Then there is no need for those cumbersome async calling and destination marking in route. The very same route then simplifies to :

```java
from("activiti:asyncCamelProcess:serviceTaskAsync1").to("activiti:asyncCamelProcess:receive1");
```

Now only timing problem remains. Just to reduce the risk of exact synchronization, now when you forward the route to a recieve task, it does not return immediately if the mentioned receive task does not exist. Now the signaler waits for a certain amount of time, and reties finding mentioned recieve task in specified time periods.
The timeout and resolution can be controlled by setting ACTIVITI_JOIN_TIMEOUT and ACTIVITI_JOIN_RESOLUTION camel properties. The default values are 5000 ms and 100 ms accordingly.
setting ACTIVITI_JOIN_TIMEOUT to 0, causes and execption to be thrown if the proper receive task cannot be found in first try, just like before.