processing.time.monitor thread leak

Details

  • User impact:
    High
  • Similar Issues:
    None

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

relates to

Bug - A problem which impairs or prevents the functions of the product. MULE-6759 Http dispatcher thread leak

  • Blocker - Blocks development and/or testing work, production could not run.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Vote (3)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved: