[
https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ciaran Jessup updated ODE-574:
------------------------------
Attachment: memory-leak-all-in-one.patch
Iv'e merged my previous two patches into a single patch, and removed another
extraneous reference to the oProcess instances. ( Currently when you do a
deploy an oProcess instance is created by the BPEL Compiler, and by the
rehydration phase, these two process I think are identical so not sure why this
needs to happen twice, but without this patch the first (compiler generated
instance) hangs around using up memory that it doesn't need to.
Again this is still using my original baseUri method, but only because the
QName approach wasn't working when I tested it, am still not against that
approach though ;) (these changes remain the same regardless of implementation
of the XSLT purge)
> 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.
