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 attributes.
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-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org
