Seam Memory Usage: Finalizer, MBeanServerImpl, and ZipEntryContext?

[indyjones2]

I have a memory leak issue with my Seam application and I am trying to get to the bottom of it....

The problem I am having is that the application runs just fine until multiple users log in and start using the app. The RAM used by JBoss keeps increasing until the performance is at a stand still. The RAM usage never drops. Not even when a user logs off.

I ran a JMAP on the heap and then feed this information to a Eclipse Plug IN called Memory Analyzer. (http://www.eclipse.org/mat/)

Memory Analyzer identified 3 potential Leak suspects:

Suspect 1

The class "java.lang.ref.Finalizer", loaded by "<system class loader>", occupies 81,609,328 (30.58%) bytes. The memory is accumulated in one instance of "java.lang.ref.Finalizer" loaded by "<system class loader>".

Keywords
java.lang.ref.Finalizer

Suspect 2

One instance of "org.jboss.mx.server.MBeanServerImpl" loaded by "org.jboss.classloader.spi.base.BaseClassLoader @ 0x724ab2f8" occupies 33,845,504 (12.68%) bytes. The memory is accumulated in one instance of "EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap$Entry[]" loaded by "org.jboss.system.NoAnnotationURLClassLoader @ 0x724b0e70".

Keywords
org.jboss.mx.server.MBeanServerImpl
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap$Entry[]
org.jboss.classloader.spi.base.BaseClassLoader @ 0x724ab2f8
org.jboss.system.NoAnnotationURLClassLoader @ 0x724b0e70

Suspect 3

292 instances of "org.jboss.virtual.plugins.context.zip.ZipEntryContext", loaded by "org.jboss.system.NoAnnotationURLClassLoader @ 0x724b0e70" occupy 74,137,256 (27.78%) bytes. 
Biggest instances: 
•  org.jboss.virtual.plugins.context.zip.ZipEntryContext @ 0x7549b0c0 - 19,777,032 (7.41%) bytes. 
•  org.jboss.virtual.plugins.context.zip.ZipEntryContext @ 0x7ec11a28 - 16,313,256 (6.11%) bytes. 


Keywords

org.jboss.virtual.plugins.context.zip.ZipEntryContext
org.jboss.system.NoAnnotationURLClassLoader @ 0x724b0e70

Seam 2.1.2
JBoss 5.0.0GA
MySQL
Java 1.5

Does anyone have any ideas?

Does any of this have to do with Seam?

[jeanluc]

It's unlikely that's the source of the leak, it's just the class loader keeping handles to the JARs. A leak is not necessarily caused by the biggest memory usage.

To find the leak, you need to take memory snapshots before and after some user actions and compare them (remember to do a GC just before each capture) then interpret the delta. Eclipse MAT is decent, a better profiler in my experience is YourKit. They have an eval version.

[indyjones2]

First of all....YourKit is a great tool. Thanks for the info....

I found my problem and fix it, but I want to make sure I understand something....

My problem was that I had way too many Beans with Scope Type Session. A User would log in and imediately close the browser and log right back in. This was loading a lot of objects into the heap, which in turn was eating up the RAM. I changed the Scope Type to Page for many Beans. Now when a user logs in, very few objects are loaded and the Page Scoped Beans are only loaded when they are needed.

My Question....

When does a Session Scoped bean get garbage collected versus when a Page Scoped Bean?

I have session timeout set at 10 minuetes in my web.xml but that doesn't seem to have any effect.

From the information Yourkit was giving me, a Session scoped Bean stays in memory well after the user has hit logged out or closed the browser. And stays in memory until is garbaged collected.....

Is this correct? 

[jeanluc]

GC doesn't happen automatically when an object is no longer referenced (and this is not specific to beans or Seam, for that matter). If, when and what kind of GC happens depends on many variables (JVM, JVM settings, usage patterns, environment such as available memory and so on). GC in itself is a complex topic (have a look here to get an idea, there are other papers as well). This has little impact on how you write your application, but might be an interesting read.