Looping Activiti Workflow

[coner]

I have been trying to implement a daemon process that will wakeup and do some work every X time in activiti.

I was able to do this with 2 service tasks and an exclusive gate that loops back to the first task, but after the flow executes 92 times it crashes, always.

It reports back a stackOverflow error and dumps an enormous number of lines.  How are serviceTask execute methods being called throughout a workflow?  It appears that they are called recursively and not sequentially regardless of the workflow layout. 

there are no variables within the execute() function that are created via "new" inside of that method.

start -> print "hello" -> sleep() -> exclusiveGate -> exit
                  ^————————|

[ronald_van_kuij]

Wrong forum, but I'll respond anyway (next time use the userforum please) because it is a fairly common misconception.

A sleep in a task makes sure you stay in the same thread. So it is indeed recursive. Normally you'll have a real waitstate and e.g. trigger it from an external event. So either use e.g quartz or model timeouts on tasks so they become real waitstates and yo do not get recursive behaviour

[coner]

shouldn't the workflow processing be sequential though and not recursive? does this mean that i cannot create linear workflows that are larger than 92 steps?

[jbarrez]

The easiest way to contribute is create a JIRA and add a patch file.

Note that looping support is not an easy task, and should be tested thorougly with plenty unit tests.

[ronald_van_kuij]

shouldn't the workflow processing be sequential though and not recursive? does this mean that i cannot create linear workflows that are larger than 92 steps?

What you do is not really recursive, it is a loop, a special kind of sequence. There needs to be a kind of 'callstack' to be able to undo things if an exception occurs, or to commit things when things go wrong. The concept of BPM is (most of the time) that there are some kinds of wait states like usertasks, receive tasks etc… If those are modeled in, the 'callstack' is persisted and stack overflows do not occur.

This does indeed mean that e.g. in your case, a lot of servicestasks after another without a waitstate will lead to stackoverflows, whether caused by loops or real sequences does not matter. Adding additional memory helps, but modelling things differently often does as well.

[coner]

so how would i go about adding more memory to a single workflow that is going to execute?

[ronald_van_kuij]

Sigh, sorry, you focussed on THAT remark… I'm less willing to help now, in combination with you trying and trying (in PM) to justify wrongly posting in this forum. If you have any IQ, you would not have taken that TO seriously and looked at the second remark… MODDELING THINGS DIFFERENTLY. But for me to help you with that, you should describe what you want to achieve, not focus on a single problem that happens to (almost) noone but you…

[coner]

obviously you intended to tell me to model things differently…. and obviously the reason that I asked how to change the memory is because I cannot accept the limited amount of memory space that is being allocated to individual workflows AND because runtime execution stack dumps are not acceptable when the workflow may not actually contain recursion or infinite loops.

I would like to be able to change the memory size to model the expected stack space consumption of an entire workflow execution.  based on this I can then report back that a designed workflow is most likely going to bust the activiti stack and prevent their deployment before they are instantiated.

[filipearaujo]

I've exactly the same problem, i want to make a loop with a condition that it may take long or short time, and it gives me the "StackOverflow" exception. I have trying doing this with a exclusive gateway and a parallel gateway and in both cases gives the  "StackOverflow" exception. Is there a way to make a efficient loop?

Something like this: http://www.workflowpatterns.com/patterns/control/new/wcp21.php

[coner]

based on the past few days discussion and as far as i know

short version:
no.

long version:
this is because memory is being added to the stack at every step inside of your workflow (by the engine), never being cleaned up, it will eventually cause a stack overflow.

ronald.van.kuijk's response was to model it differently….