-
1. Re: Unexpected behaviour using interrupting message boundary event at a custom task
swiderski.maciej Sep 11, 2014 1:45 AM (in response to thomas_fielenbach)actually I would use error boundary event instead of message as it seems you're handling error rather than message. Error will cancel the node it is attached to and continue with the flow of the boundary event. While if you do the signal from within the work item handler it might be that the signal is handled and process instance is completed before it gets a chance to be canceled ... that's just an idea and was not confirmed.
HTH
-
2. Re: Re: Unexpected behaviour using interrupting message boundary event at a custom task
thomas_fielenbach Sep 11, 2014 2:04 AM (in response to swiderski.maciej)An error boundary event - I think - would only be applicable if we would throw an exception from inside of the custom task.
But we are receiving an external trigger. The singal is not triggered by the custom task handler.
In fact, we are exposing an interface and use the 'signalEvent' (or in the positive case 'completeWorkItem') inside a bean that implements the interface:
public interface ProcessInteractions{ void processEvent(long processInstanceId, String eventName, ...); }
public class ProcessInteractionsBean{ public void processEvent(long processInstanceId, String eventName, ...){ if(eventName.equalsIgnoreCase("redo")){ ... kieSession.signalEvent(...)// trigger message boundary event ... } ... else{ ... kieSession.getWorkItemManager().completeWorkItem(...) ... } } }
-
3. Re: Unexpected behaviour using interrupting message boundary event at a custom task
swiderski.maciej Sep 15, 2014 1:47 AM (in response to thomas_fielenbach)would it be possible to get a reproducer for this? That way I would quickly check if that is a bug or not.
Cheers
-
4. Re: Re: Unexpected behaviour using interrupting message boundary event at a custom task
thomas_fielenbach Sep 16, 2014 2:09 AM (in response to swiderski.maciej)During creation of the reproducer I finally figured out the issue.
It seems that the boundary message event triggers the abortWorkItem-method. We have implemented the abortWorkItem like that:
public void abortWorkItem(WorkItem workItem, WorkItemManager manager) {
...
manager.abortWorkItem(workItem.getId());
}
That caused the concurrent process flow.
Removing 'manager.abortWorkItem(workItem.getId());' from the 'abortWorkItem'-method made the process execute as expected.
The sources are attached. In the customtask 'FirstCall' currently the variant that causes the unexpected behavior is implemented.
That can by identified that by running the unit-test which has the following output :
FIRST TASK | LOG AFTER FIRST | SECOND TASK | ABORT - FIRST TASK | MESSAGE RECEIVED - LOOPING | FIRST TASK
'LOG AFTER FIRST SECOND TASK' should not be executed.
If 'manager.abortWorkItem(workItem.getId());' is removed the output is 'FIRST TASK | ABORT - FIRST TASK | MESSAGE RECEIVED - LOOPING | FIRST TASK'
Can you explain that behaviour?
Cheers
-
5. Re: Unexpected behaviour using interrupting message boundary event at a custom task
swiderski.maciej Sep 16, 2014 7:29 AM (in response to thomas_fielenbach)Thomas,
that explains it a bit, abortWorkItem is already called by the engine to inform handler to abort the work and the handler should not call workManager.abort again as that would repeat the same sequence of steps. So that would be expected behavior in my opinion. Does it work properly when abortWorkItem of your handler does not all abort again on work manager?
HTH
-
6. Re: Unexpected behaviour using interrupting message boundary event at a custom task
thomas_fielenbach Sep 16, 2014 8:35 AM (in response to swiderski.maciej)Yes, it does work properly if we do not the 'double-abort'.
Cheers
-
7. Re: Unexpected behaviour using interrupting message boundary event at a custom task
swiderski.maciej Sep 16, 2014 12:17 PM (in response to thomas_fielenbach)cool, then I guess thread can be mark as answered/assumed answered so others can benefit from it
Cheers