cancel
Showing results for 
Search instead for 
Did you mean: 

recieveTask with boundaryEvent that expires after defined time does not finish execution with cancelActivity = true

aman1
Champ in-the-making
Champ in-the-making
I am using a recieveTask with boundaryEvent that has a timerEventDefinition of 10 seconds.

      <receiveTask id="waitForDispatchUpdate"/>
      <boundaryEvent attachedToRef="waitForDispatchUpdate" cancelActivity="true"
         id="setDefaultIfNoDispatchUpdate">
         <timerEventDefinition>
            <timeDuration>PT1S</timeDuration>
         </timerEventDefinition>
      </boundaryEvent>

In the BPMN file , the sequence flow is such that we send a request out and it for the response , if the timer expires then there is a service task that does some processing. The problem i am facing is that the flow waits on the recieveTask for 10 seconds. Suppose the response doesn't come in the intended time , then the flow continues to proceed with the negative flow. when the response comes now , then i try to check the execution based on activiti id. It should return null because the bpmn flow execution has passed the recieve task after the timer has expired but it doesnt.

runtimeService.createExecutionQuery()
            .processInstanceId(processId).activityId("waitForDispatchUpdate")
            .singleResult()  is not null.

Please can you suggest. My requirement is not to process the response if it comes back after the timer has expired.
3 REPLIES 3

trademak
Star Contributor
Star Contributor
It waits for only 1 second now, which is not a good value to test with. Did you try to use PT10S as well? It should definitely close the execution of the receive task. If it doesn't can you create a unit test showing the issue?

Best regards,

aman1
Champ in-the-making
Champ in-the-making
Yes in the BPMN i have a timer of 20 seconds only. I was trying with 1 sec because i wanted the timer to expire soon and proceed with the negative flow. So that when the late response from JMS comes back thru the runtimeService.signalRecieve(activitiId) , it fails as the execution for this activiti id is returned null. But it doesn't returns null.
See the bpmn attached.
One more point to be noticed. when the timer expires , i have a series of tasks to execute say- timer expires -> script to set colour pink -> colour ticket to pink -> log end -> end.
Suppose my java task that colors ticket to pink takes time and while we are in this step .. at this very instant if i try to signal back the workflow , should the execution returned is null or should it still be there as the workflow hasn't ended still.

frederikherema1
Star Contributor
Star Contributor
As long as the java-task is executing, the transaction is not committed yet and the process (from a DB point of view) is still in it's previous state. External calls to the API will use their own transaction, not aware of the process running. The transaction that commits first, is the winner. The other one will get an optimistic lock exception, rolling back all changes done in that transaction.