Skip to main content

RE: Classloader Leaking

12 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vbkraemer
Offline
Joined: 2003-09-03

Switch away from hibernate... contribute a patch to hibernate that resolves the issue...

mmilanez
Offline
Joined: 2009-01-23

I won't do that. Hibernate is a great framework and I bet no one would give it away because of this problem.

Just as a matter of an observation, I' just tested it with jrockit intead of sun jdk and the problem persists.

vbkraemer
Offline
Joined: 2003-09-03

I understand your reluctance to switch away from hibernate.

So, that seems to leave you with one option: contribute to the hibernate project so the issue gets resolved in that code...

Remember, contributing does not just mean coding. A clear, complete, well-written bug report that describes the issue in detail is a huge 'first step'... Check to see if one is already filed with the project. If there is not one, file one. If there is an issue that looks like the problem you are running into... add comments to it, provide more info (if the issue is weak), etc.

vbk

Stephen Connolly

But hibernate has loggers!

On 5 February 2010 13:34, wrote:

> In my tests, my applications didn't include loggers of any nature. All I
> have is one SSB and 3 Entities, using hibernate. It is the simplest
> application possible, but all these classes stays in memory forever, along
> with their generated Proxies and $__javassist_$$ generated classes.
>
> I think this is a problem with no possible solution. We must learn to live
> with it...
> [Message sent by forum member 'mmilanez' (mmilanez@gmail.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=384983
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
[att1.html]

Stephen Connolly

i.e. the $$__javaassist_$$ generated proxies will have references to the
loggers that hibernate uses for your PU. All of which can munge you up into
permgen hell

On 5 February 2010 13:48, Stephen Connolly
wrote:

> But hibernate has loggers!
>
>
> On 5 February 2010 13:34, wrote:
>
>> In my tests, my applications didn't include loggers of any nature. All I
>> have is one SSB and 3 Entities, using hibernate. It is the simplest
>> application possible, but all these classes stays in memory forever, along
>> with their generated Proxies and $__javassist_$$ generated classes.
>>
>> I think this is a problem with no possible solution. We must learn to live
>> with it...
>> [Message sent by forum member 'mmilanez' (mmilanez@gmail.com)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=384983
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
[att1.html]

mmilanez
Offline
Joined: 2009-01-23

So, no possible solution right? Do you guys also work with hibernate? Is it acceptable to have such a problem?

Dominik Dorn

its actually no (big) problem in production as we
don't reload the app that often like during development.

The problem only arises when the app gets reloaded a few times and
the references stay in memory....thats only happening during development
on our developer machines...

just make sure your ejbs are stateless/singletons and
you will not run into problems.

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

Stephen Connolly

AFAIK, there are two surefire ways to ensure that you leak classloaders...

1. Implement a custom logging level in JUL or log4j if it is present in your
javaee server classloader and that version of log4j takes precidence over
your applications classloader

2. Have log4j on the server lib classpath and store your log4j logger
instances in static fields in each class. (I think the same applies for JUL
logger instances in certain instances)

Both of the above are common enough... and most developers feel that either
looking up the logger instance each time you want to log, or storing the
logger instance as an object field is wastefull of CPU or memory, that I
don;t see that changing any time soon :-(

It would be great if somebody could come up with a "best practice" solution
to this type of issue.

-Stephen

On 4 February 2010 17:54, wrote:

>
> I have had the same issue with Glassfish. As far as I can tell this seems
> to be an issue with every JEE server. I believe the issue stems from
> references that are still being held to the class loader for the application
> even after the application is undeployed. No one seems to implement it
> properly.
>
> Try using -XX:MaxPermSize=1024M so you don't have to reboot as often.
>
>
> -------- Original Message --------
> Subject: Classloader Leaking
> From: glassfish@javadesktop.org
> Date: Thu, February 04, 2010 11:47 am
> To: users@glassfish.dev.java.net
>
> Hello everyone,
>
> I have a memory leak in my application which has been very hard to fix. My
> application classes don't leave the memory after an undeploy. I don't even
> need to use the application, if I just deploy and instantly undeploy, almost
> all of the classes remain in memory. I used jhat and jmap to track them.
>
> Form what I could understand, even the simplest EAR application which uses
> hibernate (and its dependencies) along with Stateless Session Beans, leaks
> memory, and you don't even need to use the application, just deploy and
> undeploy it to see that all the classes remain in memory.
>
> Are there any adivces to have a perfeclty clean undeploy in my server, if
> my application uses EJB and Hibernate? I'm running out of permgen space all
> the time.
>
> My current versions are:
>
> Glassfish 2.1.1 (latest build)
> JDK 1.6 u18
>
> Thanks.
> [Message sent by forum member 'mmilanez' (mmilanez@gmail.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=384822
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net For
> additional commands, e-mail: users-help@glassfish.dev.java.net
[att1.html]

mmilanez
Offline
Joined: 2009-01-23

In my tests, my applications didn't include loggers of any nature. All I have is one SSB and 3 Entities, using hibernate. It is the simplest application possible, but all these classes stays in memory forever, along with their generated Proxies and $__javassist_$$ generated classes.

I think this is a problem with no possible solution. We must learn to live with it...

Dominik Dorn

I've got a theory... maybe these objects don't get whipped away because they are
still referenced... do you have @PreDestroy annotations in your classes? Maybe
one needs to set the references to NULL if the container doesn't do it...

On Fri, Feb 5, 2010 at 2:34 PM, wrote:
> In my tests, my applications didn't include loggers of any nature. All I have is one SSB and 3 Entities, using hibernate. It is the simplest application possible, but all these classes stays in memory forever, along with their generated Proxies and $__javassist_$$ generated classes.
>
> I think this is a problem with no possible solution. We must learn to live with it...
> [Message sent by forum member 'mmilanez' (mmilanez@gmail.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=384983
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

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

mmilanez
Offline
Joined: 2009-01-23

I've tried that already. My Stateless Session Bean has only one field which is an injtected instance of EntityManager. I added a @PReDestroy method to set it to null, but debugging while undeploying, I realized that it was null already.

One thing I came across is that if your hibernate entities contains enums (@Enumerated) then all of them get stuck in memory. If you remove all the enums from there, then they get collected after undeployment. Unfortunatelly, SLSB, proxies and $__javassist__$, are never removed. They stay in the current ClassLoader with no instance associated.

Stephen Connolly

enums have some fancy logic to handle serialization/deserialization which
causes them to stay for a while... but it's logic was written correctly, so
when eventually all references are gone, they can be unloaded.

On 5 February 2010 13:57, wrote:

> I've tried that already. My Stateless Session Bean has only one field which
> is an injtected instance of EntityManager. I added a @PReDestroy method to
> set it to null, but debugging while undeploying, I realized that it was null
> already.
>
> One thing I came across is that if your hibernate entities contains enums
> (@Enumerated) then all of them get stuck in memory. If you remove all the
> enums from there, then they get collected after undeployment.
> Unfortunatelly, SLSB, proxies and $__javassist__$, are never removed. They
> stay in the current ClassLoader with no instance associated.
> [Message sent by forum member 'mmilanez' (mmilanez@gmail.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=384990
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
[att1.html]