ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ciaran Jessup (JIRA)" <j...@apache.org>
Subject [jira] Commented: (ODE-574) Memory leak when Un-deploying processes that contain XSL stylesheets
Date Thu, 09 Apr 2009 12:17:12 GMT

    [ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697489#action_12697489

Ciaran Jessup commented on ODE-574:

After applying your patch, it seems that you're correct the stylesheets aren't cached until
the first run through the process.  I think this is because you've moved the purge out to
a later point in the lifecycle (the un-deploy event that gets fired) so this removes the cached
one that the rehydration would have caused, although it is probably in my previous testing
I had run an item through the process at least once, so thought it was re-hydration pulling
in the resource.  However I don't personally see this as a disadvantage, caching it once when
the resource is first used seems perffectly acceptable to me.   I do however still need to
do the purge after the compile or else I see double oProcess object instances in memory for
the lifetime of the process. (this may not sound like much, but when the process takes up
several hundreds of megabytes this excess data has a definite impact! :)   I'm attaching a
new patch based on your latest revision.

> Memory leak when Un-deploying processes that contain XSL stylesheets
> --------------------------------------------------------------------
>                 Key: ODE-574
>                 URL: https://issues.apache.org/jira/browse/ODE-574
>             Project: ODE
>          Issue Type: Bug
>          Components: BPEL Compilation/Parsing, BPEL Runtime
>         Environment: N/A
>            Reporter: Ciaran Jessup
>         Attachments: cleanup-xsl-cache.patch, memory-leak-all-in-one.patch
> Currently if the BPEL process contains any XSL stylesheets it will not free up *all*
the memory that was allocated during the compilation/dehydration of the process.  This seems
to be because there is a cache of XSLTemplates stored in the XSLTransformHandler, and these
XSLTemplates can sometimes contain (transitive) references back to the OProcess object instances
(via for example the URIResolvers/XPAth Expressions).   Unfortunately this cache lives forever
(crucially even after the process has been un-deployed)  because of this the object graph
hanging from the OProcess object instance is never available for the GC to pick-off.
> There is also another reference issue in the ErrorListener that is associated with the
XSLTransformHandler instance, but I don't really understand that bit of code just as yet,
a patch for the former issue follows, I'm reviewing the ErrorListener issue currently.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message