News: jBPM Workflow Engine in a JBoss Cluster
Getting scalability with jBPM running on JBoss can require the use of clustered hardware. If you need to grow a jBPM configuration, Szymon Zeslawski explains in detail how to cluster jBPM efficiently - from cluster setup to fine-tuning jBPM configuration, and provides performance test results and various tips and tricks allowing to achieve maximum performance. Read article
- Posted by: Nuno Teixeira
- Posted on: March 10 2009 11:56 EDT
- link by dan oxlade on March 10 2009 17:28 EDT
- REPL_ASYNC for Entities? by Galder Zamarre??o on March 25 2009 18:03 EDT
- Re: jBPM Workflow Engine in a JBoss Cluster by Sarish Jain on June 06 2009 18:27 EDT
- jBPM Workflow Engine in a JBoss Cluster by Sowmya H N on September 25 2013 12:52 EDT
Is the link missing?
Szymon, in order to achieve a scalable system our team decided to tweak JBPM in another way: not to use a classic distributed cluster at all. We use a farm of non-clustered servers each with a local cache. Starting off a new job works in our case as the JBMP default by firing a JMS message away when there is a runnable job in the db. However, we tweaked asynchronous job execution in a process-instance that way, that it stucks on the local machine by using threads from a pool.
It would be nice to see workflow products ditch the database for storing and scheduling jobs. You can't scale up if the database doesn't, and no, I shouldn't have to buy Oracle.
I'm worried about the use of asynchronous replication for entity beans since it does not guarantee data consistency accross the clusters. Entities are not generally accessed on a sticky manner, hence, updates can happen in multiple nodes in parallel. Having REPL_ASYNC for entity cache means that you cannot guarantee the outcome of two parallel updates to the 2nd level cache coming from different nodes. You can get away with REPL_ASYNC in sticky scenarios such as http session replication where you can get a session to be accessed on a single node at the time and only use another node in a failure situation. You should be using REPL_SYNC for your 2nd level cache.
You are obviously right, it's typo, SYNC should be used for entities. Thanks for pointing this out. I'm just wondering whether INVALIDATION_SYNC would give better performance than REPL_SYNC? In my tests I couldn't show a significant difference...
First of all, excellent post. I am just curious to know one thing though, why you have used JobExecutor and not JMS based async job processing? Any insights into this decision, and advantages from performance perspective would be really helpful.?
I am new to jBPM and JBoss. I want to test scalability of jBPM so i want to set up a clustered environment. Can you please give me a detailed steps of how to set up the environment?