Application Server 3  4  5 and 6
  1. Application Server 3 4 5 and 6
  2. JBAS-2299

OutOfMemory error when repetatively deploying and undeploying with 10 minute interval

    Details

    • Type: Feature Request Feature Request
    • Status: Closed Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: JBossAS-4.0.3RC2
    • Fix Version/s: 6.0.0.M1
    • Component/s: Deployers
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Environment:
      WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
    • Similar Issues:
      Show 10 results 

      Description

      Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
      The min and max heap settings were configured as : -Xms128m -Xmx512m
      The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.

      I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.

      The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:

      2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
      2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3@c90207

      { url=null ,addedOrder=0}

      2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
      java.lang.OutOfMemoryError
      2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
      java.lang.OutOfMemoryError
      2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
      java.lang.OutOfMemoryError
      2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null

      The following two jars were added to the server\default\lib folder.
      commons-validator.jar — version 1.1.3
      struts.jar ---- version 1.2.4

      1. Data.txt
        2 kB
        Adrian Brock
      2. deploy-undeploy.sh
        0.4 kB
        Mike Millson
      3. test-jbas-2299.tar.gz
        2.87 MB
        Mike Millson
      4. UndeploymentNotificationListener.java
        3 kB
        Mike Millson
      5. UndeploymentNotificationListenerMBean.java
        0.2 kB
        Mike Millson
      1. paths-from-GC-roots.png
        135 kB
      2. paths-from-gc-roots2.png
        110 kB

        Issue Links

          Activity

          Hide
          Mike Millson
          added a comment -

          Complete project to build notification listener and run test.

          Show
          Mike Millson
          added a comment - Complete project to build notification listener and run test.
          Hide
          Mike Millson
          added a comment -

          I found the issue with the notifcation listener. It was importing com.sun.org.apache.commons.beanutils.MappedPropertyDescriptor from jsf-impl.jar instead of org.apache.commons.beanutils.MappedPropertyDescriptor from commons-beanutils.

          After this change, the notification listener removed commons-beanutils from paths from GC root. I did get OOME, but with a different paths from GC roots to classloader.

          Earlier analysis about the patched commons-beanutils was not quite right. With it I also get OOME, but the test continues to deploy/undeploy. The heap dump is the same as when the notification listener is used, commons-beanutils is not in paths from GC roots. It looks like the patched commons-beanutils and the notification listener are equal in resolving the commons-beanutils leak.

          Show
          Mike Millson
          added a comment - I found the issue with the notifcation listener. It was importing com.sun.org.apache.commons.beanutils.MappedPropertyDescriptor from jsf-impl.jar instead of org.apache.commons.beanutils.MappedPropertyDescriptor from commons-beanutils. After this change, the notification listener removed commons-beanutils from paths from GC root. I did get OOME, but with a different paths from GC roots to classloader. Earlier analysis about the patched commons-beanutils was not quite right. With it I also get OOME, but the test continues to deploy/undeploy. The heap dump is the same as when the notification listener is used, commons-beanutils is not in paths from GC roots. It looks like the patched commons-beanutils and the notification listener are equal in resolving the commons-beanutils leak.
          Hide
          Mike Millson
          added a comment -

          Leaked classloader paths to GC roots after commons-beanutils leak is resolved.

          Show
          Mike Millson
          added a comment - Leaked classloader paths to GC roots after commons-beanutils leak is resolved.
          Hide
          Clebert Suconic
          added a comment -

          Dimitris... I just realized I'm assigned to this task.

          I don't know what else i can do here. I helped Nial@Apache to solve on of the leaks.

          All I can say is upgrade BeanUtils on JBAS Branch.

          If there is anything else to be done here... I don't know what should be done.

          Show
          Clebert Suconic
          added a comment - Dimitris... I just realized I'm assigned to this task. I don't know what else i can do here. I helped Nial@Apache to solve on of the leaks. All I can say is upgrade BeanUtils on JBAS Branch. If there is anything else to be done here... I don't know what should be done.
          Hide
          Dimitris Andreadis
          added a comment -

          The update is done (JBAS-6364), but it took some time to realise apache commons-beanutils is just a test dependency for some jsf/myfaces integration tests, it's not bundled with AS.

          Show
          Dimitris Andreadis
          added a comment - The update is done ( JBAS-6364 ), but it took some time to realise apache commons-beanutils is just a test dependency for some jsf/myfaces integration tests, it's not bundled with AS.

            People

            • Assignee:
              Dimitris Andreadis
              Reporter:
              Amar Syed
            • Votes:
              7 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours
                2h