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