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 uportal-dev@lists.ja-sig.org as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
