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