Unstable Behavior When Putting Variables Separately Before Completing A Task

[mohammadhossein]

We have been using activiti for several months now.
At some part of my code I used to put variables before completing a task instead of calling

taskService.complete(taskId,variableMap);
‍‍‍

I, wrongly, did something like this:

runtimeService.setVariables(executionId, variableMap);
taskService.complete(taskId);
‍‍‍‍

After months of using this code; Today, process instances started failing after the first exclusive gateway would arrive. Claiming that the variable (which is tested by the condition expressions) is not defined.
The frequency grew until pretty much every attempt to continue a process instance would fail.

When I changed the latter code snippet to the former and ran the engine again, It started working properly again.

I did not report this as a bug for these reasons:
- It is probably hard to reproduce.
- The atlassian JIRA link on the home page is dead. (Where can I access the issue tracking system, if any exists?)

Has anyone had similar experiences?

[vasile_dirla]

Hi Mohammad,
could you please let us know what Activiti version are you using ?
would be great if it's possible for you to write a unit test to show the behaviour you described meantime I will try to reproduce it.

you can add issues here: https://github.com/Activiti/Activiti/issues

[mohammadhossein]

could you please let us know what Activiti version are you using ?

Activiti : 5.20.0 (The war file that i'm deploying is based on activiti-rest)
Container: Websphere 8.5.5.9
Java: 6
DB: DB2 (not sure about the exact version)
OS: Linux Centos 6

would be great if it's possible for you to write a unit test to show the behavior you described

I'm not at work now. will try to reproduce the behavior when I'm back to work next Saturday.

you can add issues here: https://github.com/Activiti/Activiti/issues

Thanks man!

This data might help if you're trying to reproduce it:
The behavior started after a couple of months of running instances and populating the DB; But the quantity of the data was not anything too big. (probably hundreds of thousands of records at most)
It first started misbehaving when developers would run two instances of the same process simultaneously. Then It grew more serious in a matter of hours.

As I said, changing that code fixed it.