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

GlobalTimerService.timerJobsPerSession grows without bounds

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 7.0.0.GA
    • 6.x.x
    • jBPM Core
    • WAS ND 8.5
      BPMS 6.4.4

      Suspect it will occur in other environments as well

    • ER3
    • Hide

      Attached GlobalTimerServiceVolumeTest and IntermediateCatchEventTimerCycleWithHT3.bpmn2

      Run the Test, which used Quartz timer service, and starts an endless series of processes with 1D timers.

      GlobalTimerService shows growing retained heap over time, leading to eventual OOM

      Show
      Attached GlobalTimerServiceVolumeTest and IntermediateCatchEventTimerCycleWithHT3.bpmn2 Run the Test, which used Quartz timer service, and starts an endless series of processes with 1D timers. GlobalTimerService shows growing retained heap over time, leading to eventual OOM

      When running a process with a large number of long-lived timers and a large number of sessions, the GlobalTimerService.timerJobsPerSession map appears to grow without limit and dominates the Heap until an OOM condition occurs. Each job handle keeps a live reference to the Process Session, and takes up approximately 232kb. This adds up quickly when scaling to thousands of concurrent processes.

      Since the timers are long-lived, the sessions don't need to remain in memory. Is there any way to have the GlobalTimerService purge the mapping periodically? This is especially helpful when using external timer management, such as Quartz or EJB based timers, since the engine does not need to keep the timer data around to ensure proper firing.

        1. test.log
          16 kB
        2. IntermediateCatchEventTimerCycleWithHT3.bpmn2
          6 kB
        3. GlobalTimerServiceVolumeTest.java
          7 kB
        4. gc.log
          339 kB

              swiderski.maciej Maciej Swiderski (Inactive)
              djeremiah David Murphy (Inactive)
              Marian Macik Marian Macik
              Marian Macik Marian Macik
              Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: