Hello there,
While pursuing a particularly nasty memory issue
in a custom component, I stumbled upon some
findings regarding the standard servicemix
components. It shows signs of a memory leak.
I'd like to know if these are the result of a
known issue or (if it isn't), what is required
to get bug confirmation? Provided it is indeed
a bug, of course.
Also, it'd be very useful to find out of if a
workaround is possible in this matter. The issue
is rather a showstopper.
Regards,
Rob
Tested using:
- Servicemix 2.2
- Java 5 update 15, Java 6 update 5
- Windows XP, Windows 2003 Server
- YourKit 7.0.11
The synopsis:
- Running Servicemix with (only) standard binding
components under hotdeploy, results in a steady,
continuous increase of the number of objects of
the type:
java.util.concurrent.locks.
AbstractQueuedSynchronizer$Node
The increasing object count results in a slow
drain on the VM's resources, until it runs out
of heap space.
Details:
- My tests were mostly limited to the following
components: File, HTTP, Lightweight, JSR181 and
EIP. Brief checks shows most or all of the other
standard components show the same behaviour.
- The size of an object (in this case both the
shallow and retained sizes), is 32 bytes.
- It seems there's a generation of roughly one
object per second. (Or rather 1<=X<=1.1)
- When we make a rough calculation, this equals
to about half an MB of memory every hour when
five components are deployed.
- Almost all of these objects are not Gcable.
- The increase starts even when no assemblies are
deployed. (Only the BC's and SMX Shared).
It is unknown to me which part of the code is
responsible for these objects' generation.
How to reproduce:
- Just use a (clean) install of servicemix, and
deploy Servicemix Shared and one or several of
the servicemix components. Monitor the memory
use.
Notes:
- The following Java bugreport might be
relevant:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6490770
