[jira] Resolved: (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: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.