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("activiti
arallelProcessTest: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…
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("activiti
arallelProcessTest: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…
