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] Updated: (ODE-574) Memory leak when Un-deploying processes that contain XSL stylesheets
Date Tue, 07 Apr 2009 21:50:12 GMT

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

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

    Attachment: StopListenersHangingAbout.patch

The attached patch (I think, will confirm in the morning [GMT]) may no longer be neccessary
given the other changes, but I"ve put it in just to be safe, this handles (I think) the case
where the CompileListener ends up associated with items in the Stylesheet cache, as the compileListener
contains a reference to the OProcess this keeps the reference in memory for-ever :( ...  
The other patch may make this patch redundant, will check shortly.   However!  The setErrorListener
method seems particular thread-unsafe, I can't see what guards there are that the TransformerFactory
underlying the cache won't be called from multiple places con-currently, and possibly mis-report
errors ???

> 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: StopListenersHangingAbout.patch, 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.


Mime
View raw message