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

Ciaran Jessup commented on ODE-574:
-----------------------------------

If you don't clear the cache after the compile, you end up with two instances 
of the oProcess graph in memory each time which uses an un-necessary amount of 
memory ?  By clearing the cache at that point, the extra oProcess will get 
garbage collected and the XSLT cache  just gets re-populated when the 
re-hydration phase kicks in so you still get the cached resources  at runtime 
(this I checked ;) ) ... am I missing something ?

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

Reply via email to