Uploaded image for project: 'Red Hat Process Automation Manager'
  1. Red Hat Process Automation Manager
  2. RHPAM-4150

Drools/jBPM integration: high number of instances waiting for signal adversely impacts execution time

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • 7.13.0.GA
    • 7.10.1.GA
    • jBPM Core
    • None

    • RHPAM 7.10.1 + RHPAM-4082

    • False
    • False
    • Release Notes
    • ER1
    • +
    • Hide

      No known workaround exists.

      Show
      No known workaround exists.
    • Hide

      The reproducer attached shows that the number of active instances waiting for the signal has an impact on the execution time:

      1. Run the reproducer against a clean Postgres DB

      2. Check the time it takes to signal the first instance:

      Process 1 created for process case03137622.eventgatewaytest

      real 0m0.166s <-- This is the time for the signal REST call

      3. Wait for the script to generate some data (20k process instances)

      4. Check the time it takes to signal another instance:

      real 0m2.451s

      With a debug jar, we can see that the time is spent in the previously highlighted loop:
      12:21:14,188 INFO [org.jbpm.persistence.processinstance.JPASignalManager] (default task-96) Looping through 20001 process instances took 2246 ms

      Show
      The reproducer attached shows that the number of active instances waiting for the signal has an impact on the execution time: 1. Run the reproducer against a clean Postgres DB 2. Check the time it takes to signal the first instance: Process 1 created for process case03137622.eventgatewaytest real 0m0.166s <-- This is the time for the signal REST call 3. Wait for the script to generate some data (20k process instances) 4. Check the time it takes to signal another instance: real 0m2.451s With a debug jar, we can see that the time is spent in the previously highlighted loop: 12:21:14,188 INFO [org.jbpm.persistence.processinstance.JPASignalManager] (default task-96) Looping through 20001 process instances took 2246 ms
    • 2022 Week 08-10 (from Feb 21)

      A customer observed an unexpectedly long delay starting an intermediate condition catch event. The delay was found to be correlated to the number of active process instances waiting on that particular signal. In the support case behind this Jira the customer incurred a 40-60s delay with 80k instances, causing significant degradation of their production environment.

        1. case03137622.eventgatewaytest-svg.svg
          66 kB
        2. case03137622-reproducer-attempt-v2.zip
          89 kB

              rhn-support-egonzale Enrique Gonzalez Martinez (Inactive)
              rhn-support-ger-jan Gerhardus Johannes Petrus Maria te Dorsthorst
              Gonzalo Muñoz Fernández Gonzalo Muñoz Fernández
              Gonzalo Muñoz Fernández Gonzalo Muñoz Fernández
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: