portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Created: (JS2-1231) Ensure expired (portal) sessions are properly invalidated/recreated
Date Wed, 12 Jan 2011 12:23:47 GMT
Ensure expired (portal) sessions are properly invalidated/recreated

                 Key: JS2-1231
                 URL: https://issues.apache.org/jira/browse/JS2-1231
             Project: Jetspeed 2
          Issue Type: Improvement
          Components: Components Core
    Affects Versions: 2.2.1
         Environment: Websphere 6.1, possibly others too
            Reporter: Ate Douma
            Assignee: Ate Douma
             Fix For: 2.2.2

On certain web containers and especially Websphere, expired session are cleaned up in a background
job which might sometimes take several seconds before executed.
During that "interval" period, incoming requests trying to access such a session might actually
still "see" it, but be confronted with a IllegalStateException when trying to use/access session
And, in portal environments which use cross-context dispatching across multiple web applications
with individual background cleanup of each their sessions, this all might become very tricky
to deal with without being hit by such IllegalStateExceptions.

To prevent this potential problem, I'll add a new static utility method which will check a
(servlet) session if it might already be expired (time-wise) and then invalidate/recreate
it (optionally).
This logic already is used within Pluto PortletRequestImpl.getPortletSession(boolean create)
but that only executes on portlet application level, and actually in some situations makes
things worse if a (also time-wise expired) portal session is kept "alive".

By ensuring this (portal) session check is run at the earliest stage within the portal, combined
with the Jetspeed PortalSessionManager handling, time-wise expired (portal) sessions will
be cleaned up automatically first, as well as possible portlet application sessions too (thanks
to the PortalSessionManager logic).

The best "place" to put this check will be within a top level filter mapped to /*, e.g. like
within the Jetspeed PortalFilter. 
But as not all Jetspeed installations will need/use the Jetspeed PortalFilter (using default
container managed security instead), I'll create a new SessionValidationFilter too and wire
that in the default Portal web.xml.
I also will add the same logic to the Jetspeed PortalFilter, so for those using (only) that
the same logic will be performed.
Note: having both Filters in place doesn't really hurt either: the check will be efficient
if/after a session is (re)created anew.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message