 |
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Elliot Metsger [05/Sep/07 11:13 PM]
The affected versions are set according to what users have reported on the list.
Attaching debug level output (reserves-numbered.log) from a JHU portlet exemplifying the issue. The output was captured by rendering the portlet 4 times. The first time the portlet is rendered, objects are initialized and placed into the session. On the three subsequent requests, the objects are retrieved from the session.
It appears that the PortletContext referenced by the PortletSession is improperly managed. If the PortletContext is improperly managed, then it may indicate a broader issue. Lines 1 and 2 set two objects into the session on request number 1. Line 6 prints out the session on request number 2. Note that the objects set on the first request are still present. Line 13 prints out the session on request number 3. Same objects still present. Line 20 prints out the session on request number 4. Objects are missing. Same session id. Different portlet context name. What follows is a high level description of what I think the issue is... the details are gory.
CPortletAdapter is accessed by multiple threads simultaneously attempting to render the same http request object. Ultimately CPortletAdapter calls the Pluto container to render the request, which is performed using cross-context dispatch. When Tomcat is performing request dispatching, it unwraps the request down to the first Tomcat-specific concrete request object it finds, wraps that with a Tomcat ApplicationHttpRequest, then performs the dispatch. If thread X is dispatching request A, Tomcat will insert an ApplicationHttpRequest wrapper in the wrapping chain. Thread Y is simultaneously dispatching request A, and so Tomcat will insert an additional ApplicationHttpRequest wrapper into the wrapping chain. This leads to a condition where different threads may observe the request with only a single ApplicationHttpRequest wrapper or - after it has been wrapped a second time - with two ApplicationHttpRequest wrappers. The ApplicationHttpRequest wrapper (at least in Tomcat 5.5.23) is responsible for managing the SessionFacade which is returned to callers of getPortletSession(). A request wrapped with only one ApplicationHttpRequest returns a different SessionFacade than the request wrapped with two ApplicationHttpRequest objects. So it is possible for a Pluto PortletRequest to obtain the correct SessionFacade (the SessionFacade is what backs the Pluto PortletSession) on one request, but it may obtain a different SessionFacade on subsequent requests, if the request is affected by this race condition and has been doubly-wrapped with the ApplicationHttpRequest. I can confirm that on a build of r4249 of the https://developer.ja-sig.org/svn/up2/branches/rel-2-6-patches
 branch - HEAD at the time of this comment - that this bug exists on Tomcat 5.5.23, Pluto 1.0.1.
Time for more debugging.... Sorry - not r4249 but r42431 of https://developer.ja-sig.org/svn/up2/branches/rel-2-6-patches
Eric Dalquist at the University of Wisconsin has offered to supply a patch that we think addresses this issue. Eric has (thank you thank you) offered to patch both the 2.5 and 2.6 patches branch.
After the patch has been committed, JHU will be testing the patch, and I'll email the uportal users list and ask the other affected schools to test as well. Chat transcripts from the past few days may be instructional, here is a link to the transcript for 9/11: http://www.ja-sig.org/wiki/x/LANz
Transcripts from earlier days also have discussion about this issue. Possible fix for session issue. Involves adding a custom wrapper than tomcat can't un-wrap to each request before it is rendered and adding ThreadLocals for tracking render parameters and request/response objects.
The patch was generated against the 2.5-patches branch rev 42374 JHU has tested the 2.6 patch on HEAD of the rel-2-6-patches branch with Pluto 1.0.1 and Tomcat 5.5.23 and Spring 2.0.6. It seems to fix the issue for us! I'll be testing the 2.5 patch shortly.
I had to patch part of it by hand, but after that I was able to 'make my problem not appear'. Hard to prove it's gone completely, because it was never completely deterministic, but since applying the patch I haven't seen the problem again.
uPortal 2.6.0GA + patch, Tomcat 5.5.23, HSQLDB 1.8.0.7 I also had to patch part of it by hand, specifically PortalControlStructures.java. We have NOT experienced the problem since applying the patch. We were having session problems very consistently before the patch and have not had any session problems since the patch.
uPortal 2.6.1 RC1, Tomcat 5.5.23, Oracle 10g | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Objects attached to a PortletSession randomly disappear
