Uploaded image for project: 'jBPM'
  1. jBPM
  2. JBPM-10016

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

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • 7.67.0.Final
    • None
    • Runtime Engine
    • None
    • False
    • False
    • NEW
    • NEW
    • 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

      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.

              rhn-support-egonzale Enrique Gonzalez Martinez (Inactive)
              rhn-support-egonzale Enrique Gonzalez Martinez (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: