You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "David Delbecq (JIRA)" <de...@myfaces.apache.org> on 2006/09/14 10:57:25 UTC
[jira] Created: (TOMAHAWK-672) RedirectTrackerManager store request
data without warning
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
[jira] Resolved: (TOMAHAWK-672) RedirectTrackerManager behavior
must be disabled by default
Posted by "Mario Ivankovits (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/TOMAHAWK-672?page=all ]
Mario Ivankovits resolved TOMAHAWK-672.
---------------------------------------
Fix Version/s: 1.1.5-SNAPSHOT
Resolution: Fixed
Hi!
I added a policy configuration to customize the data being saved between redirects
New context configuration parameters:
org.apache.myfaces.redirectTracker.MAX_REDIRECTS - Default: 20
Number of redirects to track - required to allow the back-button to work.
org.apache.myfaces.redirectTracker.POLICY - Default: org.apache.myfaces.custom.redirectTracker.policy.NoopRedirectTrackPolicy
The policy used to describe which data to save between requests. This can be any FQN to a class implementing the RedirectTrackerPolicy.
Current implementations are:
* org.apache.myfaces.custom.redirectTracker.policy.FullRedirectTrackPolicy
Captures request beans, local and messages
* org.apache.myfaces.custom.redirectTracker.policy.MessagesRedirectTrackPolicy
Captures FacesMessages only
* org.apache.myfaces.custom.redirectTracker.policy.NoopRedirectTrackPolicy
Captures nothing (the default for JSF backward compatiblity)
> RedirectTrackerManager behavior must be disabled by default
> -----------------------------------------------------------
>
> Key: TOMAHAWK-672
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-672
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: New Component
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: David Delbecq
> Assigned To: Mario Ivankovits
> Fix For: 1.1.5-SNAPSHOT
>
>
> 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
[jira] Commented: (TOMAHAWK-672) RedirectTrackerManager behavior
must be disabled by default
Posted by "Mike Kienenberger (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/TOMAHAWK-672?page=comments#action_12434996 ]
Mike Kienenberger commented on TOMAHAWK-672:
--------------------------------------------
As a temporary workaround, you can remove the phaselistener declaration from the sandbox.jar:/meta-inf/faces-config.xml file.
<phase-listener>org.apache.myfaces.custom.redirectTracker.RedirectTrackerPhaseListener</phase-listener>
> RedirectTrackerManager behavior must be disabled by default
> -----------------------------------------------------------
>
> Key: TOMAHAWK-672
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-672
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: New Component
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: David Delbecq
> Assigned To: Mario Ivankovits
>
> 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
[jira] Commented: (TOMAHAWK-672) RedirectTrackerManager behavior
must be disabled by default
Posted by "Kevin Galligan (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/TOMAHAWK-672?page=comments#action_12435360 ]
Kevin Galligan commented on TOMAHAWK-672:
-----------------------------------------
See bug #503. I added a patch to explicitly enable the redirecttracker on specific requests.
> RedirectTrackerManager behavior must be disabled by default
> -----------------------------------------------------------
>
> Key: TOMAHAWK-672
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-672
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: New Component
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: David Delbecq
> Assigned To: Mario Ivankovits
>
> 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