Wrong script task listener executed

[rwa]

Hi,

We face a really annoying bug with activiti.

We use version 5.13 of activiti.

Here is the bug scenario (see bpmn here: https://drive.google.com/file/d/0BxxZafFzNUQdV1JGSnRUZ242SnM/view?usp=sharing for activity references) :
The process instance is in the usertask31 activity. The user does action for going out of this task and going into servicetask1.
This causes an error that says : "No outgoing sequence flow of the exclusive gateway 'exclusivegateway35' could be selected for continuing the process".
The bug appears randomly. When the bug occurs, a restart of alfresco resolves the problem.

After some analysis and adding some logs in activiti engine code, we found that in fact a wrong listener seems to be executed : The complete-event listener attached to task usertask23 is executed instead of the complete-event listener of task usertask31.

Our listeners are implemented by alfresco script task listener (org.alfresco.repo.workflow.activiti.tasklistener.ScriptTaskListener).

We check forums and activiti release notes about such a bug but with no result.

Do you have any idea about this bug ?
Do you think that a wrong task-listener association could be done (randomly!) ?

[jbarrez]

As said above, a unit test that demonstrates this problem would help a lot here
It seems to be environmental (ie Alfresco), so not sure how to reproduce with the bare engine.

[behemot]

Hello,
We have debug and fixed this problem. Our customers faced same problem daily.
Activiti load workflow definitions, parse and change to object and after that keeps in some kind of cache (map).
The problem is with workflow parser, which/when is working asynchronous. Restart is required because cache keep wrong/mixed listeners.

We have solved problem by just changing synchronize deploy method in BpmnDeployer.
Patch is tested and ready for production.

Please find the attached file "activiti-engine-5.13-alf-20130918_patched.jar_.txt" and remove "_.txt" to use it.

[ilyagalahov]

Thank you, David.

We already solved this problem too by executing web script to remove definition from cache…

Something like this:
activitiProcessEngineConfiguration.getDeploymentManager().getProcessDefinitionCache().remove(args['defId']);

But this works after problem already occured.

We cannot use patches by company policy.

Could you please share concrete code or github link ?

Are you just marked method deploy() synchronized ?
How does it impact performance ?

Regards Ilya.

ilyagalahov1@gmail.com

[behemot]

No problem. Welcome.

Regarding to your comments:
activitiProcessEngineConfiguration.getDeploymentManager().getProcessDefinitionCache().remove(args['defId']);
> this is only temporary solution, because Altiviti will do same mistake again

Could you please share concrete code or github link ?
> please just change:
public void deploy(DeploymentEntity deployment) {
to
public synchronized void deploy(DeploymentEntity deployment) {

How does it impact performance ?
> our customers have not over 20 workflows (not over 30 tasks per workflow, with not over 2000 JavaScript lines per workflow), and we do not see any differences

[rwa]

Hello,

Thanks a lot for this patch.

Do you think such a problem could happen with listeners in java ?

[behemot]

Hello,

Welcome.

No, there is no problem with listener, but with parser. Unfortunately we do not have time to analyze Activiti source code to fix asynchronous parsing, so we switch to synchronous