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

Reply via email to