Running multiple JBPM engines

[michaelholtzman]

Greetings. We are running JBPM as a stand-alone Java application to handle the workflow requirements of our system. We would like to run multiple instances of the JBPM engine, and assign each process definition to run on a specific JBPM engine.

We assume there will be no Hibernate caching issues, since each process instance always refers back to the same JBPM engine.

Are there any problems with this scheme?

[jits_1998]

Hi Micheal,

I am not a hibernate expert, but based on my knowledge of jbpm and doing some debugging on it, here is my view.

I see a lot of performance issues owing to a large number of threads created by ehcache in hibernate. Also having multiple CommandExecutorThread will be taxing on the system.

Could you elaborate on why would you not want the same engine to handle multiple process definitions... according to some other post in the forum jbpm can handle about 100,000 transactions in a day on a simple laptop.

[michaelholtzman]

Our bigger clients will easily exceed that 100,000 transactions per day benchmark, so we are looking at ways to increase capacity. One strategy is to partition the process definitions across multiple BPM engines.

[jits_1998]

How about clustering....

I beleive jbpm will support clustering.

If someone from jboss can answer this it will help me too, as we are probably going to need some clustering ourselves.

[koen.aers]

Partitioning process definitions across multiple jBPM databases is a viable option. Clustering is also a possibility. You can use clustering by encapsulating the jBPM API calls that you need in your application in a stateless session bean and cluster this last one.

Regards,
Koen

[michaelholtzman]

For those who are following this thread ...

We hit a snag in the multiple JBPM engine scheme: timers.

In our original implementation, we started multiple jbpm applications (using the same JBPM_xxxx database tables) and assigned each process definition to a particular jbpm service (instance of our app). This worked well, except for process instances that use timers. Every jbpm service was firing every scheduled event.

We solved this by extending the scheduler thread class, and checking to see if the process instance associated with the current timer event was assigned to the current jbpm service before firing the event. Ah, joy.

Regards,
Mike H