topic Activiti on Websphere and Spring AsyncJobExcutor in Alfresco Archive

Activiti on Websphere and Spring AsyncJobExcutor

ggr — Tue, 20 Sep 2016 18:12:14 GMT

Context : Make long story short, it has been decided in my company to use Activiti, we have strong knowledge in EMC Workflow Engine. We have deployed it in a hurry in production on IBM Websphere Application Server.Not enough load/perfomance tests, the inevitable happens : the server crashed.After so

Re: Activiti on Websphere and Spring AsyncJobExcutor

jbarrez — Tue, 27 Sep 2016 11:49:47 GMT

Hi GGR, thanks for the detailed post, really interesting!

1. Wouldn't it be easier to use the org.activiti.spring.SpringAsyncExecutor here? It seems you're using Spring anyway. This SpringAsyncExecutor expects a taskExecutor to be injected (which maps to what you have). or is this how you are using it already?

2. and 3. thanks for posting that. useful for many others.

4. I'm not sure yet how this would regulate the load of the executor better/differently?
Currently, the thread based solution uses a blockinqueue, when it's full the acquiring will also be throttled.
In general, the current implementations works pretty much like you describe (except a second scheduler is not used, it's passed to the queue itself).

So am I right that maybe you're looking for different/interfaces here?

> Thanks for providing such a great product.

Many thanks!

Re: Activiti on Websphere and Spring AsyncJobExcutor

ggr — Wed, 05 Oct 2016 06:50:15 GMT

HI,

1. Of course, it will be easier, but you cant retrieve the threadpoolexecutor of a WAS.
We are using a WAS because of the organization policy, but I am not convinced that this is safer/robust/scalable than a tomcat.

4. Two point for this :
Considering the use of Thread.sleep() / scheduling of task
If you a have only a limited number of threads to work with - 10, 3 will be allocated to retrieve the jobs and 7 will process the jobs.
If the queue is full, the 3 retrieving job will be sleeping instead of processing jobs.

Regulation of the load

I do not know - because I do not have testing enough - if the regulation will be better.
I have studied your "queue based async executor" of v6, and I think this a really good solution.
Indeed, we plan to use it : we want to split the execution of job by process to mitigate the risk.
Architecture will be something like :
* one oracle DB
* one server to retrieve jobs
* As many queues/JMS as processes definition
* at least one job executor per queues.

The only things that bother me, is that there is not enough abstraction, and the standard implementation & the jms executor one does not share the same interfaces/abstract class.
On the other hand, I understand the legacy and the need that the engine can be started with the less configuration possible.