Flowable Engine in clustered enviroment

Flowable Engine
1

Hello Flowable,

Here is the description of clustering Activiti BPMN http://www.mastertheboss.com/jboss-jbpm/activiti-bpmn/clustering-activiti-bpmn.
Is it applicable as well to the Flowable Engine?

Thanks in advance.

2

Generally, yes.

  • Clustering in flowable is handled in a very microservice like way.
  • Each instance is stateless and state is persisted to the database.
  • Concurrency is handled through transactions and database locks.
  • Any number of instances of the flowable engine can be connected to the same datasource and they have a common view of the state of the processes.
  • Asynchronous tasks are stored in a jobs table to be picked up by a job executer that can live on any of the instances.

Will

3

Thank you, Will,

And can we have multiple job executors as mentioned “…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.”?

4

Yes, the number of executers are configurable per instance. Multiple are supported out of the box, but the number is probably higher. I don’t recall the default off of the top of my head (3-5 comes to mind).

5

Mmm… I mean is it possible to have as many Job Executors as cluster nodes? Suppose we have
3 nodes and the full excerpt from the mentioned article to not confuse: “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.”

6

You can run as many executors as you’d like on as many nodes as you would like. They can be configured differently on different nodes if you would like, which is what I believe this is outlining. Sizing would be dependent on how many asynchronous tasks your processes have.

One thing I’d point out is that the “cluster” is defined by having the same data source. That means that it is possible for there to be nodes in the cluster that do not contain the same code. Asynchronous tasks can get executed on any node with asynchronous executors, so you’ll want to ensure that any nodes with executors can handle any async task plus any tasks that follow an async task but do not cause a wait state.