Mule
  1. Mule
  2. MULE-5276

processing.time.monitor thread leak

    Details

    • User impact:
      High
    • Similar Issues:
      MULE-7643log4j.config.monitor thread leak
      MULE-7803Thread leak on inbound HTTP connections
      MULE-8146Grizzly thread leaks
      MULE-6759Http dispatcher thread leak
      MULE-6944Thread leak for asynchronous calls in embedded mode
      MULE-6800Thread leak on Mule redeployments for embedded
      MULE-7650DynamicClassLoader leaking classloaders
      MULE-7817ClassLoader leak due to wrong use of DEFAULT_THREADING_PROFILE
      MULE-5932Memory leak in org.mule.RequestContext
      MULE-1074Harden AbstractResponseAggregator against memory leaks (real and potential)

      Description

      Deploy loanbroker-bpm app, then stop it (e.g. via JMX -> MuleContext -> stop).

      Expected: clean shutdown of an application
      Actual: the processing time monitor thread stays behind (this applies to every app gathering stats), e.g. check out the threads list via jconsole, it has [loanbroker-bpm] app prefix. Note that there's another thread, which is ok (system Mule thread for this app, 'standby' mode handling management operations and notifications).

        Issue Links

          Activity

          Hide
          Mike Schilling added a comment -

          This is intended to be a single system thread that reaps all references. It uses (and needs) no per-app context. Having multiple threads uses more resources to accomplish the same job.

          Show
          Mike Schilling added a comment - This is intended to be a single system thread that reaps all references. It uses (and needs) no per-app context. Having multiple threads uses more resources to accomplish the same job.
          Hide
          Ryan Scheidter added a comment -

          This has been inactive for quite a while; what is the plan for fixing this issue? This thread leak becomes a much more critical PermGen memory leak in shared environments such as Web/App Servers.

          IMO, no part of Mule or any other framework should be appropriating system-wide resources that will outlive their context.

          This affects the 3.2 branch as well...

          Show
          Ryan Scheidter added a comment - This has been inactive for quite a while; what is the plan for fixing this issue? This thread leak becomes a much more critical PermGen memory leak in shared environments such as Web/App Servers. IMO, no part of Mule or any other framework should be appropriating system-wide resources that will outlive their context. This affects the 3.2 branch as well...
          Hide
          Pablo Kraan added a comment -

          When Mule runs in standalone mode, there is only one processing.time.monitor thread (wrongly named using the name of the application that uses it first). But there is no leak as the redeployment does not increases the number of processing.time.monitor threads.

          This is a problem when Mule runs in embedded mode: every time an app is redeployed will leak a processing.time.monitor thread.
          This thread should have the same life scope that the Mule context.

          Show
          Pablo Kraan added a comment - When Mule runs in standalone mode, there is only one processing.time.monitor thread (wrongly named using the name of the application that uses it first). But there is no leak as the redeployment does not increases the number of processing.time.monitor threads. This is a problem when Mule runs in embedded mode: every time an app is redeployed will leak a processing.time.monitor thread. This thread should have the same life scope that the Mule context.

            People

            • Assignee:
              Pablo Kraan
              Reporter:
              Andrew Perepelytsya
            • Votes:
              3 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development