delayed execution

[tom.baeyens]

Alejandro visited the belgian office recently. And as usual, he brought some very interesting ideas.

He pinpointed a potential problem in the process virtual machine: the call stack can grow too much with the current nested invocations. I thought that never more then 5 nodes would be executed in one go. But he pointed out that in loops this might go deeper.

I have a prototype working with delayed execution so that the nested call stack doesn't grow. it's configurable in the nodes wether a node doesn't mind delayed execution (default) or wether execution must be synchronous. As long as the behaviour implementations of nodes don't have anything between the proceed method invoation and the end of the method, the process interpretation is exactly the same, delayed and non-delayed.

Probably this will make it in 4.0.

The test is in the lightning module, test/org/jbpm/pvm/DelayTest.java It shows the sequence of execution that could be affected (if something is done between the proceed invocation and the end of the execute method). And it shows that the callstack doesn't grow in case of delayed execution of a while loop and that the same while loop generates a StackOverflowError in case of synchronous execution of this while loop.

cool, huh ? :-)

THANKS, Alejandro!

[jeffdelong]

Working with a customer this week with this issue. They create mulitple subprocesses from an actionHandler, each of which can execute several nodes, which possibly started other subprocesses, etc, and then signalling the parent token whne complete. They were having issues with the call stack. Their solution was to create additional threads on their own.

How does delayed execution differ from asynchronous continuations?

[tom.baeyens]

delayed execution is done within the same transaction. asynchronous continuation introduces a wait state and continues execution in another transaction.

delayed execution transforms tail recursion into a while loop.

but unless you have a while loop, i think there is less chance that you run into a problem.

another motivation whas that it will reduce the overall runtime footprint. if on average, you have 2 automatic nodes in a row, this will reduce the depth of the call stack of all concurrent threads.