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]

I created a unittest some small changes in the flow just to get an additional servicestask and it actually works….

There is one issue that I'll address in a different post. If the timeout is close to the actual duration of the external service, unwanted but explainable behaviour occurs. This mainly has to do with the engine cleaning up the runtime tables for this process when ending it and in the meantime something else still writes to the engine/db.

In the attachment you'll find an eclipse project.

[coner]

so:

'Send' task for 1
Working for 4400 ms
'Send' task for 2
Working for 4300 ms
'Send' task for 3
Working for 4400 ms
'Send' task for 4
Working for 4400 ms
'Send' task for 5
Working for 4200 ms
'Send' task for 6
Working for 4200 ms
'Send' task for 7
Working for 5100 ms
I'm in Error on count : 7
Process instance no longer exists

that "I'm in Error on count : *" happens fairly often;

does it work when it is not in a junit (without the while (true))? and is instead directly deployed / executed in the engine?

[ronald_van_kuij]

It happens 'often' because i did not want to wait hours when running tests. When it is 5000 or above the timeout fires…  If you change it to something like r.nextInt(5000), the odds of the timeout firering are reduced and you'll see lots of loops

I see no reason this should not work when deployed.

[coner]

is there a way to essentially have the recv task never be triggered, and always take the time out branch?

i really only am using the recv task because of the wait state memory write out issue, i don't actually want to use any of its functionality… including signaling it… because of that i really only want the timer to be the significant piece.

if changing the simpleError.java output in inputVar is sufficient let me know (but that is how my workflow was, and it never looped successfully)

if it is easier for me to create my own MemoryDumpTask via modifying the recvTask such that it doesn't actually do anything, or changing the user tasks to auto complete themselves; let me know and i'll just do it that way.

[ronald_van_kuij]

is there a way to essentially have the recv task never be triggered, and always take the time out branch?

sure, just don't trigger it, realy… It's that simple

I had no clue why you had the condition on the gateway, how you decided whether you needed to loop back or end the process, therefor I did use the simpleError.

The receive task does not do anything, so there is nothing to change. And I would not call it 'MemoryDumpTask' that is to technical a term. What it actually is/does is a 'PersistStateTask'

Oh, and if you use plain eclipse, the jobexecutor is not started automatically, so that might have been the reason it did not loop with you since the timer would not go off then. In unit tests you can 'manually' trigger the jobs to have control in the test. You can do that via the managementService. Or you can, as I did, have it start via the config file (see activiti.cfg.xml)

[coner]

Oh, and if you use plain eclipse, the jobexecutor is not started automatically, so that might have been the reason it did not loop with you since the timer would not go off then. In unit tests you can 'manually' trigger the jobs to have control in the test. You can do that via the managementService. Or you can, as I did, have it start via the config file (see activiti.cfg.xml)

that does seem to be the issue…

but do you simply mean setting it to "true" ? i have done that and can still not get it to run correctly outside of the unit test when the signal() is removed

[ronald_van_kuij]

Yep, but you have to make sure the correct config file is loaded. Easiest way to check if yours is loaded instead of the default one is to deliberatly make it invalid xml. If an error occurs you know it is, otherwise, check e.g. if it is on the classpath

[filipearaujo]

Thank you guys! This post has been useful! I created a loop that actually worked with the example of Ronald. Great post!

[ronald_van_kuij]

Glad I could be of any help…