I have jBPM 5.4 and I'm seeing that the amount of time it takes for jBPM on wildfly to burn through a bulk dump of workflows asynchronously is the same no matter what I change in the thread pool size of standalone.xml.
I'm afraid that how jBPM does this is via a fixed pool size. Can anyone confirm or deny this?
Disclaimer: I have not tried recently, this is from recollection of old project (where 6.0 was on the horizon, not used, but discussed), and refreshing my memories by checking the docs. Also I don't expect there is anything special to "workflows" here, the same principles should apply.
jBPM's engine is single-thread:
We've chosen to implement logical multi-threading using one thread: a jBPM process that includes logical multi-threading will only be executed in one technical thread.
For async tasks in v5 you have to handle the threading yourself, as shown in this example from the doc:
public class MyServiceTaskHandler implements WorkItemHandler {
public void executeWorkItem(WorkItem workItem, WorkItemManager manager) {
new Thread(new Runnable() {
public void run() {
// Do the heavy lifting here ...
}
}).start();
}
public void abortWorkItem(WorkItem workItem, WorkItemManager manager) {
}
}
My understanding is if you don't do that, your async tasks are just potentially async. And if you do that, you have no control on level of concurrency. So that's a terrible example, they should at least show how to use an ExecutorService or something reasonable.
Anyway, version 6 still has a single-thread core engine, but offers its own executor for async workloads:
In version 6, jBPM introduces new component called jbpm executor which provides quite advanced features for asynchronous execution. It delivers generic environment for background execution of commands.
Its internal threadpool can be configured with system property org.kie.executor.pool.size (mentioned at bottom of page linked above).