topic Re: Async send receive tasks in Alfresco Archive

Async send receive tasks

ghollins — Fri, 27 Sep 2013 15:41:51 GMT

Hi,I read the post at: http://bpmn20inaction.blogspot.com/2012/12/implement-parallel-execution-in-activiti.html.This is a great post, and I was able to figure this out and implement it. We are evaluating jBPM and Activiti as potential solutions right now. I really like Activiti, but in this "true pa

Re: Async send receive tasks

trademak — Mon, 30 Sep 2013 10:01:09 GMT

Yes, we could definitely implement something similar. It's only not considered a best practice in most application servers to start creating new threads yourself like this. But I can understand that sometimes this kind of logic could be helpful. Could you create a JIRA for this?

Thanks,

Re: Async send receive tasks

ghollins — Mon, 30 Sep 2013 17:38:16 GMT

Hi Tijs,

Thanks for your response. I created ACT-1800 for this (I filed it as a "New Feature").

I got to thinking though, and perhaps there is a way to do this (only use a single node) with camel routes.
In the blog example routes are created that look something like:

++++++++++++++
from("activitiarallelProcessTest:servicetask1?copyVariablesToProperties=true").setHeader("destination", constant("activitiarallelProcessTest:receivetask1")).to("seda:asyncQueue1a");

from("seda:asyncQueue1a?concurrentConsumers=100").to("bean:longTask?method=runLongTask(10000)").to("seda:receiveQueue1");

from("seda:receiveQueue1").recipientList(header("destination"));
+++++++++++++++

However, maybe what I want could be accomplished by allowing the "destination" to be set to the next node in the flow, regardless of what node type it is. In other words, the next node could be a gateway or a another task node… This way you wouldn't have to create another receive node. I tried setting the destination to a gateway to bypass creating the receive node, but that didn't work… Can you think of a way to forward to a non-receive node type like I described?

++++++++++++

I do agree that it's not the best practice to start creating new threads. If when this is implemented, there was a way to decouple via message queues, and have a message consumer be the point that essentially triggers the "WorkItemManager.completeWorkItem" call, then that would avoid the spinning up a many active threads. In other words a thread would be briefly created that puts a message in the queue, but it would almost instantly be destroyed. Then a message consumer (perhaps a fixed pool of listener threads) would be waiting for the "workCompleted" message, which would then notify the engine…

Re: Async send receive tasks

trademak — Fri, 04 Oct 2013 09:50:00 GMT

I agree that a single element in the BPMN process definition would be better than what we have now. But that would also be the solution I'm thinking of. We should introduce an enhanced camel service task that waits for the response to come back from Camel. So pretty much a combined service and receive task.

Best regards,

Re: Async send receive tasks

ghollins — Mon, 14 Oct 2013 15:33:53 GMT

Hi Tijs,

Yes, the enhanced camel service task sounds like a good idea. Do you know how far ahead in Activiti's roadmap that might be?

Thanks

Re: Async send receive tasks

trademak — Mon, 21 Oct 2013 14:22:52 GMT

We just released 5.14, so I'm thinking of 5.15. Could you create a JIRA issue for this?

Best regards,

Re: Async send receive tasks

ghollins — Mon, 28 Oct 2013 23:42:30 GMT

Hi Tijs,

I previously created this JIRA issue:

http://jira.codehaus.org/browse/ACT-1800

It references this forum post in the description.

Thanks!

Re: Async send receive tasks

smirzai — Tue, 21 Oct 2014 13:28:45 GMT

The Jira and discussions on the topic do not match. In forum a camel task is discussed but in Jira there is no notion of Camel.

Re: Async send receive tasks

smirzai — Tue, 21 Oct 2014 13:33:08 GMT

I remember from this discussion that we do not want to block the user thrad to wait for something.
http://forums.activiti.org/content/start-process-synchronously-and-return-results-back

Otherwise I am eager to implement that part. We and I guess many others desperately need it.
It will also help camel component to return values back to camel more elegantly.