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, <jcfolsom_at_pureperfect.com> 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_at_javadesktop.org
> Date: Thu, February 04, 2010 11:47 am
> To: users_at_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_at_gmail.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=384822
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net For
> additional commands, e-mail: users-help_at_glassfish.dev.java.net