RedirectTrackerManager store request data without warning
---------------------------------------------------------
Key: TOMAHAWK-672
URL: http://issues.apache.org/jira/browse/TOMAHAWK-672
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.5-SNAPSHOT
Reporter: David Delbecq
The redirectTrackerManager store datas it find in the request scope of current
request to restore them after a redirect. However, it does it automatically,
leading to problems at 2 levels
1) It has a default size of 20 redirect, meaning if you create temporary
objects of about 500k in your request (like an xml file to render as an
example) you can end up with 10M / user session, when you have about 30 active
users at the same time (not so improbable if you have session timeout of about
1h), this reach the level of 300M of datas in memory used just by the
TrackerManager! This is too expensive
2) When you design your application, you assume that what is request scope
stays in request scope. There is no recommendation i know of that suggest you
store only serializable objects in request scope. On the other hand, Everything
in Session scope should be serializable. By transfering datas from request
scope to session scope without warning (just including the sandbox.jar is
enough to activate this behaviour), RedirectTrackerManager is breaking the
specs, storing unserializable objects in session, preventing serialization of
the session.
For all those reason, you should:
1) make the RedirectTrackerManager an optional component, not an automic
behaviour as soon as you include the sandbox jar. This would pervent the
surprise of seeing the session size explode, and take into account clustered
environment (in which, for already mentionned serialization reason, the
redirect tracker is by design broken and should not be used)
2) Have the redirectEntryMap field in RedirectTrackerManager marked transient,
to prevent serialization attempts of request scope datas.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
