Boundary signal causes: already taking a transition

[dengee]

Hi there,


We're using activiti since June and we have different running instances of several processes and everything works great.
But now, I have a problem - and I don't know if I missunderstand some parts of BPMN and/or the use case was not correctly modelled.

I stripped the problem down to the following model:
[img]http://ibin.co/2PZiUKD797iX[/img]

The idea is as follows:
- the "service task" checks if a certain file (e.g. example.gif) exists or not.
- if the file is missing, a human task is added, where someone has to add the file
- there are different instances and it is possible that these different instances wait for the same file.
- so, if one instance has added a file (the "add a file" was completed) - a signal is sent to all instances.
- this should cancel all "add a file" tasks from all remaining instances. so, the "service task" rechecks if the file for this instance now exists.

so - it's somekind of a "multi-instance-retry"

However, when I want to complete the "Add a file" task, a "org.activiti.engine.impl.pvm.PvmException: already taking a transition" is thrown.

version: activiti 5.19

Do I missunderstand the boundary and signal concepts?!

Thanks!

[vasile_dirla]

I guess you get this exception for the instance which added the file and completed manually the user task.

could you please provide a unit test which will be very useful for reproducing the issue and decide what's happening ?

[dengee]

yes, your guess is right: My workaround is currently to remove the SignalThrowingEvent and to invoke the signal manually using runtimeService.signalEventReceived for all instances except of the current instance.

However, for me it is more a workarount than a good solution, so I created an unit test:
Project with Process and Junit: https://github.com/geesen/activiti-bugs

Thanks!

[jbarrez]

First of all, many thanks for the excellent and clear unit test. This really helps a lot.

So:

- I changed the process slightly (while still showing the exception) to have an end event after the signal throw. It doesn't make sense for the currently called process instance, as you would have 2 times the user task 'use the file' active

- The problem is caused by having both the throw and the boundary event in the same transaction. Well technically, the boundary is destroyed and the signal is created. The problem is that this is done using the same executionEntity. Which is why the engine chokes on it. The good news is that we fixed this in version 6 (the test ran green directly), cause there we introduce an execution for the boundary event specifically.  The bad news is that this is hard to fix on v5.

- There is a a more elegant workaround on v5 though is to make the signal throw async. That way, the boundary event will be destroyed in one transaction and the throw will happen in the next one.

[dengee]

Thank you that you looked at the problem!

Meanwhile I changed the processed:
- removed the boundary as well as the signal
- changed the user task into a receive task "waitForFile"
- instead of just complete the user task after the user uploaded a file, all instances are woken up: querying for all executions with the activity "waitForFile" and send them a signal.
- since I removed the SignalThrowingEvent, there is no direct flow to the "use the file" task. So, all instances run through the "service task" again.


However, I'm looking forward to see a production stable version 6
Thanks!