You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Ciaran Jessup (JIRA)" <ji...@apache.org> on 2009/04/07 22:49:13 UTC
[jira] Created: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
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
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.
[jira] Updated: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ciaran Jessup updated ODE-574:
------------------------------
Comment: was deleted
(was: Your proposal makes sense, the only reason I didn't want to do something like that was the scale of the change, I *thought*/hoped? that the 1.3.1 release was nearing completion so wanted to put in a minimal change. This change is v. important to me as I can't currently/am barely able to deploy my processes on a 32 bit machine, I *Definately* can't deploy/un-deploy more than once due to this leak and need something quick and safe in place. I can make your proposed change if you really want me to, but it seems a little riskier, for no real benefit at this point ? (other than tidy-ness/sanity))
> 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, StopListenersHangingAbout.patch, StyleSheetCache.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.
[jira] Updated: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ciaran Jessup updated ODE-574:
------------------------------
Attachment: (was: StopListenersHangingAbout.patch)
> 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.
[jira] Commented: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696764#action_12696764 ]
Karthick Sankarachary commented on ODE-574:
-------------------------------------------
I took a quick look at your patch, and I have to say that it seems overly complicated, just because of the way the cache is structured.
I'd rather play it safe, and tweak the multi-key a little bit so that it becomes easier to purge process-specific data. To that end, I suggest replacing the baseUri component of the multi-key with the processQName, so that it becomes the tuple <processQName, uri> as opposed to <baseUri, uri>. The processQName can be obtained through CompilerContext.getOProcess().getQName().
WDYT?
> 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: StyleSheetCache.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.
[jira] Updated: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ciaran Jessup updated ODE-574:
------------------------------
Attachment: (was: StyleSheetCache.patch)
> 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.
[jira] Commented: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696772#action_12696772 ]
Ciaran Jessup commented on ODE-574:
-----------------------------------
Your proposal makes sense, the only reason I didn't want to do something like that was the scale of the change, I *thought*/hoped? that the 1.3.1 release was nearing completion so wanted to put in a minimal change. This change is v. important to me as I can't currently/am barely able to deploy my processes on a 32 bit machine, I *Definately* can't deploy/un-deploy more than once due to this leak and need something quick and safe in place. I can make your proposed change if you really want me to, but it seems a little riskier, for no real benefit at this point ? (other than tidy-ness/sanity)
> 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, StopListenersHangingAbout.patch, StyleSheetCache.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.
[jira] Resolved: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary resolved ODE-574.
---------------------------------------
Resolution: Fixed
The patch from 2009-04-08 04:07 AM has been applied at revision 765005.
> 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.
[jira] Commented: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-574:
--------------------------------------
Attachment: cleanup-xsl-cache.patch
Ciaran,
Please take a look at cleanup-xsl-cache.patch, and let me know what you think. It simplifies the way the cache is created which in turn makes it a breeze to clean it up.
Regards,
Karthick
> 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, StopListenersHangingAbout.patch, StyleSheetCache.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.
[jira] Commented: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696760#action_12696760 ]
Karthick Sankarachary commented on ODE-574:
-------------------------------------------
This is a known issue and we were planning on cleaning up the cache at the time of process undeployment. If its any consolation, if you bounce the server after deleting a process, then its stylesheets will never ever get loaded in the cache.
If you're looking into a possible solution, I would suggest taking advantage of the fact that the stylesheets are cached against a multikey that comprises the process' base URI. When a process is undeployed, you could try and clear all entries in the cache corresponding to that process' base URI.
> 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: StyleSheetCache.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.
[jira] Updated: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ciaran Jessup updated ODE-574:
------------------------------
Attachment: StyleSheetCache.patch
This patch should now allow any OProcess instances that happen to be left in memory due to 'belonging' to a cached Stylesheet to be garbage collected when the process that contained the stylesheet is un-deployed. The patch definately needs reviewing as the with/without slash code I put in seems un-neccessary but I couldn't understand why the multi-key had a terminating slash when the path-to-package wasn't constructed with one wherever I looked ;)
> 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: StyleSheetCache.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.
[jira] Commented: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696944#action_12696944 ]
Ciaran Jessup commented on ODE-574:
-----------------------------------
I've reviewed the cleanup-xsl-cache.patch, unfortunately it won't work in its current form :(
It seems that the process name is not equivalent to the process id (the latter having a version identifier appended the proces name, also shouldn't we use removeAll rather than remove from the map [I'm not familiar with that particular collection MultiKeyMap] and the remove/all should probably be in a synchronised block.
The main issue is the mis-match of process name, which means the resources don't currently get released at the minute, eek!
> 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, StopListenersHangingAbout.patch, StyleSheetCache.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.
[jira] Commented: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696776#action_12696776 ]
Ciaran Jessup commented on ODE-574:
-----------------------------------
That patch certainly is a lot simpler from the stylesheet cache perspective, I'll need to re-test it in the morning (left a load-test running over night to test my patches.) Conceptually it seems right, I'll comment in the morning. (I was loathe to make a change that big myself as I don't have your knowledge of the system, but if you're happy with those changes then I am <g> )
> 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, StopListenersHangingAbout.patch, StyleSheetCache.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.
[jira] Updated: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ciaran Jessup updated ODE-574:
------------------------------
Attachment: StopListenersHangingAbout.patch
The attached patch (I think, will confirm in the morning [GMT]) may no longer be neccessary given the other changes, but I"ve put it in just to be safe, this handles (I think) the case where the CompileListener ends up associated with items in the Stylesheet cache, as the compileListener contains a reference to the OProcess this keeps the reference in memory for-ever :( ... The other patch may make this patch redundant, will check shortly. However! The setErrorListener method seems particular thread-unsafe, I can't see what guards there are that the TransformerFactory underlying the cache won't be called from multiple places con-currently, and possibly mis-report errors ???
> 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: StopListenersHangingAbout.patch, StyleSheetCache.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.