Struts 2
  1. Struts 2
  2. WW-3751

Memory leak using jsp tags on an app deployed on glassfish

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: 2.2.1, 2.2.1.1, 2.2.3, 2.3.1, 2.3.1.1
    • Fix Version/s: 2.3.12
    • Component/s: Other
    • Labels:
      None
    • Environment:

      Description

      I have some webapps based on Struts 2 framework.

      I use JSP tags, even sometimes with nested Struts 2 tag (FreeMarker).

      Every time you call with a single jsp jsp tags JspWriterImp a new instance is created with more or less the contents of the tag (instead of reusing the same object stored in memory.

      This causes a loss of memory, because these objects are located in the old generation heap 'til the web application is restarted

      After a few days / weeks depending on the traffic that you need to restart because of irresponsiveness.

      I also created a Jira issue on GlassFish (http://java.net/jira/browse/GLASSFISH-18316), where I posted a screenshot and a sample application to reproduce the problem.

      Basically I'm not sure if it's a struts problem or a problem of glass fish.
      Perhaps the second hypothesis is more likely

      Feel free to close it if you feel that the problem is solely related to Glassfish

      1. screenshot-1 - VisualVM.jpg
        328 kB
        Marco Malavolta
      2. testproject.zip
        11 kB
        Marco Malavolta

        Activity

        Hide
        Lukasz Lenart added a comment -

        Please re-open if you disagree

        Show
        Lukasz Lenart added a comment - Please re-open if you disagree
        Hide
        Lukasz Lenart added a comment -

        Marco Malavolta you can always specify the correct jndi key with struts.objectFactory.cdi.jndiKey as mentioned in docs [1]

        http://struts.apache.org/2.x/docs/cdi-plugin.html#CDIPlugin-Configuration

        Show
        Lukasz Lenart added a comment - Marco Malavolta you can always specify the correct jndi key with struts.objectFactory.cdi.jndiKey as mentioned in docs [1] http://struts.apache.org/2.x/docs/cdi-plugin.html#CDIPlugin-Configuration
        Hide
        Johannes Geppert added a comment -

        The strut2 cdi plugin does not work because it searches the beanManager with those keys: "java:comp/BeanManager" and "java:app/BeanManager".
        Tomcat only allows to bind entries to java:comp/env, so the BeanManager is available at java:comp/env/BeanManager.

        Please open an separate Issue for this Problem.

        Show
        Johannes Geppert added a comment - The strut2 cdi plugin does not work because it searches the beanManager with those keys: "java:comp/BeanManager" and "java:app/BeanManager". Tomcat only allows to bind entries to java:comp/env, so the BeanManager is available at java:comp/env/BeanManager. Please open an separate Issue for this Problem.
        Hide
        Marco Malavolta added a comment -

        The trick does not work.
        After setting jasper to use pool, some other classes than JspWriterImpl hangs on memory and produces the same result.
        Finally I've switched to tomcat, I will reintroduce ejbs once tomee will be released on a final version.

        Only one more thing.
        I followed this instruction http://docs.jboss.org/weld/reference/1.0.0/en-US/html/environments.html in order to add cdi support to tomcat.
        The strut2 cdi plugin does not work because it searches the beanManager with those keys: "java:comp/BeanManager" and "java:app/BeanManager".
        Tomcat only allows to bind entries to java:comp/env, so the BeanManager is available at java:comp/env/BeanManager.

        If you want me to open an issue for the plugin I'll do.

        Show
        Marco Malavolta added a comment - The trick does not work. After setting jasper to use pool, some other classes than JspWriterImpl hangs on memory and produces the same result. Finally I've switched to tomcat, I will reintroduce ejbs once tomee will be released on a final version. Only one more thing. I followed this instruction http://docs.jboss.org/weld/reference/1.0.0/en-US/html/environments.html in order to add cdi support to tomcat. The strut2 cdi plugin does not work because it searches the beanManager with those keys: "java:comp/BeanManager" and "java:app/BeanManager". Tomcat only allows to bind entries to java:comp/env, so the BeanManager is available at java:comp/env/BeanManager. If you want me to open an issue for the plugin I'll do.
        Hide
        Marco Malavolta added a comment -

        Thank you very much Maurizio, we are going to apply your hint today to our staging environments. Fingers Crossed

        Show
        Marco Malavolta added a comment - Thank you very much Maurizio, we are going to apply your hint today to our staging environments. Fingers Crossed
        Hide
        Maurizio Cucchiara added a comment -

        Ciao Marco,
        finally I found the culprit.
        What really differs between Tomcat and Glassfish is the jsp implementation. In fact, according with the Glassfish docs the pool is disabled by default, whereas Tomcat enables it by default.
        Although this is not within my sphere of competence, I guess that if you set the system property "org.apache.jasper.runtime.JspFactoryImpl.USE_POOL" to true it should be work at the same way of Tomcat.
        I will try to find out what is holding the JspFactoryImpl/JspWriterImpl

        Show
        Maurizio Cucchiara added a comment - Ciao Marco, finally I found the culprit . What really differs between Tomcat and Glassfish is the jsp implementation. In fact, according with the Glassfish docs the pool is disabled by default, whereas Tomcat enables it by default . Although this is not within my sphere of competence, I guess that if you set the system property "org.apache.jasper.runtime.JspFactoryImpl.USE_POOL" to true it should be work at the same way of Tomcat. I will try to find out what is holding the JspFactoryImpl/JspWriterImpl
        Hide
        Maurizio Cucchiara added a comment -

        Another thing that I can confirm is that Tomcat reuses the same instances of PageContextImpl and consequently PageContextImpl.
        Glassfish doesn't.

        Show
        Maurizio Cucchiara added a comment - Another thing that I can confirm is that Tomcat reuses the same instances of PageContextImpl and consequently PageContextImpl. Glassfish doesn't.
        Hide
        Maurizio Cucchiara added a comment -

        Ciao Marco,
        I have just tried the example you provided and I can confirm the presence of the issue on Glassfish (apropos, thank you for the accurate and clear test case).
        At the same time, I have to say you that the error does not occur under Tomcat neither under Jetty (which would make me think that this is a Glassfish issue).
        Under both the application servers, the tenured gen memory has never exceeded 20MB in size (though Jetty is much slower than Tomcat).

        I'm trying to understand what really differs from Glassfish and I'll ping you back.

        Show
        Maurizio Cucchiara added a comment - Ciao Marco, I have just tried the example you provided and I can confirm the presence of the issue on Glassfish (apropos, thank you for the accurate and clear test case). At the same time, I have to say you that the error does not occur under Tomcat neither under Jetty (which would make me think that this is a Glassfish issue). Under both the application servers, the tenured gen memory has never exceeded 20MB in size (though Jetty is much slower than Tomcat). I'm trying to understand what really differs from Glassfish and I'll ping you back.
        Hide
        Maurizio Cucchiara added a comment -

        In such case I'll take a deeper look at this during this weekend.

        Show
        Maurizio Cucchiara added a comment - In such case I'll take a deeper look at this during this weekend.
        Hide
        Marco Malavolta added a comment -

        Glassfish's team closed the issue with this explanation:

        "An instance of JspWriterImpl (and its associated response buffer) is created for every request. It should be released at the end of the request. If that is not the case, then someone else is holding on to the page or the request, but this is not the problem with JspWriterImpl per se."

        Can you investigate?

        Show
        Marco Malavolta added a comment - Glassfish's team closed the issue with this explanation: "An instance of JspWriterImpl (and its associated response buffer) is created for every request. It should be released at the end of the request. If that is not the case, then someone else is holding on to the page or the request, but this is not the problem with JspWriterImpl per se." Can you investigate?
        Hide
        Marco Malavolta added a comment - - edited

        Ciao Maurizio,

        This issue is not directly related to WW-3702.
        I fell into two issues, the first (and not the worst in terms of burned memory) was the one reported in WW-3702. It has been solved by glassfish 3.1 release, probably by some fixes on Weld.
        If you have a chance to take a look at the sample app i've posted on glassfish's jira, you will notice that no plugins are involved. I've only linked the latest struts2-core libraries.

        Thank you for your utra fast willingness, which I appreciate a lot.

        Show
        Marco Malavolta added a comment - - edited Ciao Maurizio, This issue is not directly related to WW-3702 . I fell into two issues, the first (and not the worst in terms of burned memory) was the one reported in WW-3702 . It has been solved by glassfish 3.1 release, probably by some fixes on Weld. If you have a chance to take a look at the sample app i've posted on glassfish's jira, you will notice that no plugins are involved. I've only linked the latest struts2-core libraries. Thank you for your utra fast willingness, which I appreciate a lot.
        Hide
        Maurizio Cucchiara added a comment -

        Ciao Marco,
        is this related with WW-3702 in someway?
        No problem for me. We could put the issue on hold at the moment and seeing what happens on the Glassfish side.

        Show
        Maurizio Cucchiara added a comment - Ciao Marco, is this related with WW-3702 in someway? No problem for me. We could put the issue on hold at the moment and seeing what happens on the Glassfish side.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development