glassfish
  1. glassfish
  2. GLASSFISH-587

ServletException: PermGen space on deployment when iteratively developing a web application.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 9.0pe
    • Fix Version/s: 9.1pe_dev
    • Component/s: ejb_container
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      587
    • Status Whiteboard:
      Hide

      fixed-9.0peur1

      Show
      fixed-9.0peur1

      Description

      I keep getting the PermGen ServletException on iterative deployments. To get
      around this I have to restart my appserver.

      I find this extremely annoying!! It seems that I have to restart my server
      almost every hour or after 15 re-deploys.

      This may sound like a lot of re-deploys, but when developing a complex JSF/AJAX
      application, this number of re-deployments is nothing. I would average 5-15 per
      hour when critiquing/debugging a small piece of functionality.

      I am using Build 43 of glassfish on windows xp professional with 1.5 Gegs of ram.

      Is this a know issue?? I queried the issues database and didn't find any hits.

      Is there a workaround???

      Attached is a full stacktrace that may be helpful...

      Thanks - Mark

      [#|2006-04-19T11:02:52.406-0700|SEVERE|sun-appserver-pe9.0|javax.enterprise.resource.webcontainer.jsf.application|_Threa
      dID=16;_ThreadName=httpWorkerThread-8080-1;_RequestID=706613d8-498e-4ba4-8602-64466d1bf469;|java.lang.OutOfMemoryError:
      PermGen space
      javax.faces.el.EvaluationException: java.lang.OutOfMemoryError: PermGen space
      at
      javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:9
      1)
      at
      com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:95)
      at javax.faces.component.UICommand.broadcast(UICommand.java:384)
      at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:452)
      at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:764)
      at
      com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
      at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:266)
      at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:132)
      at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
      at
      org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
      at
      org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278)
      at
      org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
      at
      org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
      at
      org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240)
      at
      org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179)
      at
      org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
      at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
      at
      org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
      at
      org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
      at
      com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
      at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
      at
      org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
      at
      org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
      at
      org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
      at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
      at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:231)
      at
      com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)
      at
      com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java:574)
      at
      com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
      at
      com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
      at
      com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
      at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
      at
      com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
      Caused by: java.lang.OutOfMemoryError: PermGen space

      #]

        Issue Links

          Activity

          Hide
          sgtest added a comment -

          testing in observer role

          Show
          sgtest added a comment - testing in observer role
          Hide
          bjb added a comment -

          Is this fixed for 9.0peur1 ?

          I am currently running 9.0.1 build 14 with a JDK1.6.0 FCS with a 1GB allocated
          to the GF VM. I got 1 EAR deployed and about 5 WAR on it. After 3 days, of run,
          I got the permgen leak problem, only solution is to "kill -9" the process.

          Can you clarify if this fixed in 9.0 branch ?

          Best Rgs,
          JB

          Show
          bjb added a comment - Is this fixed for 9.0peur1 ? I am currently running 9.0.1 build 14 with a JDK1.6.0 FCS with a 1GB allocated to the GF VM. I got 1 EAR deployed and about 5 WAR on it. After 3 days, of run, I got the permgen leak problem, only solution is to "kill -9" the process. Can you clarify if this fixed in 9.0 branch ? Best Rgs, JB
          Hide
          jluehe added a comment -

          If you scroll up, you'll see the commits that fixed the issue, and how they've
          been backported to 9.0peur1. For example, search for "Fix has been backported to
          9.0peur1, b02", or "Commit to 9.0peur1".

          Notice that the OutOfMemory problem at the core of this Issue occurred after
          several redeployments. From your description, it is not clear if you are running
          out of memory after several redeployments, or during a "continuous" run. Can you
          please clarify? Thanks!

          Show
          jluehe added a comment - If you scroll up, you'll see the commits that fixed the issue, and how they've been backported to 9.0peur1. For example, search for "Fix has been backported to 9.0peur1, b02", or "Commit to 9.0peur1". Notice that the OutOfMemory problem at the core of this Issue occurred after several redeployments. From your description, it is not clear if you are running out of memory after several redeployments, or during a "continuous" run. Can you please clarify? Thanks!
          Hide
          jluehe added a comment -

          Incremental fix: When stopping a WebappClassLoader (e.g., during the
          undeployment of its associated webmodule), call the newly added:

          com.sun.org.apache.commons.beanutils.MappedPropertyDescriptor.clear()

          to prevent WebappClassLoader leak as shown in this sample reference graph:

          org.apache.commons.beanutils.MappedPropertyDescriptor.declaredMethodCache
          class org.apache.commons.beanutils.MappedPropertyDescriptor) :
          --> java.util.Hashtable@0xed6cf188 (40 bytes) (field table
          --> [Ljava.util.Hashtable$Entry;@0xed249a28 (100 bytes) (Element 1 of
          [Ljava.util.Hashtable$Entry;@0xed249a28
          --> java.util.Hashtable$Entry@0xed6d8eb8 (24 bytes) (field key
          --> class org.apache.struts.tiles.DefinitionsFactoryConfig (84 bytes) (??
          --> org.apache.catalina.loader.WebappClassLoader@0xed6cdc58 (155 bytes)

          Show
          jluehe added a comment - Incremental fix: When stopping a WebappClassLoader (e.g., during the undeployment of its associated webmodule), call the newly added: com.sun.org.apache.commons.beanutils.MappedPropertyDescriptor.clear() to prevent WebappClassLoader leak as shown in this sample reference graph: org.apache.commons.beanutils.MappedPropertyDescriptor.declaredMethodCache class org.apache.commons.beanutils.MappedPropertyDescriptor) : --> java.util.Hashtable@0xed6cf188 (40 bytes) (field table --> [Ljava.util.Hashtable$Entry;@0xed249a28 (100 bytes) (Element 1 of [Ljava.util.Hashtable$Entry;@0xed249a28 --> java.util.Hashtable$Entry@0xed6d8eb8 (24 bytes) (field key --> class org.apache.struts.tiles.DefinitionsFactoryConfig (84 bytes) (?? --> org.apache.catalina.loader.WebappClassLoader@0xed6cdc58 (155 bytes)
          Hide
          jluehe added a comment -

          Commits related to the incremental fix that involves invoking
          MappedPropertyDescriptor.clear() during WebappClassLoader.stop():

          Checking in WebappClassLoader.java;
          /cvs/glassfish/appserv-webtier/src/java/org/apache/catalina/loader/WebappClassLoader.java,v
          <-- WebappClassLoader.java
          new revision: 1.29; previous revision: 1.28
          done
          Checking in MappedPropertyDescriptor.java;
          /m/jws-mirror/jakarta-commons/com-sun-commons-beanutils-1.6.1-src/src/java/com/sun/org/apache/commons/beanutils/MappedPropertyDescriptor.java,v
          <-- MappedPropertyDescriptor.java
          new revision: 1.2; previous revision: 1.1
          done

          Show
          jluehe added a comment - Commits related to the incremental fix that involves invoking MappedPropertyDescriptor.clear() during WebappClassLoader.stop(): Checking in WebappClassLoader.java; /cvs/glassfish/appserv-webtier/src/java/org/apache/catalina/loader/WebappClassLoader.java,v <-- WebappClassLoader.java new revision: 1.29; previous revision: 1.28 done Checking in MappedPropertyDescriptor.java; /m/jws-mirror/jakarta-commons/com-sun-commons-beanutils-1.6.1-src/src/java/com/sun/org/apache/commons/beanutils/MappedPropertyDescriptor.java,v <-- MappedPropertyDescriptor.java new revision: 1.2; previous revision: 1.1 done

            People

            • Assignee:
              jluehe
              Reporter:
              basler
            • Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: