AnsweredAssumed Answered

Process variable content not properly passed to subprocess

Question asked by waldo on Mar 12, 2013
Latest reply on Mar 20, 2013 by jbarrez
Dear community,

I am stuck in a problem related to parameter passing and asynchronous subprocess calls and I hope that somebody can help me :)

We are evaluating the use of Activiti (5.11) in a current project. We created some processes (which I cannot attach here) to get acquainted with Activiti.

The processes use Activiti process variables to pass information around. The data in these variables is supposed to be "threaded through", i.e.
on each Call Activity, these parameters are passed in (via input parameters, e.g. source=X, target=X) and returned to the caller
(via output parameters, e.g. source=X, target=X).

We experience the following strange behaviour: the value of some variable X (a large Serializable object) for a subprocess executed through a
CallActivity does NOT contain the value of X as it is when the calling process calls the subprocess, but instead it contains the value of X as it was when the calling process itself started its execution.

There are 4 process definitions involved:

Syn (S)
Incoming (I)
Operate (O)
Confirm (C)

The execution sequence is as follows (service tasks executed in between are omitted, only calls are shown):

- O is started by some external "event", i.e. in Java code
- The value of X.foo.bar.baz is 0 [X.foo.bar.baz==0]
- O calls S
- S starts
- S waits for a message (message intermediate catching event)
- I is started by some external "event", i.e. in Java code
- I sends the message that S is waiting for
- S receives the message and continues
- meanwhile, I ends
- S reaches its end event, we still have [X.foo.bar.baz==0]
- O is resumed, still [X.foo.bar.baz==0] holds
- O's service tasks modify X, setting X.foo.bar.baz to 1
- O calls C
- C's first service task (right after the start event) detects [X.foo.bar.baz==0] and fails (it expects it to equal 1)

I tried to debug this problem myself, but honestly, this was hopeless for me given the way that Activiti handles process execution. The stack was ~1700 items
deep(!), mostly containing calls to CommandContext.performOperation, ExecutionEntity.performOperation and others.
I have implemented more than one finite state machine myself, and it never turned out to be a good idea to use the OS/VM stack for maintaining the machine's state.
I'm really curious why you chose this design. Any background information would be highly appreciated.

Btw: At one point, we even encountered a StackOverflowError, which we fixed by adding some more async…

We use Oracle 11g as a DataSource, the job executor is activated, all CallActivities are set to asynchronous (activiti:async="true")

Many thanks for any hints!

Regards,
Dennis

Outcomes