Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: v3.0.1
    • Fix Version/s: 3.1_ms07
    • Component/s: cdi
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Linux

    • Issuezilla Id:
      12,368
    • Status Whiteboard:
      Hide

      weld-int-required

      Show
      weld-int-required

      Description

      Glassfish v3 and v3.0.1 leak memory when repeatedly redeploying the same
      application.

      The actual use case in our project is that we work with Eclipse and the
      Glassfish plugin so that our application get redeployed automatically whenever
      we save a file. After a couple of edit-save-redeploy cycles, Glassfish throws an
      OutOfMemoryError (either with heap or PermGenSpace) so we have to kill the
      Glassfish process and/or restart Eclipse to continue working which is rather
      annoying.

      This problem first occurred on Glassfish v3 (full profile). Our application uses
      JPA (Hibernate), EJBs (Local Stateless Session Beans), Wicket and CDI injections
      both in the EJB and web layers.

      Taking heap dumps with jvisualvm after a number of redeployments, I could
      observe multiple copies of our application classes loaded by different instances
      of WebappClassLoader. Some of these had a GC root deep down in the Felix module
      storage of the weld-osgi-bundle.

      Having a look at the Glassfish and Weld sources, I noticed that the problem was
      indeed caused by Weld, not by Glassfish: they registered a "singleton per
      classloader" of their Container class and forgot to unregister it on undeployment.

      This bug is fixed in Weld 1.0.1, so then I checked whether a more recent
      Glassfish build would contain this version of Weld (and not the buggy 1.0.0.SP4
      version from Glassfish v3).

      At that time, Glassfish 3.0.1b21 was the most recent promoted build, and it
      contained Weld 1.0.1.SP3, so I gave it a try, and the problem was gone, or at
      least I could redeploy my application a much larger number of times without any
      memory issues.

      I was looking forward to using the official 3.0.1 release instead of the
      promoted build, but unfortunately this release has even more drastic memory
      leaks on repeated redeployment of our application.

      So far, I have no clue what the cause might be, I don't think it is Weld this
      time. Heap dumps do not give much indication either; this time I can see
      multiple instances of WebAppClassLoader most of which do not have a GC root at
      all, and the remaining ones have a GC root in (Timer)Thread.contextClassLoader.

      I'll try to isolate the problem and hopefully attach a small web app to this
      issue to make it reproducible.

      We are using Sun JDK 1.6.0_20 on Ubuntu 10.04 and Windows XP.

        Activity

        Hide
        Sivakumar Thyagarajan added a comment -

        We are waiting for a fix to WELD-570 https://jira.jboss.org/browse/WELD-570 that
        would resolve this and other memory leak issues. Targetting this for MS7

        Show
        Sivakumar Thyagarajan added a comment - We are waiting for a fix to WELD-570 https://jira.jboss.org/browse/WELD-570 that would resolve this and other memory leak issues. Targetting this for MS7
        Hide
        Sivakumar Thyagarajan added a comment -

        Marking as weld-int-required

        Show
        Sivakumar Thyagarajan added a comment - Marking as weld-int-required
        Hide
        Sivakumar Thyagarajan added a comment -

        With the latest integration of Weld 1.1.MS2 [1] and resolution of WELD-570, I
        don't see these leaks anymore. I was able to re-deploy the sample app attached
        with this issue about 40-50 times and did not see a marked increase in Permgen
        space and multiple webappclassloaders being held. Hence I am closing this issue.
        Please let me know or update this issue, if you still see this issue.

        [1] Integration of Weld 1.1.0.Beta2 into GlassFish 3.1 was complete a couple of
        days ago. The trunk (post svn commit 42731) or a nightly after saturday (b30-
        11_13) could be used to test this integration.

        Show
        Sivakumar Thyagarajan added a comment - With the latest integration of Weld 1.1.MS2 [1] and resolution of WELD-570, I don't see these leaks anymore. I was able to re-deploy the sample app attached with this issue about 40-50 times and did not see a marked increase in Permgen space and multiple webappclassloaders being held. Hence I am closing this issue. Please let me know or update this issue, if you still see this issue. [1] Integration of Weld 1.1.0.Beta2 into GlassFish 3.1 was complete a couple of days ago. The trunk (post svn commit 42731) or a nightly after saturday (b30- 11_13) could be used to test this integration.
        Hide
        invinity added a comment -

        Although I haven't dug into the exact memory behavior, I believe I am experiencing this same issue with the currently downloadable version of GF (3.1build43).

        I'm using it with Eclipse 3.6 on Windows 7 64bit and after about 10 deployments of a relatively small application from Eclipse, my GF instance is using 1GB+ of memory and seems to peg one of the cores of my CPU (as it sits nearly constantly at 50% CPU usage). The application is deployed via an EAR project that has one EJB project and one web project under it. The EJBs are using JPA (EclipseLink), but no other EE services and the web project is using JSF and JAX-RS.

        From what I gather looking at the past GF builds, the fix for this bug should be in the release I am using, but can someone in the know confirm this for sure? If I am running a build with the fix, then is there any advice on how to determine, for sure, where my problem is stemming from?

        TIA
        -matt

        Show
        invinity added a comment - Although I haven't dug into the exact memory behavior, I believe I am experiencing this same issue with the currently downloadable version of GF (3.1build43). I'm using it with Eclipse 3.6 on Windows 7 64bit and after about 10 deployments of a relatively small application from Eclipse, my GF instance is using 1GB+ of memory and seems to peg one of the cores of my CPU (as it sits nearly constantly at 50% CPU usage). The application is deployed via an EAR project that has one EJB project and one web project under it. The EJBs are using JPA (EclipseLink), but no other EE services and the web project is using JSF and JAX-RS. From what I gather looking at the past GF builds, the fix for this bug should be in the release I am using, but can someone in the know confirm this for sure? If I am running a build with the fix, then is there any advice on how to determine, for sure, where my problem is stemming from? TIA -matt
        Hide
        saboobaker added a comment -

        We are facing same issue with Glassfish 3.1.1. We notice that when the application is deployed several times (4 or 5 times), glassfish reports permgen out of memory error. We have seen it on Windows as well as Linux platforms. On one of the instances, we do not have embedded eclipse.

        Our project also uses Hibernate and Spring.

        Show
        saboobaker added a comment - We are facing same issue with Glassfish 3.1.1. We notice that when the application is deployed several times (4 or 5 times), glassfish reports permgen out of memory error. We have seen it on Windows as well as Linux platforms. On one of the instances, we do not have embedded eclipse. Our project also uses Hibernate and Spring.

          People

          • Assignee:
            Sivakumar Thyagarajan
            Reporter:
            Harald Wellmann
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: