[jira] Commented: (WW-2996) Memory Leak when SlashesInActionNames is enabled and wildcards are used in actionnames

["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.