Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Critical
-
Resolution: Unresolved
-
Affects Version/s: 3.1.2
-
Fix Version/s: None
-
Component/s: Core: Concurrency / Threading, Modules: CXF
-
Labels:None
-
User impact:High
-
Similar Issues:None
Description
The field org.apache.cxf.endpoint.ClientImpl#responseContext is a WeakHashMap that contains a weak reference to the Thread that is handling a Mule message (key of the map). The value of the map contains among a lot of other things also the DefaultMuleMessage (contained in DefaultMuleEvent).
Since Mule 3 the DefaultMuleMessage also contains a hard reference to the thread handling the Mule message: org.mule.DefaultMuleMessage#ownerThread.
This means that the WeakHashMap org.apache.cxf.endpoint.ClientImpl#responseContext contains references to the Thread object in its key and value. As a result of this the Thread and the corresponding responseContext are never removed from the responseContext map.
Under a continuous load this is not an issue since the thread pool that is used to handle messages is constant. This responseContext map will only grow when the pool first shrinks and then grows again. When shrinking Threads are removed from the pool and the corresponding responseContext objects should be removed as well. When the pool grows again new Thread objects are created and added to the responseContext map.
In our case the map became 1.4GB after 6 days.
Our current workaround is to set the threading profile maxThreadsActive and maxThreadsIdle to the same number so that the pool is constant and no new threads are created.