cancel
Showing results for 
Search instead for 
Did you mean: 

Timer triggers entity deleted event

mortalcombat
Champ on-the-rise
Champ on-the-rise

Hi all,

I am adopting activiti version 5.22.0 and I've noticed the following behavior: when a timer is started an entity deleted event is triggered with no delete reason specified. I'm attaching a unit test which illustrates this behavior. I have added an EventListener, which is notified when an "ENTITY_DELETED" event occurs and it checks whether the deleteReason is null. The same event is also triggered for the endTask. Am I doing something wrong, or is this the expected behavior ?

Kind regards,

Mihail

11 REPLIES 11

nikmenke
Confirmed Champ
Confirmed Champ

Hi Mihail,

this is the correct behaviour. In your unit test you start an instance of the process. The instance will be returned if the process reaches the first wait state. The timer is such a wait state. So the timer is created and the startProcess method returns the instance. Furthermore it is the end of the test. Therefore the deployment will be deleted and the event is triggered. If you would add a line like TimeUnit.SECONDS.sleep(30) the second service task would be executed too.

Niklas

mortalcombat
Champ on-the-rise
Champ on-the-rise

Hello Niklas,

As far as I understand, when the first wait state is reached it's expected that the process instance will get deleted and therefore the listener gets triggered ? Should this event get triggered for each wait state, e.g. if i have a flow like start->task->timer->task->timer->task->end  would this event get triggered twice ?

Also, this behavior is not observed in version 5.15.1, as I'm currently updating my project from 5.15.1 to 5.22.0 and I have similar event listeners, which didn't get triggered in this case before. Would you know if this is a new feature introduced somewhere in the range of [ 5.15.1; 5.22.0 ] version of the engine ?

Thanks,

Mihail

Hi Mihail,

when the first wait state is reached the process will be persisted. At that moment the current thread finished the method startProcessInstanceByKey and returns the process instance. So the test will be ended and the deployment will be deleted.

The timer would now be handled by the jobexecutor or asyncexecutor. I have noticed that you did not activated one of them. So your second service task would never been executed because the process will never be triggered to continue.

This event triggers anytime a entity is deleted. So if your unit-test passes with the activation of the asyncexecutor and adding a sleep it will be triggered several times.

Just add those lines to the processEngineConfiguration in your activiti.cfg.xml:

<property name="jobExecutorActivate" value="false" />
<property name="asyncExecutorEnabled" value="true" />
<property name="asyncExecutorActivate" value="true" />

Hope this helps

Niklas

Hi Niklas,

I have made the modifications you mentioned. I have also modified the listener to display the activityId when it is triggered. Now the second service task gets executed as well, and the event listener gets triggered two times -> one time for the timer and one time for the endEvent.

When I run the same test using version 5.15.1 of the engine, however, the event listener doesn't get triggered at all. Is this a bug in the 5.15.1 version or is this a feature introduced somewhere between 5.15.1 and 5.22.0 ? I could attach the modified archive if you'd like. 

Best regards,

Mihail

Hi Michail,

the first time the events triggers your listener the execution for the timer is deleted. The second time the execution(ProcessInstance) for the tasks is deleted.

Step1: StartEvent -> ProcessInstance created

Step1: ServiceTask1

Step2: TimerEvent -> TimerExecution created, ProcessInstance suspended

Step3: Timer fired -> ProcessInstance activated, TimerExecution deleted (Listener triggered)

Step4: ServiceTask2

Step5: EndEvent -> ProcessInstance deleted (Listener triggered)

But i don't know if this was the behaviour before v. 5.22.0.

Niklas

Hi Niklas,

I have modified the bpmn diagram so that the listener would get triggered only for process-instance entity type by adding the following:

<activiti:eventListener events="ENTITY_DELETED" entityType="process-instance" class="test.tasks.MyEventListener"></activiti:eventListener>

According to your previous statement, as far as I understand, now the listener should get triggered once, when the endEvent is reached and the ProcessInstance gets deleted. It is, however, still triggered for the timer. Should the "TimerExecution deleted" trigger the listener ? Or there is a process instance created and then deleted for each timer ?

Mihail

Hi Mihail,

i agree with you. That should not happen. But there is still no second ProcessInstance. If you would modify your listener a little bit you would get a better output. Something like this maybe:

public void onEvent(ActivitiEvent event) {
   try {
         if (((ExecutionEntity) ((ActivitiEntityEventImpl) event).getEntity()).getDeleteReason() == null) {
               System.out.println("Event listener triggered: " + event.getType() + " " + ((ExecutionEntity)                         ((ActivitiEntityEventImpl) event).getEntity())+ " " + ((ExecutionEntity)((ActivitiEntityEventImpl)                   event).getEntity()).getParentId());
        }  
      } catch (ClassCastException e) {
   }

}

Output:

Test service task
Event listener triggered: ENTITY_DELETED Execution[7] 4
Another test service task
Event listener triggered: ENTITY_DELETED ProcessInstance[4] null

As you can see there is an execution and a processinstance. The main difference of both is that the processinstance has no parent execution.

Niklas

Hi Niklas,

I've modified the listener as you've said and indeed it gets triggered for the entity type Execution. But I have configured it to be triggered only for entityType="process-instance". For now I will apply the workaround you've suggested, but is this considered a bug ? If so, should I track it somewhere ? 

Thanks a lot for your support !
Mihail

Hi Mihail,

in my opinion this is a bug. You could raise a jira issue.

Niklas