Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 3.1.2
-
Fix Version/s: None
-
Component/s: Core: Event/Message
-
Labels:
-
User impact:Medium
-
Similar Issues:None
Description
There appears to be sort of a memory leak in org.mule.RequestContext in the currentEvent ThreadLocal variable. Because threads are re-used, when a thread processes a MuleEvent and stores that MuleEvent in a threadLocal, the MuleEvent is not cleared out until the next time that thread is used to process something. In some cases, the mule system I'm working with processes large amounts of data which are getting stored in a threadlocal variable. Hours after the processing is done, the data is still in the java VM (seen in a heap dump). It appears the only reference to the variable is the threaLocal, so perhaps using a WeakReference or SoftReference for the threadLocal variable. Or is there a way to tell that an Event is done, and so clear it?
Activity
Suggestion: add finally blocks before threads are returned to the various pools, and in it null out all the thread locals used in core. (There really should be a Java method to null out all ThreadLocals, since everyone who uses a thread pool has the same issue. It's as simple as clearing the (package private) threadLocals and inheritableThreadLocals field in the Thread. A simple JVM hack 
)
)
RequestContext itself is evil and needs to go away ... With your last sentece you hit the nail on its head: we currently have no way to tell when a flow is done (consider async thread handoffs etc) hence there is no easy, one-stop solution to clear out RequestContext.