You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Karthick Sankarachary (JIRA)" <ji...@apache.org> on 2009/04/07 23:14:12 UTC
[jira] Commented: (ODE-574) Memory leak when Un-deploying processes
that contain XSL stylesheets
[ 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.