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. Microsoft Word
              Proposed changes.docx
              14 kB
              Migration
            2. Microsoft Word
              Proposed changes.docx
              14 kB
              Migration

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              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
              Permalink
              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
              Permalink
              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)
              Hide
              Permalink
              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.

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: