Another option that _might_ work is to run with JRockit as your
JRE.... I have been lead to believe that JRockit does not have a
separate PermGen space, and so will not give you PermGen issues....
(Note: I'm guessing at some stage you will get an OOM error using
JRockit... but one would hope that would be after a good few more
re-deployments)
-Stephen (The bringer of rumor and innuendo)
2009/1/30 Dobes Vandermeer <dobesv_at_gmail.com>:
>
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>