Unexpected behaviour using interrupting message boundary event at a custom task

[thomas_fielenbach]

Hi all,

We are using custom tasks to execute asynchronous service calls to external systems.

The asynch response can result in different processings (simplified):

- positive response -> call 'completeWorkItem' and go with the process (LOG AFTER, ...)

- negative response --> redo the custom task by sending a message which is processed by the interrupting boundary message event and loop back into the custom task

Our expectation is:

- The custom task is cancelled/aborted (without traversing the process flow further to LOG AFTER, ...)

- Loop back to the custom task again so that the service call is triggered again.

--> Only one thread exists and that is the one for the looping (MessageReceive -> LOG FIRST --> XOR -> FIRST_CALL)

What happens:

- One token traverses down the process (LOG AFTER, ...)

- One token loops back to the custom task again so that the service call is triggered again.

--> So there are "logically" two threads of execution in the process exist (1. MessageReceive -> LOG FIRST --> XOR -> FIRST_CALL | 2. LOG AFTER ...)

Is that a desired behaviour?

If so, do are there best practices etc. how to solve our use case/expectation?

Thanks in advance

Thomas

[swiderski.maciej]

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

[thomas_fielenbach]

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(...)
     ...
   }
 }
}

[swiderski.maciej]

would it be possible to get a reproducer for this? That way I would quickly check if that is a bug or not.

Cheers

[thomas_fielenbach]

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

[swiderski.maciej]

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

[thomas_fielenbach]

Yes, it does work properly if we do not the 'double-abort'.

Cheers

[swiderski.maciej]

cool, then I guess thread can be mark as answered/assumed answered so others can benefit from it

Cheers