ICEfaces
  1. ICEfaces
  2. ICE-8663

Potential Memory leak in the Icefaces management code

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-1.8.2.GA_P04
    • Fix Version/s: EE-1.8.2.GA_P05
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces, Tomcat 6.0.18
    • Assignee Priority:
      P2
    • Salesforce Case Reference:

      Description

      The purpose of this JIRA is to investigate a potential memory leak in our code and apply a fix proposed by one of our customers if applicable.

      Customer's description:

      In our application all the contexts used by the same browser in the same application have the same sessionId (cookie JSESSIONID con path=\).
      The map inside com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Monitor uses the sessionId as the key and the value contains a map of contexts related to that sessionId, the problem is that, when the first context is released, the element is removed from the first map and no other contexts with the same sessionId can be released afterwards.


      1. Proposed changes.docx
        14 kB
        Migration
      2. Proposed changes.docx
        14 kB
        Migration

        Activity

        Migration created issue -
        Hide
        Evgheni Sadovoi added a comment - - edited

        Proposed modification to the following classes has been attached as MS Word document.

        core.src.com.icesoft.faces.webapp.http.servlet.SessionDispatcher
        core.src.com.icesoft.faces.webapp.http.servlet.SessionDispatcher.Monitor
        (Restricted to icesoft-internal-developers group)

        Show
        Evgheni Sadovoi added a comment - - edited Proposed modification to the following classes has been attached as MS Word document. core.src.com.icesoft.faces.webapp.http.servlet.SessionDispatcher core.src.com.icesoft.faces.webapp.http.servlet.SessionDispatcher.Monitor (Restricted to icesoft-internal-developers group)
        Hide
        Deryk Sinotte added a comment - - edited

        I've visually examined the changes and they appear to be relatively safe. However, based on the description, I am not able to replicate the issue that they are seeing. I've:

        • Configured Tomcat to run with <Context sessionCookiePath="/"> so that all contexts share the same JSESSIONID cookie.
        • Added a bunch of logging to the SessionDispatcher and Monitor to track the number of Monitors and number of contexts that are being stored.
        • Run two different apps and verified that they are using the same JSESSIONID cookie in the browser (Firebug in this case).
        • Let the session expire and see that the logging shows that the monitors and their contexts are both cleaned up.
          I'm not saying that a problem doesn't exist - just that, from the description, I can't reproduce it. Without being able to reproduce it, I can't verify that it does what it needs to do. I'm not against committing the change but right now I have no way to verify that it fixes anything. Is it possible to get more detailed instructions on how to produce the problem they have?
        Show
        Deryk Sinotte added a comment - - edited I've visually examined the changes and they appear to be relatively safe. However, based on the description, I am not able to replicate the issue that they are seeing. I've: Configured Tomcat to run with <Context sessionCookiePath="/"> so that all contexts share the same JSESSIONID cookie. Added a bunch of logging to the SessionDispatcher and Monitor to track the number of Monitors and number of contexts that are being stored. Run two different apps and verified that they are using the same JSESSIONID cookie in the browser (Firebug in this case). Let the session expire and see that the logging shows that the monitors and their contexts are both cleaned up. I'm not saying that a problem doesn't exist - just that, from the description, I can't reproduce it. Without being able to reproduce it, I can't verify that it does what it needs to do. I'm not against committing the change but right now I have no way to verify that it fixes anything. Is it possible to get more detailed instructions on how to produce the problem they have?
        Hide
        Evgheni Sadovoi added a comment - - edited

        More details from the customer.

        Environment:
        • Liferay 5.2.3 + Tomcat 6.018
        • ICEfaces EE-1.8.2.GA_P04
        • ICEfaces is installed as a shared library
        • Cookies are configured to be all stored under the root context (Tomcat server.xml: <Connector emptySessionPath="true"… />)

        Steps to reproduce:
        1) Install ICEfaces as a shared library in Tomcat
        2) Deploy two separate ICEfaces app .war files to Liferay
        3) Create a new portal page and add 1 portlet from each app to the page (target page)
        4) Log in to the portal
        5) Navigate to the target page
        6) Log out from the portal (invalidate portal session)

        Show
        Evgheni Sadovoi added a comment - - edited More details from the customer. Environment: • Liferay 5.2.3 + Tomcat 6.018 • ICEfaces EE-1.8.2.GA_P04 • ICEfaces is installed as a shared library • Cookies are configured to be all stored under the root context (Tomcat server.xml: <Connector emptySessionPath="true"… />) Steps to reproduce: 1) Install ICEfaces as a shared library in Tomcat 2) Deploy two separate ICEfaces app .war files to Liferay 3) Create a new portal page and add 1 portlet from each app to the page (target page) 4) Log in to the portal 5) Navigate to the target page 6) Log out from the portal (invalidate portal session)
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #32091 Fri Nov 09 11:03:13 MST 2012 deryk.sinotte ICE-8663: customer supplied patch to avoid leaking session monitors in certain environments
        Files Changed
        Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/SessionDispatcher.java
        Hide
        Deryk Sinotte added a comment - - edited

        Community Contribution: Yes
        Resolution: Fixed
        Using VisualVM, I was able to see what looked like a potential leak of the SessionDispatcher.Monitors. Applying the patch seemed to prevent the leak. I tested the patch against our regular component-showcase application there didn't seem to be any bad side-effects. Marking as resolved. Thanks for the patch.

        Show
        Deryk Sinotte added a comment - - edited Community Contribution: Yes Resolution: Fixed Using VisualVM, I was able to see what looked like a potential leak of the SessionDispatcher.Monitors. Applying the patch seemed to prevent the leak. I tested the patch against our regular component-showcase application there didn't seem to be any bad side-effects. Marking as resolved. Thanks for the patch.
        Migration made changes -
        Field Original Value New Value
        Reporter Migration [ remote ] Evgheni Sadovoi [ evgheni.sadovoi ]
        Migration made changes -
        Attachment Proposed changes.docx [ 14900 ]
        Migration made changes -
        Attachment Proposed changes.docx [ 14901 ]
        Migration made changes -
        Assignee Deryk Sinotte [ deryk.sinotte ]
        Fix Version/s EE-1.8.2.GA_P05 [ 10331 ]
        Assignee Priority P2 [ 10011 ]
        Migration made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Security Private [ 10001 ]
        Evgheni Sadovoi made changes -
        Description The purpose of this JIRA is to investigate a potential memory leak in our code and apply a fix proposed by one of our customers if applicable.

        Customer's description:

        In our application all the contexts used by the same browser in the same application have the same sessionId (cookie JSESSIONID con path=\).
        The map inside com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Monitor uses the sessionId as the key and the value contains a map of contexts related to that sessionId, the problem is that, when the first context is released, the element is removed from the first map and no other contexts with the same sessionId can be released afterwards.
        The purpose of this JIRA is to investigate a potential memory leak in our code and apply a fix proposed by one of our customers if applicable.

        Customer's description:

        In our application all the contexts used by the same browser in the same application have the same sessionId (cookie JSESSIONID con path=\).
        The map inside com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Monitor uses the sessionId as the key and the value contains a map of contexts related to that sessionId, the problem is that, when the first context is released, the element is removed from the first map and no other contexts with the same sessionId can be released afterwards.


        Environment:
        • Liferay 5.2.3 + Tomcat 6.018
        • ICEfaces EE-1.8.2.GA_P04
        • ICEfaces is installed as a shared library
        • Cookies are configured to be all stored under the root context (Tomcat server.xml: <Connector emptySessionPath="true"… />)

        Steps to reproduce:
        1) Install ICEfaces as a shared library in Tomcat
        2) Deploy two separate ICEfaces app .war files to Liferay
        3) Create a new portal page and add 1 portlet from each app to the page (target page)
        4) Log in to the portal
        5) Navigate to the target page
        6) Log out from the portal (invalidate portal session)
        Evgheni Sadovoi made changes -
        Description The purpose of this JIRA is to investigate a potential memory leak in our code and apply a fix proposed by one of our customers if applicable.

        Customer's description:

        In our application all the contexts used by the same browser in the same application have the same sessionId (cookie JSESSIONID con path=\).
        The map inside com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Monitor uses the sessionId as the key and the value contains a map of contexts related to that sessionId, the problem is that, when the first context is released, the element is removed from the first map and no other contexts with the same sessionId can be released afterwards.


        Environment:
        • Liferay 5.2.3 + Tomcat 6.018
        • ICEfaces EE-1.8.2.GA_P04
        • ICEfaces is installed as a shared library
        • Cookies are configured to be all stored under the root context (Tomcat server.xml: <Connector emptySessionPath="true"… />)

        Steps to reproduce:
        1) Install ICEfaces as a shared library in Tomcat
        2) Deploy two separate ICEfaces app .war files to Liferay
        3) Create a new portal page and add 1 portlet from each app to the page (target page)
        4) Log in to the portal
        5) Navigate to the target page
        6) Log out from the portal (invalidate portal session)
        The purpose of this JIRA is to investigate a potential memory leak in our code and apply a fix proposed by one of our customers if applicable.

        Customer's description:

        In our application all the contexts used by the same browser in the same application have the same sessionId (cookie JSESSIONID con path=\).
        The map inside com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Monitor uses the sessionId as the key and the value contains a map of contexts related to that sessionId, the problem is that, when the first context is released, the element is removed from the first map and no other contexts with the same sessionId can be released afterwards.


        Evgheni Sadovoi made changes -
        Salesforce Case Reference 5007000000OC4c2AAD
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Evgheni Sadovoi
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: