Details

    • Type: Bug
    • Status: Verified (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 6.3.4, 6.3.4.GA, 6.4.0
    • Fix Version/s: 6.4.1
    • Component/s: jBPM Core
    • Labels:
    • Fix Build:
      CR1
    • Affects:
      Documentation (Ref Guide, User Guide, etc.), Release Notes, User Experience

      Description

      Source: https://github.com/droolsjbpm/jbpm/blob/6.5.x/jbpm-flow/src/main/java/org/jbpm/process/core/timer/impl/QuartzSchedulerService.java#L331

      We have seen many cases where due to database or network issues, the quartz trigger may fail for > 5 times and then eventually delete the quartz trigger. This may cause workflow to abnormally abort.

      We have even cases where the Quartz trigger is deleted for a process instance, but the process instance is left in reserved state, thereby leaving the process instance in an idle state and impacting the business SLA’s.

      I think we need a better mechanism to handle the triggers in case of 5 consecutive failures instead of deleting them and aborting the process. Also would be nice to be able to configure the maximum count of failures and the retry wait time.

      It would be great if we can error out these triggers instead of deleting them and then provide a mechanism to recover these failed triggers.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                swiderski.maciej Maciej Swiderski
                Reporter:
                jean.abraham Jean Abraham
                Tester:
                Tibor Zimanyi
              • Votes:
                2 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: