[
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-2.patch
This patch has been re-generated against the latest SVN HEAD. It does the
following:
1) Adds a synchronisation block around the templates removeAll call.
2) Adds a call to purge just after an oProcess has been compiled.
3) In my previous patch I very deliberately didn't set the 'ErrorListener' to
null as my reading of the java specification in this area suggests that doing
that should cause a null-pointer, I'm unsure that it is safe to do what the
current SVN HEAD does, but I'm happy to be shown to be wrong :)
I still don't really understand why purging based on the filepath was a bad
idea, as these are file-based resources that are being deleted, however I'll
bow down to your expertise and better judgement, I'm sure you're aware that
the current version will delete cached resources for *all* versions of a given
process, wheras the original patch was a little more fine-grained <g>, but the
important thing for me is, with the above changes I no-longer leak memory on
deply-undeploy cycles, and I use less on a deploy (freeing up references allows
the GC to collect if it needs to mid deploy, otherwise you can twice as much in
memory as you need to )
> 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-2.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.
