nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Scaling activiti in large deployments?

gregorypierce

What is the best way to scale Activiti? Looking through the code, the thread model is such that a single thread handles all of the work going through the engine. There is a single instance of a processEngine and it handles everything that gets executed, but appears to be doing so in a single threaded manner. Am I missing something?

Find more posts tagged with

Comments

meyerd

Hi gregorypierce

What do you mean with "single threaded" ?

gregorypierce

When Activiti starts from my Spring application context the JVM using JVM Stat is only showing a single thread for everything request coming to the application on OSX. If I toss a lot of traffic at it will the Executor launch more threads to parallelize the requests or will they continue to be handled by a single thread? It could be that JVM Stat is just showing me some bogus information, but it appears that everything is a single thread hitting the database which is maintaining state.

meyerd

I still do not get what you mean by "a single Thread", sorry

But the deal is this:

Let's assume you have inbound requests via HTTP. Then you Servlet container will have a Threadpool handling Http requests. If you call activiti from such a thread, it will use that thread for performing synchronous work.
In addition, ativiti also has a custom Threadpool for performing asynchounous work (like Timers).

In that case the max number of threads that can be active in activiti is HTTP_POOL_SIZE + JOBEXECUTOR_THREAD_POOL_SIZE.
Of course concurrency will be further constrained by the maximum number of database connectionsyou configure in your pool.

But of course this all greatly varies depending on the environment you embedd activiti into.

gregorypierce

The issue is that its not servicing requests via HTTP, it is sitting in a normal Java application which is being run from the command line. The process itself is single-threaded starting from a static main(). So the only thread in the application is the one started when the application starts.

In the Spring configuration the processEngine is started and I am assuming that in 5.9 for things that receive messages it isn't starting new threads for processes to receive messages so all of the data. So the entire process exists in the context of a single thread. If I device to write an adapter to convert JMS messages into messages that will be passed to processes, unless I spawn multiple listeners/threads, Activiti is only running within the constraints of the single thread that the application is using.

Outside of JobExecuter which manages threads for timers and such, I don't see Activiti itself spawning any threads. It doesn't bring any threadpool to the table as far as I can tell. So from the prospective of Activiti, I am assuming that it always runs within the context of the Thread which is making calls to it - that it doesn't parallelize anything on its own. Consequently in order to scale activiti I need to bring my own server threading model to Activiti since it doesn't provide one itself… it is itself "as scalable as the threading model you provide it".