Process variable content not properly passed to subprocess

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.

waldo

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

jbarrez

It's pretty hard to say with only this description of course, but

The stack was ~1700 items deep(!)

That for sure doesn't sound right.  We do have a mechanism in place to avoid using the stack, but from what I read it might be broken here. How many steps does the process contain once you trigger it. Also keep in mind that the transaction will be open for the whole duration of all steps… some database (Oracle definitely) don't really like that.