0 Replies Latest reply on Aug 3, 2016 4:52 AM by happyhippo

    jBPM 6.x - no complete rollback after exception in ServiceTask triggered by Quartz-Timer

    happyhippo

      Greetings,

       

      a neat feature of the jBPM engine is the ability to rollback the process, if an exception occured in a script/servicetask (the transaction does not get commited). That makes it easy to fix the error and retry.

       

      This does not happen with (Quartz) One-Shot-Timers. (We use jBPM 6.4, but the problem exists in previous releases as well).

      Maciej already fixed a similar bug ([JBPM-5024] error after timer causes the process to abort - JBoss Issue Tracker), that lead to the process being aborted in case of an exception after timers.

       

      A little pieces of code:

       

      How a Quartz-Timer gets executed:

      QuartzSchedulerService.QuartzJob:

       

      public void execute(JobExecutionContext quartzContext) throws JobExecutionException {

        TimerJobInstance timerJobInstance = (TimerJobInstance) quartzContext.getJobDetail().getJobDataMap().get("timerJobInstance");

         try {

        ((Callable<Void>)timerJobInstance).call();

        } catch (Exception e) {

      [this branch will not be entered]

      ....

       

      What gets executed further down in TimerManager.ProcessJob:

       

      public void execute(JobContext c) {

      ..

      try {

      ...

      ((InternalProcessRuntime) kruntime.getProcessRuntime()).getSignalManager().signalEvent(processInstanceId,

         "timerTriggered", ctx.getTimer());

      ...

      } catch (Throwable e) {

         logger.error("Error when executing timer job", e);

      [why dont we just throw e?]

      }

       

      As you can see, a timer causes the engine to simply signal the process. When the process continues then and there happens an exception after it, the exception never gets caught or thrown upwards the callstack.

       

      Implications:

      The process is being rolled back correctly due to the abortion of the transaction, but the quartz-timer can not handle the exception and mark the timer as incorrect - instead it behaves as everything was fine. Because of the missing feedback we can not programatically analyze the error and the still running process might be running until doomsday without anybody noticing

       

      Is there a reason for this behavior, or potentially a bug?

      A workaround might be to replace

       

      ((Callable<Void>)timerJobInstance).call();

       

      with the code to directly signal the process the "timerTriggered".

       

      Thank you,

      Dan