You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "David Greenwald (JIRA)" <ji...@apache.org> on 2009/02/12 16:07:46 UTC
[jira] Created: (WW-2996) Memory Leak when SlashesInActionNames is
enabled and wildcards are used in actionnames
Memory Leak when SlashesInActionNames is enabled and wildcards are used in actionnames
--------------------------------------------------------------------------------------
Key: WW-2996
URL: https://issues.apache.org/struts/browse/WW-2996
Project: Struts 2
Issue Type: Bug
Components: Core Interceptors
Affects Versions: 2.0.11
Environment: *nix, Java 1.6
Reporter: David Greenwald
Priority: Critical
Struts 2 leaks memory when SlashesInActionNames is enabled and action mappings with wildcards are used. The problem is in the AnnotationActionValidatorManager which maintains a cache of the Validators. If an action is defined along the lines of "actionname/*" where what the wildcard matches isn't a finite list you end up with one validator in memory for each unique request.
eg: A request for /actionname/foo and /actionname/bar causes two validator objects to be cached even though they are mapped to the same action.
The AnnotationActionValidatorManager class assumes a finite number of Validators will need to be created, and thus has no mechanism to limit the maximum size of the cache.
I believe the solution is probably to change the key to the cache so that the widecards are respected by the cache (i.e. /actionname/foo and /actionname/bar result in only one validation object being created).
In my specific case this leak worked out to be about a gig of heap a day on an application that takes a little over a million unique hits a day. I was able to resolve this issue by removing the validation interceptor which was acceptable because I had used validate() methods in the actions which is called by the workflow interceptor at which point the application could run with 256 meg of heap.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2996) Memory Leak when SlashesInActionNames
is enabled and wildcards are used in actionnames
Posted by "Musachy Barroso (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45803#action_45803 ]
Musachy Barroso commented on WW-2996:
-------------------------------------
I was able to replicate this, I totally missed (nah? really?) the slashes in the name part. I don't see how putting slashes in an action name is a healthy thing to do but this needs to be fixed.
> Memory Leak when SlashesInActionNames is enabled and wildcards are used in actionnames
> --------------------------------------------------------------------------------------
>
> Key: WW-2996
> URL: https://issues.apache.org/struts/browse/WW-2996
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.0.11
> Environment: *nix, Java 1.6
> Reporter: David Greenwald
> Priority: Blocker
> Fix For: 2.1.7
>
>
> Struts 2 leaks memory when SlashesInActionNames is enabled and action mappings with wildcards are used. The problem is in the AnnotationActionValidatorManager which maintains a cache of the Validators. If an action is defined along the lines of "actionname/*" where what the wildcard matches isn't a finite list you end up with one validator in memory for each unique request.
> eg: A request for /actionname/foo and /actionname/bar causes two validator objects to be cached even though they are mapped to the same action.
> The AnnotationActionValidatorManager class assumes a finite number of Validators will need to be created, and thus has no mechanism to limit the maximum size of the cache.
> I believe the solution is probably to change the key to the cache so that the widecards are respected by the cache (i.e. /actionname/foo and /actionname/bar result in only one validation object being created).
> In my specific case this leak worked out to be about a gig of heap a day on an application that takes a little over a million unique hits a day. I was able to resolve this issue by removing the validation interceptor which was acceptable because I had used validate() methods in the actions which is called by the workflow interceptor at which point the application could run with 256 meg of heap.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-2996) Memory Leak when SlashesInActionNames is
enabled and wildcards are used in actionnames
Posted by "Musachy Barroso (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Musachy Barroso updated WW-2996:
--------------------------------
Fix Version/s: 2.1.7
> Memory Leak when SlashesInActionNames is enabled and wildcards are used in actionnames
> --------------------------------------------------------------------------------------
>
> Key: WW-2996
> URL: https://issues.apache.org/struts/browse/WW-2996
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.0.11
> Environment: *nix, Java 1.6
> Reporter: David Greenwald
> Priority: Blocker
> Fix For: 2.1.7
>
>
> Struts 2 leaks memory when SlashesInActionNames is enabled and action mappings with wildcards are used. The problem is in the AnnotationActionValidatorManager which maintains a cache of the Validators. If an action is defined along the lines of "actionname/*" where what the wildcard matches isn't a finite list you end up with one validator in memory for each unique request.
> eg: A request for /actionname/foo and /actionname/bar causes two validator objects to be cached even though they are mapped to the same action.
> The AnnotationActionValidatorManager class assumes a finite number of Validators will need to be created, and thus has no mechanism to limit the maximum size of the cache.
> I believe the solution is probably to change the key to the cache so that the widecards are respected by the cache (i.e. /actionname/foo and /actionname/bar result in only one validation object being created).
> In my specific case this leak worked out to be about a gig of heap a day on an application that takes a little over a million unique hits a day. I was able to resolve this issue by removing the validation interceptor which was acceptable because I had used validate() methods in the actions which is called by the workflow interceptor at which point the application could run with 256 meg of heap.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-2996) Memory Leak when SlashesInActionNames is
enabled and wildcards are used in actionnames
Posted by "Musachy Barroso (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Musachy Barroso updated WW-2996:
--------------------------------
Priority: Blocker (was: Critical)
> Memory Leak when SlashesInActionNames is enabled and wildcards are used in actionnames
> --------------------------------------------------------------------------------------
>
> Key: WW-2996
> URL: https://issues.apache.org/struts/browse/WW-2996
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.0.11
> Environment: *nix, Java 1.6
> Reporter: David Greenwald
> Priority: Blocker
>
> Struts 2 leaks memory when SlashesInActionNames is enabled and action mappings with wildcards are used. The problem is in the AnnotationActionValidatorManager which maintains a cache of the Validators. If an action is defined along the lines of "actionname/*" where what the wildcard matches isn't a finite list you end up with one validator in memory for each unique request.
> eg: A request for /actionname/foo and /actionname/bar causes two validator objects to be cached even though they are mapped to the same action.
> The AnnotationActionValidatorManager class assumes a finite number of Validators will need to be created, and thus has no mechanism to limit the maximum size of the cache.
> I believe the solution is probably to change the key to the cache so that the widecards are respected by the cache (i.e. /actionname/foo and /actionname/bar result in only one validation object being created).
> In my specific case this leak worked out to be about a gig of heap a day on an application that takes a little over a million unique hits a day. I was able to resolve this issue by removing the validation interceptor which was acceptable because I had used validate() methods in the actions which is called by the workflow interceptor at which point the application could run with 256 meg of heap.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2996) Memory Leak when SlashesInActionNames
is enabled and wildcards are used in actionnames
Posted by "Musachy Barroso (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45624#action_45624 ]
Musachy Barroso commented on WW-2996:
-------------------------------------
I am trying to replicate this but I haven't been able so far. I am trying in showcase, there is an action mapping like:
<action name="edit-*" class="org.apache.struts2.showcase.action.EmployeeAction">
.....
</action>
now the method build the cache key is:
protected static String buildValidatorKey(Class clazz, String context) {
StringBuilder sb = new StringBuilder(clazz.getName());
sb.append("/");
sb.append(context);
return sb.toString();
}
which uses the class and the method(context) to build the key. So calling edit-1.action and edit-2.action always results on the same key being built(org.apache.struts2.showcase.action.EmployeeAction/save). Am I missing something?
> Memory Leak when SlashesInActionNames is enabled and wildcards are used in actionnames
> --------------------------------------------------------------------------------------
>
> Key: WW-2996
> URL: https://issues.apache.org/struts/browse/WW-2996
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.0.11
> Environment: *nix, Java 1.6
> Reporter: David Greenwald
> Priority: Blocker
>
> Struts 2 leaks memory when SlashesInActionNames is enabled and action mappings with wildcards are used. The problem is in the AnnotationActionValidatorManager which maintains a cache of the Validators. If an action is defined along the lines of "actionname/*" where what the wildcard matches isn't a finite list you end up with one validator in memory for each unique request.
> eg: A request for /actionname/foo and /actionname/bar causes two validator objects to be cached even though they are mapped to the same action.
> The AnnotationActionValidatorManager class assumes a finite number of Validators will need to be created, and thus has no mechanism to limit the maximum size of the cache.
> I believe the solution is probably to change the key to the cache so that the widecards are respected by the cache (i.e. /actionname/foo and /actionname/bar result in only one validation object being created).
> In my specific case this leak worked out to be about a gig of heap a day on an application that takes a little over a million unique hits a day. I was able to resolve this issue by removing the validation interceptor which was acceptable because I had used validate() methods in the actions which is called by the workflow interceptor at which point the application could run with 256 meg of heap.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2996) Memory Leak when SlashesInActionNames
is enabled and wildcards are used in actionnames
Posted by "Musachy Barroso (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46608#action_46608 ]
Musachy Barroso commented on WW-2996:
-------------------------------------
this was fixed in r1954 in xwork.
> Memory Leak when SlashesInActionNames is enabled and wildcards are used in actionnames
> --------------------------------------------------------------------------------------
>
> Key: WW-2996
> URL: https://issues.apache.org/struts/browse/WW-2996
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.0.11
> Environment: *nix, Java 1.6
> Reporter: David Greenwald
> Priority: Blocker
> Fix For: 2.1.7
>
>
> Struts 2 leaks memory when SlashesInActionNames is enabled and action mappings with wildcards are used. The problem is in the AnnotationActionValidatorManager which maintains a cache of the Validators. If an action is defined along the lines of "actionname/*" where what the wildcard matches isn't a finite list you end up with one validator in memory for each unique request.
> eg: A request for /actionname/foo and /actionname/bar causes two validator objects to be cached even though they are mapped to the same action.
> The AnnotationActionValidatorManager class assumes a finite number of Validators will need to be created, and thus has no mechanism to limit the maximum size of the cache.
> I believe the solution is probably to change the key to the cache so that the widecards are respected by the cache (i.e. /actionname/foo and /actionname/bar result in only one validation object being created).
> In my specific case this leak worked out to be about a gig of heap a day on an application that takes a little over a million unique hits a day. I was able to resolve this issue by removing the validation interceptor which was acceptable because I had used validate() methods in the actions which is called by the workflow interceptor at which point the application could run with 256 meg of heap.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WW-2996) Memory Leak when SlashesInActionNames is
enabled and wildcards are used in actionnames
Posted by "Musachy Barroso (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Musachy Barroso resolved WW-2996.
---------------------------------
Resolution: Fixed
Fixed in struts and xwork trunk. The solution was to use the actionConfig.getName() (which is the name from the xml), instead of the action name (the one in the url), so the key is the same for all the patterns of an action that has wildcards
> Memory Leak when SlashesInActionNames is enabled and wildcards are used in actionnames
> --------------------------------------------------------------------------------------
>
> Key: WW-2996
> URL: https://issues.apache.org/struts/browse/WW-2996
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.0.11
> Environment: *nix, Java 1.6
> Reporter: David Greenwald
> Priority: Blocker
> Fix For: 2.1.7
>
>
> Struts 2 leaks memory when SlashesInActionNames is enabled and action mappings with wildcards are used. The problem is in the AnnotationActionValidatorManager which maintains a cache of the Validators. If an action is defined along the lines of "actionname/*" where what the wildcard matches isn't a finite list you end up with one validator in memory for each unique request.
> eg: A request for /actionname/foo and /actionname/bar causes two validator objects to be cached even though they are mapped to the same action.
> The AnnotationActionValidatorManager class assumes a finite number of Validators will need to be created, and thus has no mechanism to limit the maximum size of the cache.
> I believe the solution is probably to change the key to the cache so that the widecards are respected by the cache (i.e. /actionname/foo and /actionname/bar result in only one validation object being created).
> In my specific case this leak worked out to be about a gig of heap a day on an application that takes a little over a million unique hits a day. I was able to resolve this issue by removing the validation interceptor which was acceptable because I had used validate() methods in the actions which is called by the workflow interceptor at which point the application could run with 256 meg of heap.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.