jBPM thread control

[ali_feint]

Is it possible to control the maximum number of threads instantiated by jBPM?

I am looking at using jBPM to implement processes which incorporate automatic functions into the nodes, which then signal the BPM asynchronously when they are finshed.
But it is possible that there could be 100,000 processes running concurrently. Is there any way of controlling the max number of threads that are executed concurrently by jBPM?

Thanks

[icyjamie]

they are all "long-running" processes (jBpm is like a sophisticated state-machine). State is persisted and you can "wake" them up. So, they don't stay in memory.

[kukeltje]

Correct, and if you need to have long running actionhandlers, make them async by e.g. using jms and not put them on transitions

jbpm will support async functionality in the not to distant future

[ali_feint]

Putting the actionhandlers on transitions will not provide enough control for what I need to do.

Basically I need the nodes to represent tasks which will be carried out, not by users, but by other applications/components in our system. But I need to encapsulate more functionality than just running an actionhandler on a node, because it needs to be robust. I need to implement retry and timeout functionality for each application task, and also some other arbitrary logic to attempt to obtain resource locks before running the application task.
Anyway, I want to encapsulate this logic inside an action handler (away from jBPM engine), and implement my own async call back to kick the jBPM token into the next transition when task execution is finished.
So a state or node would represent a sub process, which encapsulates the logic above.

Anyway, supposing that 50,000 nodes or subprocesses all complete at the same time, then there are 50,000 call backs to the jBPM engine (by looking up a process instance and calling signal()), and 50,000 new action handler instances being called...
Of course I can stop this from happening by restricting the number of threads that are instantiated to call application tasks at one time, which will flow on to the number of call backs being received.

So unless I am missing something, it is not too hard to implement async functionality right now. So what exactly will be added in 3.1 (I read in other threads about async in 3.1)? When will 3.1 be released?

And is there any way of controlling the number of threads from jBPM, or will I need to implement this functionality myself?

Thanks

[kukeltje]

instead of limiting threads, try using jms for async functionality. That is what will be used in 3.1 as well.

As with many opensource projects, it will be released when it is ready ;-) see the roadmap in the jira for open issues. Those will give you an idea.

Implementing async stuff is not to difficult. As are all other small issues. If you have a fairly good knowledge of jms/async stuff and are ready for contributing something...., we are always open to good ideas.