Details
-
Type:
Bug
-
Status: Closed
-
Priority:
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
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.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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)
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?
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)
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.