Lennard,
So I just pulled rel-2-5-patches. Stock install. And I can't replicate
the bug. That's why I indicated in the Jira issue and earlier in this
thread that I'll be testing 2.5 later.
I can replicate the bug in a stock rel-2-6-patches install, and in our
local uPortal installation. JHU runs a heavily (read munged) modified
uPortal 2.5 codebase. We experience the bug, but it isn't a reliable
platform for developing patches against.
I have a modified Tomcat jar and some debugging statements in
CPortletAdapter so I'll take a deeper look rel-2-5-patches and attempt
to figure out why the bug doesn't seem to surface.
Note that there are others on this thread who run 2.5.x code and they do
experience it, so...
Elliot
Lennard Fuller wrote:
I've been following this thread for a while now, and for the life of me
can not see why the portlet web applications that we have running in
uPortal 2.5.3 (using Tomcat 5.5.23) have not suffered these types of
errors. We have multiple web applications with multiple portlets, each
portlet makes use of the portlet session. None of the aforementioned
portlets seem to have exhibited the UP-1816 issue in either user
acceptance testing or production (in use for nearly a year at this
point). The only possible difference that occurs to me that *might* be
related is that we have our tomcat connector configured with
emptySessionPath=true. Even that seems to be something of a long shot.
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
--
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-dev
