You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Ciaran Jessup (JIRA)" <ji...@apache.org> on 2009/04/07 22:57:13 UTC

[jira] Updated: (ODE-574) Memory leak when Un-deploying processes that contain XSL stylesheets

     [ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ciaran Jessup updated ODE-574:
------------------------------

    Attachment: StyleSheetCache.patch

This patch should now allow any OProcess instances that happen to be left in memory due to 'belonging' to a cached Stylesheet to be garbage collected when the process that contained the stylesheet is un-deployed.  The patch definately needs reviewing as the with/without slash code I put in seems un-neccessary but I couldn't understand why the multi-key had a terminating slash when the path-to-package wasn't constructed with one wherever I looked ;)


> 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: StyleSheetCache.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.