NPE when closing parent instance via event from called process

Camunda 7 Topics Discussion & Questions
1

Dear Community,

I am trying to implement a cancelation pattern when parent instance

topProcess.png612×513 8.82 KB

is canceled from one of the called process instances by throwing cancelation event to the event sup-process of the parent process (new users can put only one image in a post)

The event is correlated and the other called instance is being canceled successfully, however I get the following NPE when the code attempts to complete the parent instance.
It looks like the code attempts to process compensation logic by accessing the parent execution node which is null. This looks like a defect to me.

SEVERE: ENGINE-16006 BPMN Stack Trace:
	EndEvent_0yvqfs7 (activity-end, Execution[25])
	EndEvent_0yvqfs7
	  ^
	  |
	CallActivity_0a1mckm
	  ^
	  |
	EndEvent_0yvqfs7
	  ^
	  |
	CallActivity_15b8q80
	  ^
	  |
	UserTask_1
	  ^
	  |
	EndEvent_0yvqfs7
	  ^
	  |
	ExclusiveGateway_0d5diku
	  ^
	  |
	UserTask_1

Apr 20, 2016 11:24:43 AM org.slf4j.impl.JCLLoggerAdapter error
SEVERE: ENGINE-16004 Exception while closing command context: null
java.lang.NullPointerException
	at org.camunda.bpm.engine.impl.pvm.runtime.PvmExecutionImpl.getFlowScopeExecution(PvmExecutionImpl.java:1299)
	at org.camunda.bpm.engine.impl.pvm.runtime.PvmExecutionImpl.getFlowScopeExecution(PvmExecutionImpl.java:1299)
	at org.camunda.bpm.engine.impl.pvm.runtime.PvmExecutionImpl.createActivityExecutionMapping(PvmExecutionImpl.java:1289)
	at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityEnd.execute(PvmAtomicOperationActivityEnd.java:53)
	at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityEnd.execute(PvmAtomicOperationActivityEnd.java:32)
	at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:81)
	at org.camunda.bpm.engine.impl.interceptor.CommandContext.invokeNext(CommandContext.java:180)
	at org.camunda.bpm.engine.impl.interceptor.CommandContext.performNext(CommandContext.java:159)
	at org.camunda.bpm.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:134)
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:494)
	at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:471)
	at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityNotifyListenerEnd.eventNotificationsCompleted(PvmAtomicOperationActivityNotifyListenerEnd.java:42)
...

The workaround I’ve found is to use Async After on the Throw End Event, so that the failure doesn’t abort the current execution thread, but fail in the job executor, which appears to be capable of completing the instance despite the exception.

I’ve created a repro in the following repository:

2

Camunda version is 7.4.4.

3

Hi @stsymbal,

Sending messages within one process instance is not defined by the BPMN specification and not a documented feature of Camunda BPM (although we also do not exclude this use case explicitly). The exception occurs when the engine continues execution at the end event after the message has been sent. At this point, the called process instance has already been cancelled, apparently resulting in a NullPointerException. I created a bug ticket: https://app.camunda.com/jira/browse/CAM-5849

I suggest you exchange the message events by escalation or error events which would be the more appropriate BPMN constructs and appear to work with your process models.

Cheers,
Thorben

4

Hi @thorben,

Thank you very much for your reply.
In my case the cancelation message may be sent from outside of the instance and even by external system.
Thank you for pointing out the escalation event. I will consider it for instance scoped communication.

Thanks,
Sergii

5

Can you check if the problem exists with the latest 7.6.0-SNAPSHOT? I thinked we fixed the bug with the fix for https://app.camunda.com/jira/browse/CAM-6324.

Cheers,
Thorben

6

Hi Thorben,

Apologies for the delay.
I’ve tested with the latest 7.6.0-SNAPSHOT (Aug 5th 2016) and it looks like the issue is fixed, i.e. the unit test I created in the initial post no longer fails and I see the correct process flow in the log.

Thank you!
Sergii