-- Guillaume Nodet: > Are you able to know where these objects are created ? > It sounds like it comes from the auto deployer ...
No, I've not been able to deduce this. My suspicion is that it might be part of a locking mechanism during a poll sequence that's defined in one of the basic component classes, but I've absolutely nothing but a gut feeling to base this sucpicion on. Hopefully, I'll have more time to test soon. 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
