geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Janko Heilgeist (JIRA)" <j...@apache.org>
Subject [jira] Commented: (GERONIMO-4543) EAR classloader not garbage collected
Date Fri, 20 Feb 2009 07:19:01 GMT

    [ https://issues.apache.org/jira/browse/GERONIMO-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675265#action_12675265
] 

Janko Heilgeist commented on GERONIMO-4543:
-------------------------------------------

Hi Kevan,

I've set my JAVA_OPTS to "-XX:MaxPermSize=265m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled"
for some time now and never saw any OOM errors. But last Friday I must have accidentally reset
the environment variable somehow without noticing it. On Monday I started seeing the OOM PermGen
space errors immediately during first deployment and began investigating the cause. I didn't
recognize the missing JAVA_OPTS and instead debugged the application with jmap/jhat. Thus,
I noticed that the classes of my EAR never get GCed after undeploying and that got me hooked
up on the issue. Shortly after, I switched back to the old JAVA_OPTS and everything worked
again. But its just my own private Geronimo installation for development purposes that gets
restarted a few times a day. So the OOM may be pushed back long enough to never occur.

So much for the background. I currently just deploy/undeploy my app and don't actually drive
it. I already noticed a few additional issues when I enable an included Quartz scheduled job
and when I call my JUnitE2 test cases. For now, I've disabled them and focus just on getting
the app GCed after a single deploy/undeploy. I also noticed that the PermGen space increases
minimally (that is a few KB maybe) with each deploy/undeploy cycle. It's not a serious issue
yet but I'll investigate it further if it continues.

I've only seen the EAR's MultiParentClassLoader, its child WAR's MultiParentClassLoader, and
an intermediate ChildConfigurationClassLoader not being GCed. SUN's Frank Kieviet describes
a servlet in his blog, that repeatedly loads a class with its own classloader to force a PermGen
space GC. Thus, the relevant classloaders should have been GCed if they had been eligible.

> EAR classloader not garbage collected
> -------------------------------------
>
>                 Key: GERONIMO-4543
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-4543
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: Memory Leaks, transaction manager
>    Affects Versions: 2.2
>            Reporter: Janko Heilgeist
>            Priority: Blocker
>             Fix For: 2.2
>
>         Attachments: ear-with-tx.tar.gz, privileged_currenttime.patch
>
>
> The TransactionTimer$CurrentTime thread inherits the AccessControlContext of the first
EAR/WAR/EJB-jar that carries out a transaction. Thus, the particular EAR/WAR/EJB-jar's classloader
is prevented from being GCed.
> See http://www.nabble.com/PermGen-space-issues-td22079768s134.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message