Hola,
With years of detailed experience in jBPM, including the BPMN parts of jBPM4, I made the switch to using Activiti. In the company I currently work for, I convinced people to do a proof-of-concept with Activiti. The most important initial tests will be 'crash restistency' regarding transactions in the db, including crashing the db etc… Since I'm convinced this will succeed (maybe after some small patches), I'm already focussing on additional functionality that we need. Some of it is on the roadmap and I hope/think we can contribute in realizing this earlier or offloading some work for Joram as it seems (see below) or maybe he can focus on more complex things like boundary events (like ACT-15 we want those as well ;-)) and Tom on ACT-32
Foreach: parallel execution based on variable collection or expression-return-value collection (5.2, Joram).
I've already implemented something for this (only for tasks). It might not be how you should do it, since I just needed something to work for demonstrations, but I'm happy to make the required changes
EJB invoke (5.3,Joram)
The same as for the previous item
Asynchronous continuations ACT-126 (5.5, Tom)
The same as for the previous to items 🙂
JobExecutor
In addition to the previous requirements, I've made some changes to the way the JobExecutor works. This improves the troughput of the Async jobs by 30%, because of a lot less queries to the db if used in a high volume STP kind of way. What effectively happens is that jobs are put in the db, directly pinned to the server they are created on and put in the threadpool (if there is room). This way job acquisition is normally not needed for async functionality and only if the queue was full. Still then, retrieving them is not in a competing way since they are already pinned. Not even when failover is taking place since we changed that way failover works as well. Servers are registerthemselves in the db and update a record there notifying that they are alive. The combination of changes decreases possible issues when running multiple job executors on different machines since jobs are pinned in advance (I have not seen any problems at all!!!, so ACT-234 is probably not an issue anymore
We also added the option to have multiple queues so you can e.g. have a high-priority queue and a low priority one (or one per service). Pausing/Resuming is also added and behaviour to back-off if the queue becomes full. Configuring queue sizes, threads etc per queue is on the todo list, as well as extending Activiti Probe (if this is required).
I'm curious though what the ideas are behindACT-34, Refactor JobExecutor threading. We might take that into account if needed.
There still is the option though to have the current behaviour. It should only be made confirurable in the config (but I've learned those internals as well so that will not be a problem)
Expressions in timer duration ACT-429
Since I'm an expert on this from the jBPM era, I'm happy to contribute here as well since we need it to. No work has been done on it it yet (and certainly no documentation
)
'Dynamic Subproceses'
jBPM had the option to decide which subprocess you were going to call based on the value of process value. This is very interesting for us to. I've not realy seen a jira issue for this. The ones I did saw were about runtime created subprocesses, but that is not what we require. Thoughts?
Ok, this was the first post, expect more…
With years of detailed experience in jBPM, including the BPMN parts of jBPM4, I made the switch to using Activiti. In the company I currently work for, I convinced people to do a proof-of-concept with Activiti. The most important initial tests will be 'crash restistency' regarding transactions in the db, including crashing the db etc… Since I'm convinced this will succeed (maybe after some small patches), I'm already focussing on additional functionality that we need. Some of it is on the roadmap and I hope/think we can contribute in realizing this earlier or offloading some work for Joram as it seems (see below) or maybe he can focus on more complex things like boundary events (like ACT-15 we want those as well ;-)) and Tom on ACT-32
Foreach: parallel execution based on variable collection or expression-return-value collection (5.2, Joram).
I've already implemented something for this (only for tasks). It might not be how you should do it, since I just needed something to work for demonstrations, but I'm happy to make the required changes
EJB invoke (5.3,Joram)
The same as for the previous item
Asynchronous continuations ACT-126 (5.5, Tom)
The same as for the previous to items 🙂
JobExecutor
In addition to the previous requirements, I've made some changes to the way the JobExecutor works. This improves the troughput of the Async jobs by 30%, because of a lot less queries to the db if used in a high volume STP kind of way. What effectively happens is that jobs are put in the db, directly pinned to the server they are created on and put in the threadpool (if there is room). This way job acquisition is normally not needed for async functionality and only if the queue was full. Still then, retrieving them is not in a competing way since they are already pinned. Not even when failover is taking place since we changed that way failover works as well. Servers are registerthemselves in the db and update a record there notifying that they are alive. The combination of changes decreases possible issues when running multiple job executors on different machines since jobs are pinned in advance (I have not seen any problems at all!!!, so ACT-234 is probably not an issue anymore
We also added the option to have multiple queues so you can e.g. have a high-priority queue and a low priority one (or one per service). Pausing/Resuming is also added and behaviour to back-off if the queue becomes full. Configuring queue sizes, threads etc per queue is on the todo list, as well as extending Activiti Probe (if this is required).
I'm curious though what the ideas are behindACT-34, Refactor JobExecutor threading. We might take that into account if needed.
There still is the option though to have the current behaviour. It should only be made confirurable in the config (but I've learned those internals as well so that will not be a problem)
Expressions in timer duration ACT-429
Since I'm an expert on this from the jBPM era, I'm happy to contribute here as well since we need it to. No work has been done on it it yet (and certainly no documentation
)'Dynamic Subproceses'
jBPM had the option to decide which subprocess you were going to call based on the value of process value. This is very interesting for us to. I've not realy seen a jira issue for this. The ones I did saw were about runtime created subprocesses, but that is not what we require. Thoughts?
Ok, this was the first post, expect more…
