1 Reply Latest reply on Dec 1, 2015 3:48 AM by Alexander Golubev

    Repeated signal from a single task is handled only once (retry simulation)

    Alexander Golubev Newbie



      I'm trying to simulate retry logic by using signal with cancelActivity=true. The jbpm version is 6.2.0.

      So i have a custom work item handler which would catch exception and send signal if exception occurs during custom task execution.



      What i observe is that ErrorRetryTask in the picture can be repeated only 1 time.

      It means that after first execution of custom task with exception the signal is sent and execution goes to the gateway and back to the custom task as expected. Then after second execution of custom task with exception signal is being sent again but workflow just ends so it doesn't go to the gateway again.


      Is it expected behavior that repeated signal is processed only once ?

        • 1. Re: Repeated signal from a single task is handled only once (retry simulation)
          Alexander Golubev Newbie

          It works now.  I've tried several options and finally updated custom workitem handler to not 'abort' or 'complete' workitem when exception happens and signal is sent. In this case the retry may happen in the loop without any limitations. The only question if such approach is correct from JBPM design perspective or not ? In accordance with JBPM documentation it's said that 'abort' or 'complete' should be invoked only after sending signal, but it's not clear whether complete/abort is mandatory in such case or not, and what the impact of not calling them at all. Any hints there ?


          Chapter 22. Exception Management



          When you use the WorkItemManager to signal that the work item has been completed or aborted, make sure to do that after you've sent any signals to the process instance. Depending on how you've defined your process, calling WorkItemManager.completeWorkItem(...) or WorkItemManager.abortWorkItem(...) will trigger the completion of the process instance. This is because the these methods trigger the jBPM process engine to continue the process flow.