maybe Memory Leaks

[diegocoronel]

Hi,

I worked in a project that is in production now and its having memory problems, i installed a Profiler and i can see that for every conversation created the memory is not been released. Every time i click in a functionality in my menu im starting a new conversation and killing the other conversations. So, in debug i can see that im with only the correct conversation active. I dont know how to use the profiler correct but i can see that my ManagedBeans are being referenced by JavaBeanInterceptor that is a seam class. We have 200 users simultaneously and the memory is always increasing, only when i finish the session that i have some memory released.

Does anyone knows something about that ? I tried to remove all Session Beans but it doesnt worked too.

[lvdberg]

Hi,

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 see.

Use the different java tools to se what happens.

Leo

P.S. Look for bean managed objects such as caching, maps and so on, where you manually need to null references.

[diegocoronel]

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.

[lvdberg]

Hi,

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

Leo

[ibenjes]

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?

Regards

Immo