Exception while invoking TaskListener: null

[nal_raj]

Hi I am getting following Error while upgrading from 5.9 to 5.18.0
Do i need to implement custom TaskListener? How i can do that?

Caused by: org.activiti.engine.ActivitiException: Exception while invoking TaskListener: null
        at org.activiti.engine.impl.bpmn.helper.ClassDelegate.notify(ClassDelegate.java:119) [activiti-engine-5.18.0.jar:5.18.0]
        at org.activiti.engine.impl.delegate.TaskListenerInvocation.invoke(TaskListenerInvocation.java:34) [activiti-engine-5.18.0.jar:5.18.0]
        at org.activiti.engine.impl.delegate.DelegateInvocation.proceed(DelegateInvocation.java:37) [activiti-engine-5.18.0.jar:5.18.0]
        at org.activiti.engine.impl.delegate.DefaultDelegateInterceptor.handleInvocation(DefaultDelegateInterceptor.java:25) [activiti-engine-5.18.0.jar:5.18.0]
        at org.activiti.engine.impl.persistence.entity.TaskEntity.fireEvent(TaskEntity.java:728) [activiti-engine-5.18.0.jar:5.18.0]
        … 265 more

[jbarrez]

Without the code or process it's hard to tell what is causing this. Can you paste some relevant snippets so we can try to understand what you are doing?

[nal_raj]

Scenario is I have FLow1, FLow2, Flow3 bpmn20.xml with interrelated states. There is Sign-Out state in all flow.
Code configure like, If i want to signout flow1, it callback to FLow2 to signout and Flow2 callback to flow3.
Individually all flows getting sign out but from callback its not.
It's getting executed , but when i am trying to retrieve its state …i found its previous state as new state is not getting save in DB

THings working fine with Activiti 5.9 not with 5.18.0
Please see code
Called flow1 sign out->(Callback Flow2)-> Flow2 Signout-> (Callback FLow3) flow 3 signing out as follows.

getProcessHelper().signal( processId, signalFlow3Signout ); and Signal API as follows

  public void signal( String processId, String signal ) {
    ProcessInstance instance = runtimeService.createProcessInstanceQuery()
      .processInstanceId( processId )
      .singleResult();
    runtimeService.setVariable( processId, USER_SIGNAL, signal );

    Task task = taskService.createTaskQuery().executionId( instance.getId() ).singleResult();
    String state = task.getName();
    LOGGER.info( "State Change :: signal() :: Signal for State change - state: " + state + ", for execution id : "
      + instance.getId() + ", All states getProcessInstanceId: " + instance.getProcessInstanceId() + " Signal :"
      + signal );
   
    taskService.complete( task.getId() );
  
    instance = runtimeService.createProcessInstanceQuery().processInstanceId( processId ).singleResult();
    task = taskService.createTaskQuery().executionId( instance.getId() ).singleResult();
    LOGGER.info( "State Change :: signal() :: After Changed state: " + task.getName() + " for processId id : "
      + instance.getId() );

  }

I am doing taskService.complete( task.getId() ); and in next step when trying to get changed state…I found state is previous one not (Sign-Out) but if i will call  getProcessHelper().signal( processId, signalFlow3Signout ); standaloneits working fine to me. Then why not from callback function? Do i need to update above(Signal API)

[trademak]

Can you include the BPMN XML as well? If you are performing logic in a signal method, you have to be aware that transactional data is not yet persisted in the database.

Best regards,

[nal_raj]

But is there any specific problem with Activiti-5.18.0..because it's working fine with Activiti 5.9
Please find BPMN XML.

[jbarrez]

I'm assuming that this is the same problem as the one you posted here: https://forums.activiti.org/content/error-while-migration-activiti-engine-59-5180 ?

How this this class look like: com.nal.raj.workflow.impl.DefaultProcessTrackingListener

I've looked at the process, but I'm not quite sure what to do. Do you also have a java unit test that uses this process definition xml and that demonstrates this problem?

[nal_raj]

In this case …i will try to create demo project that would have same implementation and i will share with you,
So that scenario will be more clear

[nal_raj]

PF Attached Test-Case in activiti-example.zip , run with 5.18.0 and 5.9 by changing dependency in pom.xml

https://github.com/nal-raj/Activiti-demo      ->(Project and issue-PPT)
I have created sample demo to reproduce that issue, which we were talking long time
Now Issue is more apparent that- > "Process state is not getting changed in callback context but it is changed after callback end ".
Behavior quite different in 5.18.0 as compared to 5.9.0


In Activiti 5.18.0 -> When we callback "Items" flow from "Order" flow for Signout state (After taskService.complete(taskID)) We tried to get its output before callback end..I can see that "Items" flow's state is not changed, its still previous state i.e. "InProgress". Once callback end , state is getting changed.

But in Activiti 5.9 ->  State getting changed before callback end and obviously after callback end .

Now I want same behavior in activiti 5.18.0 as well, because before callback end, based on state changed..i am executing some other business logic.

Test case will not fail in either case i.e. Activiti 5.9 and Activiti 5.18.0 , because assert in test case executes after callback… SO that i have printed output in console.

Please help.

[jbarrez]

Ok, so I looked at your unit tests, that helps a lot to understand it. For example, you're talking about callbacks, but that's a concept in your own code, hence I never understood so far what was happening.

Also, dont go spamming your problem on various topics, please.

Ok, so the problem is quite easy: in 5.9 (and other versions) the transaction management with spring was actually not consistent. In 5.18 (and earlier), we fixed this. Thus, your call for the callback is executed is executed in the same transaction as the others, which means in the next taskQuery call, the value is NOT yet updated as the transaction is still happening and it hasn't been comitted yet. So the behaviour in 5.18 is actually correct and honoring the correct transaction semantics.

You can set back the 'old' behaviour by adding this to your processEngineConfiguration:

<code>
<property name="defaultCommandConfig">
      <bean class="org.activiti.engine.impl.interceptor.CommandConfig">
        <constructor-arg value="false" />
      </bean>
     </property>
</code>

[nal_raj]

Does this solution create any bottleneck in performance of Acitiviti-engine 5.18.0 and specific to java callback (in my scenario).
because performance is the only reason to upgrade, Otherwise i am fine with Activiti v5.9 too.
please let me know.

I will keep only this topic on…no worry !! Thank you very much for your help and guidance.