Clustering activiti BPMN
- Published: 26 December 2013
In this interview Activiti's project lead Tijs Rademakers discusses about best practices for running Activiti BPMN 2.0 solution as part of a cluster of application server nodes.
The Activiti BPM solution is a well adopted and consolidated solution in the Java EE arena. As most of the Enterprise applications running in production are configured to provide redundancy of services by means of cluster, I'd like to explore the capabilities of the Activiti framework in a cluster.
1) So, at first which is the recommended Activiti setup in a cluster ? (Shared database vs Multiple databases with data replication)
There’s no general recommended Activiti setup because this depends on a lot of different aspects and can change between use cases. When there’s a need to cluster multiple Activiti Engines, it’s often best to go for a shared database.
There’s one main component in Activiti that should be taken into account when clustering Activiti and that’s the Job Executor. The Job Executor performs timer logic and asynchronous activities in the Activiti Engine. The Job Executor can be disabled per Activiti Engine, which means that in a cluster of 3 Activiti Engines you could run the Job Executor on only one Activiti Engine. But running 3 Job Executors is supported out-of-the-box as well and a job will only be executed by one Job Executor with a locking strategy.
2) Is Activiti able to execute failover of processes ? Let's say for example that the first call hits the Activiti EngineB which will launch the process on NodeB of the cluster. Supposing for example that the process on EngineB is waiting for human interaction task. Before the human interaction occurs, NodeB goes down. When the interaction occurs, the Load Balancer in front of the cluster will direct the request to another node, let's say NodeA - will this correctly continue the process?
Yes that’s supported without additional configuration. The Activiti database will contain the process instance created by Node B and Node A will be able to perform the human interaction logic on the same process instance.
3) Supposing that your Processes are idempotent, that is you can re-execute them in case of failure without corrupting data. In such a scenario would you recommend an architecture where you have on each Server: 1 Application Server - 1 Activiti Engine - 1 Database
Like mentioned in 1) the typical usage would be to use a shared database. But yes 1 Application and 1 Activiti Engine would be a typical architecture.
4) Which (if any) Activiti components are cached in the engines that are part of the cluster ?
The main artifacts that are cached in the Activiti Engine are process definitions. Every Activiti Engine will have a cache of process definitions in-memory. In addition there’s a thread cache when running a process instance until it gets persisted to the Activiti database.
5) How do you ensure that multithreaded requests from process engines are properly synchronized ? is it demanded to the database specific features or it is done enterely by Java code ?
The first request trying to complete a specific user task will be executed and the second request will get an exception. If multiple requests access different process instances in the Activiti Engine then each request is executed as expected of course.
6) What happens if the Job executor is deployed on every node of the cluster ? would you recommend it ?
It’s recommended to have more than one Job Executor to have fail-over. When each node in a cluster has a Job Executor running then that’s fine as well. Each Job Executor will poll the jobs table to look for jobs to be executed. But only one Job Executor will be able to lock the job and then execute it. If you really need that many Job Executors depends on the number of jobs (timers, asynchronous activities) that you have in your process definition. Typically, having 2 Job Executors is enough for a lot of use cases.
Tijs Rademakers is a senior software engineer specializing in open source BPM, lead developer of Activiti Designer, and member of the core Activiti development team. He is the author of the book Activiti in Action published by Manning