struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lukasz Lenart (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (WW-4536) potential memory leak with annotationActionValidatorManager
Date Thu, 20 Aug 2015 05:52:45 GMT

    [ https://issues.apache.org/jira/browse/WW-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14703594#comment-14703594
] 

Lukasz Lenart edited comment on WW-4536 at 8/20/15 5:52 AM:
------------------------------------------------------------

I'd suggest a slightly different tact. From the user perspective @SkipValidation should only
need to be applied in a cases where there are two actions on the same class and one requires
a validate() method. Same with an exclude method I would thing. Otherwise, you're putting
the onus on the developer to know that they need to manage a memory issue that wouldn't be
apparent to them :

* it seems like the issue we're seeing is directly related to the parameterized action name.
Is there a way to get at the parameterized action name ahead of being translated e.g. {{/namespace/actionName/\{param\}}}
 instead of {{/namespace/actionName/foo}}? This would reduce the footprint and potential size
of these actions significantly.  If possible, I'd suggest adjusting the default logic to use
the pre-interpolated version if possible
* separately, I would suggest, if possible, to stop tracking Interfaces and AbstractClasses

* Finally, I definitely would suggest making {{buildValidatorKey}} not static to make overrides
feasible.

It occurs to ask -- are we using these paramaterized actions in an unexpected way? Is there
a better way for us to do what we're doing?  We went down this route to try and move logic
out of a URLRewrite engine.


was (Author: abrin):
I'd suggest a slightly different tact. From the user perspective @SkipValidation should only
need to be applied in a cases where there are two actions on the same class and one requires
a validate() method. Same with an exclude method I would thing. Otherwise, you're putting
the onus on the developer to know that they need to manage a memory issue that wouldn't be
apparent to them :

* it seems like the issue we're seeing is directly related to the parameterized action name.
Is there a way to get at the parameterized action name ahead of being translated e.g. {{/namespace/actionName/\\{param\\}}}
 instead of {{/namespace/actionName/foo}}? This would reduce the footprint and potential size
of these actions significantly.  If possible, I'd suggest adjusting the default logic to use
the pre-interpolated version if possible
* separately, I would suggest, if possible, to stop tracking Interfaces and AbstractClasses

* Finally, I definitely would suggest making {{buildValidatorKey}} not static to make overrides
feasible.

It occurs to ask -- are we using these paramaterized actions in an unexpected way? Is there
a better way for us to do what we're doing?  We went down this route to try and move logic
out of a URLRewrite engine.

> potential memory leak with annotationActionValidatorManager
> -----------------------------------------------------------
>
>                 Key: WW-4536
>                 URL: https://issues.apache.org/jira/browse/WW-4536
>             Project: Struts 2
>          Issue Type: Bug
>          Components: XML Validators
>    Affects Versions: 2.3.20
>            Reporter: adam brin
>             Fix For: 2.3.x
>
>         Attachments: Screen Shot 2015-08-16 at 1.48.30 PM.png, Screen Shot 2015-08-16
at 1.49.22 PM.png
>
>
> We've recently been having issues with our app crashing and trying to track down the
root causes.  One of the things we've seen is that over the course of 1 day, 50% of our memory
(almost 620 MB of 1.2 GB)  is allocated to "com.opensymphony.xwork.validator.AnnotationActionValidatorManager"
according to the heap dump. We also see millions of entries in two SynchronizedMap's:
> * validatorCache (1,635,019  entries)
> * validatorFileCache (87,321 entries)
> Looking through the entries in the validator cache, we se entries for every unique page
browsed within the app. Note: we're using staticParam mapping and NamedVariable PatternMatching
in action names e.g. {{"$\{id\}/$\{slug\}"}} so effectively every url is unique.
> Looking at the source code, should these maps perhaps be "WeakHashMaps" or WeakReferences
so that they're disposed of?
> (source code to the app is here: https://bitbucket.org/tdar/tdar.src/src )



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message