Patches that should work on the last rev from both the 2-5-patches and 2-6-patches are now attached to the Jira issue: http://www.ja-sig.org/issues/browse/UP-1816
-Eric Cris J Holdorph wrote: > I apologize if this is in the IRC log. > > two questions. > > 1) why does the pluto 1.1 driver (test portal) not exhibit the same > problem? Do they do something similar to what your patch does for > uPortal? Specifically breaking part of the servlet spec (even though > it probably is ok to do so)? > > 2) Will this change work in other containers? I know that CalPoly > uses WebSphere (or did at some point in the past) and Colorado uses > Resin. > > And a bonus question... > * Does Tomcat 6 implement this optional 'erata' part of the Servlet > spec? That is if, someone spent enough time to get uPortal 2.6.0 > running in Tomcat 6, are they unlikely to see the same problem? > > ---- Cris J H > > Eric Dalquist wrote: >> There is a possible patch for this issue attached to the Jira case: >> http://www.ja-sig.org/issues/browse/UP-1816 >> >> This patch *_HAS NOT_* been extensively tested yet and makes some >> significant changes in the ChannelRender and related code. The Jira >> issue also has a link to yesterday's IRC log which I would recommend >> reading if you are interested in an in-depth discussion about the >> probably underlying issue causing the session bug. >> >> The high level overview is that due to uPortal's multi-threaded >> rendering model the Tomcat requestDispatcher is creating incorrectly >> wrapped HttpServletRequest objects to pass to the portlets for >> rendering. >> >> >> A more detailed overview follows, if there are questions about the >> patch please ask. >> >> Until an errata was recently filed in the servlet 2.4 spec it was >> against spec to allow multiple threads to access the request or >> response objects. The errata changed this so that it is no longer >> against spec but containers can optionally support multi-threaded >> access to these objects. With this wording it is not specifically a >> Tomcat bug, just an optional part of the spec that Tomcat does not >> implement. >> >> The patch involves having the ChannelRenderer.Worker class, which >> invokes rendering on a channel, create a wrapper around the >> HttpServletRequest specific for the thread that Worker is running in. >> The wrapper implements HttpServletRequest directly instead of >> extending HttpServletRequestWrapper to stop Tomcat from un-wrapping >> the wrapper. Passing objects back to the servlet container that are >> not either the original request object or extended from >> HttpServletRequestWrapper is also against the servlet spec, though >> breaking spec compliance in this area should fix the session problem >> and doesn't appear to cause other problems. >> >> The objects, specifically PortalControlStructures, which track the >> request and response through the rendering pipeline have also been >> modified to use ThreadLocals. This allows each rendering thread to >> have its own request and response objects as required by this patch. >> >> This patch is very closely based on code that UW-Madison has been >> running since going live in June 2006. It was not contributed back >> earlier due to both the significance of the changes in the rendering >> pipeline and the thought that the problem being addressed by the >> change was specific to a special case here at UW. >> >> I would encourage people experiencing the session problem and those >> who are familiar with the inner workings of the uPortal channel >> rendering code to try the patch and provide feedback. The patch was >> created against the 2.5-patches branch. Once some testing has been >> done on it confirming its viability I will create a patch for the >> 2.6-patches branch as well. >> >> -Eric >> >> Elliot Metsger wrote: >>> Yup, >>> >>> I pulled HEAD of the 2-6-patches branch, and the buggy behavior >>> still exists.... >>> >>> Parker Grimes wrote: >>>> Elliot, >>>> >>>> Yes we are using uPortal 2.6.0 GA with no custom patches. >>>> getMarkup() in >>>> CPortletAdapter is synchronized. >>>> >>>> -Parker >>>> >>>> On 9/9/07, Elliot Metsger <[EMAIL PROTECTED]> wrote: >>>>> >>>>> Hi Parker, >>>>> >>>>> Quick question: are you using uPortal 2.6.0 GA? Have you applied any >>>>> custom >>>>> patches? >>>>> >>>>> I'm curious if your CPortletAdapter's getMarkup() method is >>>>> synchronized. >>>>> >>>>> >>>>> Parker Grimes wrote: >>>>>> This is sounding very familiar to what we have been experiencing. >>>>>> We use >>>>>> uPortal 2.6.0 and the Spring Portlet MVC. >>>>>> >>>>> -- >>>>> View this message in context: >>>>> http://www.nabble.com/uPortal-Session-Failures--tf4116258.html#a12582790 >>>>> >>>>> Sent from the uPortal - User mailing list archive at Nabble.com. >>>>> >>>>> >>>>> --- >>>>> You are currently subscribed to [EMAIL PROTECTED] as: >>>>> [EMAIL PROTECTED] >>>>> To unsubscribe, change settings or access archives, see >>>>> http://www.ja-sig.org/wiki/display/JSG/uportal-user >>>>> >>>> >>>> --- You are currently subscribed to [EMAIL PROTECTED] >>>> as: [EMAIL PROTECTED] >>>> To unsubscribe, change settings or access archives, see >>>> http://www.ja-sig.org/wiki/display/JSG/uportal-user >>> >>> --- You are currently subscribed to [EMAIL PROTECTED] >>> as: [EMAIL PROTECTED] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-user >
smime.p7s
Description: S/MIME Cryptographic Signature
