Yes, you are probably right. Wow, looks like a major pain to resolve,
perhaps I'll live with restarting the appserver until some easier tools come
out.
Maybe one day glassfish can trace all the classes on the application
ClassLoader and somehow ensure that they are all collectible - I'm not sure
how exactly it would do that but it would certainly be possible and save
some real pain for the future generations of Java EE programmers.
Perhaps just enumerating all instances of the classes loaded by that
classloader and its descendants and setting all their fields to zero and
their class pointer to java.lang.Object - it's an agressive tactic but at
least garbage collection could proceed. After all, once something has been
undeployed, it should be gone, and take its objects with it ...
Chris Donaldson wrote:
>
> Hi Dobes,
>
> You may have a classloader leak:
>
> http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
>
> Regards,
> Chris
>
> Dobes Vandermeer wrote:
>> Does anyone know of a way to figure out why I'm running out of PermGen
>> space
>> after multiple redployments? I'd like to cut down the time it takes for
>> me
>> to update the EAR on our server and one sizable component is that I
>> restart
>> the domain each time to avoid running out of PermGen. On my local
>> machine I
>> routinely have to restart glassfish due to PermGen issues.
>>
>> My EAR is using Postgres and Hibernate, and a bunch of other jars. Are
>> there tools and techniques that would allow me to figure out which
>> classes
>> are not being garbage collected?
>>
>> Thanks,
>> Dobes
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>
--
View this message in context: http://www.nabble.com/Diagnosing-PermGen-issues-tp21757212p21757888.html
Sent from the java.net - glassfish users mailing list archive at Nabble.com.