Skip to main content

About memory leaks in GlassFish

14 replies [Last post]
vkoniecz
Offline
Joined: 2008-11-14

Hello,

I know that there were issues filed about memory leaks and there are still a few ones opened. I have the impression that all the leaks indicated as FIXED in the issue tracker have been fixed before v2.1 b60e.
Is that right ? If not, can anybody tell me which ones I am missing please ?

Specifically, I have read that there can be problems with jar files not closed when the deployment abort. Is GF v2.1 b60e impacted ?

Thanks a lot for any information

Bye

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vkoniecz
Offline
Joined: 2008-11-14

Hello

Well after some work, it looks like the leak is due to issue 7074 or something very similar.
The little difference is that a connection has to be retrieved so that the memory leak occurs.

Bye

vkoniecz
Offline
Joined: 2008-11-14

Hello

Well finally it looks like the leak is due to issue 7074
https://glassfish.dev.java.net/issues/show_bug.cgi?id=7074

When the application gets a connection, a timer is created with the wrong context classloader leading to a leak.

Bye

vkoniecz
Offline
Joined: 2008-11-14

Hello

Just to share with you a temporary result of an analysis to try to identify some classes I can suspect from leaking.
This analysis has been performed on the histograms extracted from the heap dump.
Its objective was to identify the classes whose instances has been increased in a repeatable way between several deployments (repeatable cumulative increases eliminating those which have been subject to garbage collection).

You will find attached a file with a list of suspects.

Bye

vkoniecz
Offline
Joined: 2008-11-14

Hello

I was looking to the patches you attached to issue #7600.
The erroneous code pattern looks to be:
1) new JarFile( ... )
2) no finally clause that closes the jarFile
3) keeping references to the entries of the jar somewhere

Is that right ?

Since the open() and close() methods of classes JarFile/ZipFile are native methods, is the condition 3) required ?
I mean if a jar file is opened when the JarFile constructor is invoked (unless specified otherwise), it is required to explicitly close it.
Correct or not ?

Bye

dkoper
Offline
Joined: 2005-10-27

There are no patches attached to issue #7600 so I'll assume you are referring to my patches for issue #7060.

The problem I intended to address is:
1) new JarFile( ... )
2) no finally clause that closes the jarFile
3) file stays locked until gc kicks in so problems can occur when you undeploy/redeploy the app.

I'm not sure how this qualifies as a memory leak, btw.

Also I'm not sure how keeping references to the entries of the jar come in play. For the problem I had, the stream does not need to be closed while its entries are still in use. I would assume all references to the entries are nullified somewhere during undeploy.

Regards,
Dies

vkoniecz
Offline
Joined: 2008-11-14

Thanks for the clarification.
I am just trying to understand the meaning of your patch so that I can make some correlations between what I can observe during deployment/undeployment and thie issue #7060.
This can also be very helpful for diagnosis and heap dump analysis.

Bye

hzhang_jn
Offline
Joined: 2005-07-22

> I know that there were issues filed about memory
> leaks and there are still a few ones opened. I have
> the impression that all the leaks indicated as FIXED
> in the issue tracker have been fixed before v2.1
> b60e.
> Is that right ? If not, can anybody tell me which
> ones I am missing please ?

As Dies pointed out, issue

https://glassfish.dev.java.net/issues/show_bug.cgi?id=7060

was fixed in v3 but not in v2.*. I guess the sustaining engineers can port the fix to v2.* if needed.

> Specifically, I have read that there can be problems
> with jar files not closed when the deployment abort.
> Is GF v2.1 b60e impacted ?

Can you be more specific on this? I was not aware of any open issue on this...

> Thanks a lot for any information
>
>
> Bye

vkoniecz
Offline
Joined: 2008-11-14

For the moment, I can not be more specific.
I can only tell you that I have a small app I can deploy only 7 times on a GlassFish server before having headaches (OutofMemoryError during deployment).

We have taken some dumps and we are currently analyzing them.
We took a look at one heap dump we extracted.
This shows a lot of leak suspects (EJBClassloader, ...).
We will take a closer look and try to check whether we can find jar files not closed ...

(the headaches are due to the necessity to identify the right java processes to kill the faulty instance (without killing the others) because no other options work : admin console unusable, asadmin as well, ...)

hzhang_jn
Offline
Joined: 2005-07-22

I see. Let us know what you find. And remember open jar files is not the only reason that could cause memory leak.

I remember there were a few good links as to how to debug memory leak problems in glassfish, I cannot seem to find those forum threads now though.

hzhang_jn
Offline
Joined: 2005-07-22

I was able to find the links to Frank Kieviet's blogs on memory leak. Those were excellent blogs to read.
http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded

vkoniecz
Offline
Joined: 2008-11-14

Well I would rather recommand the use of Memory Analyzer (MAT for short) with a Sun JDK.
see http://www.eclipse.org/mat/

This tool is several magnitude more useful for memory problems analysis than jhat would ever be.
jhat is just a low level tool that displays references and allows some browsing.
Give MAT a try and you will understand what I mean.

vkoniecz
Offline
Joined: 2008-11-14

Answering to myself.

There are these ones
https://glassfish.dev.java.net/issues/show_bug.cgi?id=7060
https://glassfish.dev.java.net/issues/show_bug.cgi?id=9179

From the comments in issue 7060, may I suspect that those leaks are fixed for v3 but not v2.1 ?

Message was edited by: vkoniecz

Dies Koper

You are right.

Note that the places I indicated in #7060 were picked up from the V3
source base. Some of them are not relevant for V2.1 (new code), and V2.1
might have other cases (refactored/removed/already fixed in V3).

Regards,
Dies

glassfish@javadesktop.org wrote:
> Answering to myself.
>
> There is these ones
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=7060
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=9179
>
>
>>From the comments in issue 7060, may I suspect that those leaks are fixed for v3 but not v2 ?
> [Message sent by forum member 'vkoniecz' (vkoniecz)]
>
> http://forums.java.net/jive/thread.jspa?messageID=361317

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net