uPortal Session Failures?
|
| 1 2 |
|
|
||||||||
|
|
||||||||
|
In reply to this post
by Parker Grimes
|
||||||||
|
|
In reply to this post
by Elliot Metsger
|
||||||||
|
Elliot,
Has JHU back-ported the CPortletAdapter switch from IMultithreadedChannel to IChannel? I'm trying to figure out why we (UW) aren't seeing this at all and one thing that did change with 2.5.3 was switching the portlet adapter from a multithreaded to regular channel. Perhaps there was some synchronization going on with the multithreaded channel that isn't happening any more? The other local change that we have that I'm not sure the trunk has is we add a custom HttpServletRequest wrapper (doesn't use the spec provided HttpServletRequestWrapper) around the real request before handing it to each channel for rendering. This was a fix for a concurrent JSP rendering issue that we ran into but were never able to replicate in the core codebase. The purpose of this wrapper is to stop tomcat from un-wrapping so far down and providing a single request object for each rendering thread. -Eric Elliot Metsger wrote: > So I've posted observations on what I think is happening at > http://www.ja-sig.org/issues/browse/UP-1816 > > If I put only one instance of my portlet on one tab on our staging > server, it never crashes. If I put a different portlet up on the same > tab, so that when I click two different portlets are being rendered > instead of just one, I cause the crash in 3 to 5 clicks. > > It appears that there is a race condition caused by CPortletAdapter > when it attempts to render the same request object in two different > threads. > > When Pluto performs cross context dispatch to the portlet webapp, > Tomcat will insert its own request wrapper into the wrapper chain. So > the first thread to dispatch gets the first Tomcat request wrapper > inserted, and the second thread to dispatch has a second Tomcat > request wrapper inserted. > > Unfortunately, the Tomcat request wrappers affect what PortletSession > you get when calling getPortletSession() on your PortletRequest... So > depending on when you call getPortletSession() you may get the correct > PortletSession or not... > > I'm sure we'll be discussing in the IRC chat room Monday regarding > whether or not this is the correct theory, and if it is, what to do > about it. I'll need some help from other developers to kick this > theory around and figure out what the right solution is. > > Elliot > > > > Elliot Metsger wrote: >> >> I think I am seeing this behavior in a patched uP 2.5.2. I'm doing some >> digging, but it appears that randomly objects go missing from the >> portlet >> session object. If I find anything I'll follow up on the thread. >> >> In the mean time did you find the cause of your problam Conan? >> >> Thanks, >> Elliot >> >> >> Conan Cook wrote: >>> Dear uPortal Folk, >>> >>> We've had the occasional issue that appears to be the result of the >>> session failing to return an object when it should. It's an >>> intermittent fault and we are unable to reproduce it reliably; it >>> usually shows up as a NullPointerException being thrown when trying to >>> use an object that was pulled off the session. Most recently we >>> noticed >>> it in a bookmarks portlet that we have, but there doesn't appear to be >>> any logical way of the object not being on the session as expected. >>> Here's a code snippet to show what I mean: >>> >>> In our doView method we have: >>> >>> BookmarksXMLManager manager = (BookmarksXMLManager) >>> session.getAttribute("manager"); >>> if(manager == null){ >>> manager = new BookmarksXMLManager(username, title); >>> session.setAttribute("manager", manager); >>> } >>> >>> >>> In our processAction method we have: >>> >>> BookmarksXMLManager manager = (BookmarksXMLManager) >>> session.getAttribute("manager"); >>> Document xml = manager.getBookmarksXML(); >>> >>> >>> The final line threw a NullPointerException. I can't see a logical way >>> for the session not to contain a BookmarksXMLManager object called >>> "manager" by the time it is pulled off and used in processAction. >>> We've >>> seen very similar behaviour in a number of other portlets, but quite >>> rarely and never consistently. Does anyone know of a reason this might >>> happen? We're running 2.5.3. >>> >>> Conan Cook >>> Applications Developer (Java) >>> Academic Technologies Group (ATG) >>> University of the West of England >>> Frenchay Campus >>> Bristol BS16 1QY >>> >>> email: [hidden email] >>> telephone: 01173 281 053 >>> >>> >>> >>> This email was independently scanned for viruses by McAfee anti-virus >>> software and none were found >>> >>> --- You are currently subscribed to [hidden email] as: >>> %%emailaddr%% >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-user >>> >> > > --- You are currently subscribed to [hidden email] as: > [hidden email] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-user |
||||||||
smime.p7s (4K) |
|
|
||||||||
|
In reply to this post
by Elliot Metsger
|
||||||||
|
|
|
||||||||
|
In reply to this post
by Elliot Metsger
|
||||||||
|
|
In reply to this post
by Elliot Metsger
Some javascript/style in this post has been disabled (why?)
There is a possible patch for this issue attached to the Jira case:
http://www.ja-sig.org/issues/browse/UP-1816This 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, |
||||||||
|
|
Some javascript/style in this post has been disabled (why?)
Note that patches based both the 2-5-patches and 2-6-patches branches
are now attached to the issue.-Eric 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 |
||||||||
|
|
In reply to this post
by Eric Dalquist
|
||||||||
|
|
|
||||||||
|
|
Some javascript/style in this post has been disabled (why?)
Glad to hear it is working for you and thanks for the report, it really
helps to make sure the patch is good enough to be applied to the core
code base.One thing I'd like to hear from folks testing the patch is how many and what types of channels they are using. I'm reasonably confident the patch won't cause any problems with portlets since we've been running a version of it here for over a year. We don't really use any channels though so I want to make sure there aren't going to be unintended effects in that area. -Eric Parker Grimes wrote: Well so far so good! I installed the patch on our system (2.6.1 RC1) and the problem appears to be fixed. Nice job figuring this out. We will keep testing over the next couple of days, but I am eager to put it into production asap. |
||||||||
|
|
|
||||||||
|
|
In reply to this post
by Elliot Metsger
I've heard from a few people that have tested the patch and are seeing
good results. If I could get those that have tested the patch to comment on the Jira case: http://www.ja-sig.org/issues/browse/UP-1816 so I know who has tested it and how it is working for them? Thank you, -Eric Elliot Metsger wrote: > I'm so happy (spinning in my office chair) to report that the patch > for 2.6 attached to http://www.ja-sig.org/issues/browse/UP-1816 seems > to work for us here at JHU. > > As Eric says this patch needs to be heavily tested before going into > svn. If everyone who experienced this issue would take some time to > verify that it fixes the problem, it would be really appreciated. > That will facilitate the patch being accepted into svn all the quicker. > > I'm still working on testing the 2.5 patch. > > Thanks everyone, > > Elliot > > > 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 <[hidden email]> 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 [hidden email] as: >>>>> [hidden email] >>>>> To unsubscribe, change settings or access archives, see >>>>> http://www.ja-sig.org/wiki/display/JSG/uportal-user >>>>> >>>> --- You are currently subscribed to [hidden email] >>>> as: [hidden email] >>>> To unsubscribe, change settings or access archives, see >>>> http://www.ja-sig.org/wiki/display/JSG/uportal-user >>> --- You are currently subscribed to [hidden email] >>> as: [hidden email] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-user >> > > --- You are currently subscribed to [hidden email] as: > [hidden email] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-user |
||||||||
|
|
In reply to this post
by Eric Dalquist
Some javascript/style in this post has been disabled (why?)
Parker,I believe you may be experiencing this: http://www.ja-sig.org/issues/browse/UP-1869 If you click on the fisheye tab in Jira you can see what changes were made to resolve the issue. -Eric Parker Grimes wrote: I may have just come across the first problem with this patch... or maybe it is an issue that just wasn't resolved by this patch. |
||||||||
|
|
|
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
