This really off-topic,
It possibly has to do with your basic coding and not with Seam. Basic rule for the garbage collector is that it can do its work only for released memory it can
Use the different java tools to se what happens.
P.S. Look for bean managed objects such as caching, maps and so on, where you manually need to null references.
Sry, but im using same architecture with Spring and Weld, and i can see that Weld is not holding the conversation objects. Because that i wanna know if someone had this problem with Seam 2. Even doing a killOthersConversations() are not firing the endConversation event, i can listen beginConversation without problem. I tried to listen endConversation event to clear manually the objects. So, looking the reference graph of the Profiler im always getting the same JavaBeanInterceptor.class, this is the last knew code and after just java.lang... classes.
We have deployed a survey application whit thousands of simultaneous users. The site is up and running for months now and besides the stuff we don't see the mentioned problems here.
Something should be different, because we experience that especially the conversation scope has an excellent clean-up. We now use 2.1.2 and 2.2
Diego, have you found out what was causing the memory leak? I am experiencing something similar. I have implemented a 'memory debug' page based on the wiki example in the seam distribution. The size of objects is estimated by serializing them. For that we get an enumeration of Attributes names from the the HttpSession and show a table with the name of the object and its size.
What I've found is
a) a know memory leak with AjaxStateHolder (we are using richFaces) https://issues.jboss.org/browse/RF-3878. The workaround there does limit the biggest memory leak.
b) objects for old conversations are still listed in the HttpSession.
(see screenshot). When you check with the debug.seam page these old conversations aren't listed.
So why aren't these objects not removed from the HttpSession?