[
https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697347#action_12697347
]
Karthick Sankarachary commented on ODE-574:
-------------------------------------------
I'm not sure that we want to clear the cache as soon as we're done compiling.
Personally, I would prefer to clear the cache when the process is about to be
undeployed. That way, the runtime gets to see the benefit of the cache, which
was the whole point to begin with.
As for the QName issue in my patch, I took care of it by relying on the
process' "type" as opposed to its "name". Sure enough, it clears the cache just
like you wanted. Also, I merged your fix for the error listener into my patch,
which has been checked in at revision 763467.
Please grab that revision and let me know if it works for you or not.
> 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.
