topic Re: NullPointerException in AtomicOperationTransitionDestroyScope in Alfresco Archive

NullPointerException in AtomicOperationTransitionDestroyScope

deg — Thu, 18 Dec 2014 08:50:23 GMT

In activiti 5.16.3 we defined a flow that has a receive task. Later on in the flow it is possible to be redirected to that same receive task.In our integration tests we test the flow by signalling the execution runtimeService.signal(id, processData);‍‍‍Since it is possible in our flow that the same

Re: NullPointerException in AtomicOperationTransitionDestroyScope

deg — Wed, 13 May 2015 09:40:38 GMT

In Activiti 5.17 we still encounter this:

We wait for the process to wait for the event before we send the message.
We do this by querying the proces so that it is in the receive task before we send the message.
<code>
runtimeService.createExecutionQuery()
                .processDefinitionKey(processDefinitionKey)
                .activityId(taskIdentifier)
                .processVariableValueEquals(A_KEY, aUniqueValue);
</code>
When this query returns the result we signal the process that the task is received. But this still gives us the error.
<code>
Caused by: java.lang.NullPointerException: null
at org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionDestroyScope.execute(AtomicOperationTransitionDestroyScope.java:96) ~[activiti-engine-5.17.0.jar:5.17.0]
at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:96) ~[activiti-engine-5.17.0.jar:5.17.0]
at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:631) ~[activiti-engine-5.17.0.jar:5.17.0]
</code>

If we add the ugly:
<code>Thread.sleep(1000);</code>
then our tests pass.

But i really don't want such fragile tests with Thread.sleeps everywhere.

Re: NullPointerException in AtomicOperationTransitionDestroyScope

jbarrez — Mon, 18 May 2015 14:56:00 GMT

That is a racing condition between the receive task database commit and the signal method.
I agree a nullpointer is not nice, but it would still be the same issue with a nicer message.
If you signal that quickly, why not use another construct (a custom service task for example that does the wait and receive at once?)