Struts 2
  1. Struts 2
  2. WW-3702

struts2-cdi-plugin - memory never garbage colleted

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.1, 2.2.1.1, 2.2.3, 2.2.3.1
    • Fix Version/s: 2.3.1
    • Component/s: Other
    • Labels:
      None
    • Environment:

      It happens regardless on Linux and Windows OS
      Proble encountered on both Glassfish 3.0.1 and Glassfish 3.1.1
      The JDK used is jdk1.6.0_24

      Description

      Every action execution that contains injected classes consume a small amout of memory that after a while is stored in old-gen. This memory is never released after garbage collection.
      After a few days / week, depending on usage, my applications based on struts2 + struts2-cdi-plugin are no more responsive.
      This forces me to restart the web server.

      1. struts2-cdi-example.7z
        410 kB
        Marco Malavolta

        Activity

        Hide
        Marco Malavolta added a comment - - edited

        Attached the struts2-cdi-example project, modified to reproduce the issue.

        The archive contains also a readme.txt and some screenshots demostrating the problem

        Show
        Marco Malavolta added a comment - - edited Attached the struts2-cdi-example project, modified to reproduce the issue. The archive contains also a readme.txt and some screenshots demostrating the problem
        Hide
        Philip Luppens added a comment -

        Lowered priority to major.

        Show
        Philip Luppens added a comment - Lowered priority to major.
        Hide
        Philip Luppens added a comment - - edited

        Just one thing: in the sample code you've sent, you have the devmode=true setting. Can you confirm that the same memory leak happens when devmode is disabled?

        Show
        Philip Luppens added a comment - - edited Just one thing: in the sample code you've sent, you have the devmode=true setting. Can you confirm that the same memory leak happens when devmode is disabled?
        Hide
        Marco Malavolta added a comment -

        Thank you a lot for the quick reply
        I confirm the same beahviour with devmode=false setting. It takes a lot more time to reach the peak.
        I obtained the same results after about 320000 requests.

        Show
        Marco Malavolta added a comment - Thank you a lot for the quick reply I confirm the same beahviour with devmode=false setting. It takes a lot more time to reach the peak. I obtained the same results after about 320000 requests.
        Hide
        Philip Luppens added a comment -

        Ok, thank you very much for the quick testing. I'll see if I can confirm the results here locally. Any chance you could have a look with MAT or YourKit to see what's leaking? I'll try to have a look here, but I'm currently at work and a bit low on spare time.

        Show
        Philip Luppens added a comment - Ok, thank you very much for the quick testing. I'll see if I can confirm the results here locally. Any chance you could have a look with MAT or YourKit to see what's leaking? I'll try to have a look here, but I'm currently at work and a bit low on spare time.
        Hide
        Maurizio Cucchiara added a comment -

        hi guys,
        unfortunately I have no glassfish environment to reproduce the issue.
        I'll get ASAP and let you know.

        Show
        Maurizio Cucchiara added a comment - hi guys, unfortunately I have no glassfish environment to reproduce the issue. I'll get ASAP and let you know.
        Hide
        Lukasz Lenart added a comment - - edited

        I added a flag to disable internal cache in CDI plugin, by default it's disabled now. It can be enabled again by specifying flag

        struts.cdi.useInternalCache = true

        Could you check with both settings ?

        Show
        Lukasz Lenart added a comment - - edited I added a flag to disable internal cache in CDI plugin, by default it's disabled now. It can be enabled again by specifying flag struts.cdi.useInternalCache = true Could you check with both settings ?
        Hide
        Philip Luppens added a comment -

        Regardless of whether or not this works, it seems pretty bad that we need to set a cache flag to false to counter a memory leak.

        Show
        Philip Luppens added a comment - Regardless of whether or not this works, it seems pretty bad that we need to set a cache flag to false to counter a memory leak.
        Hide
        Maurizio Cucchiara added a comment - - edited

        Hi guys,
        @Lukasz
        I totally agree with Philip, furthermore I don't believe it fixes the problem.

        I have taken a deeper look at this issue last weekend. I also thought that the internal cache could be a potential cause of memory leaks, but setting a breakpoint on the code I realized that there were always 40 objects (not more) inside the cache.
        I ran the code example on Glassfish 3.1.1 and unfortunately I didn't experience the problem that Marco mentioned before (I got the usual sawtooth wave).
        I also changed the code using the Spring Framework, but the outcome is more or less the same.

        @Marco, I could be wrong but can you confirm the java vendor/version?
        Have you experienced this issue in other environments (it could be also a glassfish issue)?

        Also, in order to expedite the memory leak process, I decreased the heap size to 128MB

        Show
        Maurizio Cucchiara added a comment - - edited Hi guys, @Lukasz I totally agree with Philip, furthermore I don't believe it fixes the problem. I have taken a deeper look at this issue last weekend. I also thought that the internal cache could be a potential cause of memory leaks, but setting a breakpoint on the code I realized that there were always 40 objects (not more) inside the cache. I ran the code example on Glassfish 3.1.1 and unfortunately I didn't experience the problem that Marco mentioned before (I got the usual sawtooth wave). I also changed the code using the Spring Framework, but the outcome is more or less the same. @Marco, I could be wrong but can you confirm the java vendor/version? Have you experienced this issue in other environments (it could be also a glassfish issue)? Also, in order to expedite the memory leak process, I decreased the heap size to 128MB
        Hide
        Lukasz Lenart added a comment -

        The idea behind is to remove the cache at all, probably it isn't needed as a CDI implementation should do it for us. It can even be worse as a cache duplication.

        Show
        Lukasz Lenart added a comment - The idea behind is to remove the cache at all, probably it isn't needed as a CDI implementation should do it for us. It can even be worse as a cache duplication.
        Hide
        Philip Luppens added a comment -

        @Lukasz: Agreed. We should probably remove caching at that layer completely.

        Show
        Philip Luppens added a comment - @Lukasz: Agreed. We should probably remove caching at that layer completely.
        Hide
        Marco Malavolta added a comment -

        Hi to all.

        @Maurizio, I can confirm the java version. I also tried to lower the max memory to 256MB from 512MB for glassfish (with 128MB the old gen was nearly full after starting the server and deploying the application) and the application slows 'til unresponsiveness in about half the time (about 156000 requests in 46 minutes), so the beahviour seems predictable.

        I've never tested the application in environments other than glasshfish, cause in my applications I use dependency injection and ejb support.
        I think I will take a look at TomEE in a few days. If the problem doesn't affect it, I'll try to promote the switch in production.

        Just to know, does any of you has experienced the same problem and can confirm it?

        Show
        Marco Malavolta added a comment - Hi to all. @Maurizio, I can confirm the java version. I also tried to lower the max memory to 256MB from 512MB for glassfish (with 128MB the old gen was nearly full after starting the server and deploying the application) and the application slows 'til unresponsiveness in about half the time (about 156000 requests in 46 minutes), so the beahviour seems predictable. I've never tested the application in environments other than glasshfish, cause in my applications I use dependency injection and ejb support. I think I will take a look at TomEE in a few days. If the problem doesn't affect it, I'll try to promote the switch in production. Just to know, does any of you has experienced the same problem and can confirm it?
        Hide
        Maurizio Cucchiara added a comment -

        Ciao Marco,
        we need some more details, could you start to describe your environment in term of resources: architecture, cpu, memory and so on.
        has anyone experienced the issue described by Marco?

        Show
        Maurizio Cucchiara added a comment - Ciao Marco, we need some more details, could you start to describe your environment in term of resources: architecture, cpu, memory and so on. has anyone experienced the issue described by Marco?
        Hide
        Marco Malavolta added a comment - - edited

        Hi to all.

        @Maurizio, here my environment specifications
        -------------------------------------------------------
        Windows 7 Professional (Microsoft Windows version 6.1 Build 7601:Service Pack 1) 64 bit

        Processor: Intel Core i5 CPU 650 @ 3.20GHz 3.33 Ghz
        Ram: 6.00 GB

        jdk1.6.0_24
        GlassFish Server Open Source Edition 3.0.1 (build 22)
        -------------------------------------------------------

        Today i tried different version of GlassFish with the same application.

        I tested these two versions.
        GlassFish Server Open Source Edition 3.1 (build 43)
        GlassFish Server Open Source Edition 3.1.1 (build 12).

        None of them is affected by the issue in my environment, so Maurizio is propably right when he says "it could be also a glassfish issue".

        Now I have to check the production environment where we have both GF 3.0.1 (build 22) and GF 3.1.1 (build 12).
        In both cases the old-gen grows slowly and is never released by garbage collector.

        I'm pretty confused.

        Thank you all for the help

        Show
        Marco Malavolta added a comment - - edited Hi to all. @Maurizio, here my environment specifications ------------------------------------------------------- Windows 7 Professional (Microsoft Windows version 6.1 Build 7601:Service Pack 1) 64 bit Processor: Intel Core i5 CPU 650 @ 3.20GHz 3.33 Ghz Ram: 6.00 GB jdk1.6.0_24 GlassFish Server Open Source Edition 3.0.1 (build 22) ------------------------------------------------------- Today i tried different version of GlassFish with the same application. I tested these two versions. GlassFish Server Open Source Edition 3.1 (build 43) GlassFish Server Open Source Edition 3.1.1 (build 12). None of them is affected by the issue in my environment, so Maurizio is propably right when he says "it could be also a glassfish issue". Now I have to check the production environment where we have both GF 3.0.1 (build 22) and GF 3.1.1 (build 12). In both cases the old-gen grows slowly and is never released by garbage collector. I'm pretty confused. Thank you all for the help
        Hide
        Lukasz Lenart added a comment -

        I leave the cache for now, Weld doesn't provide any caching at this time. It can always be removed in the future.

        Show
        Lukasz Lenart added a comment - I leave the cache for now, Weld doesn't provide any caching at this time. It can always be removed in the future.

          People

          • Assignee:
            Unassigned
            Reporter:
            Marco Malavolta
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development