Uploaded image for project: '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
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: JBossAS-4.0.3RC2
    • Fix Version/s: 6.0.0.M1
    • Component/s: Deployers
    • Labels:
      None
    • Environment:

      WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07

      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

        Gliffy Diagrams

        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
            mmillson Mike Millson added a comment -

            Complete project to build notification listener and run test.

            Show
            mmillson Mike Millson added a comment - Complete project to build notification listener and run test.
            Hide
            mmillson 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
            mmillson 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
            mmillson Mike Millson added a comment -

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

            Show
            mmillson Mike Millson added a comment - Leaked classloader paths to GC roots after commons-beanutils leak is resolved.
            Hide
            clebert.suconic 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 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 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 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 Dimitris Andreadis
                Reporter:
                amarsyed 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

                    Development