[ http://issues.apache.org/jira/browse/XALANJ-1980?page=comments#action_54667 ] Joe Kesselman commented on XALANJ-1980: ---------------------------------------
Hmmm. Are you AttrImpl/ElementImpl etc. -- That's the DOM you're passing in. org.apache.xml.dtm.ref.dom2dt.DOM2DTM -> Vector -> Object[] -> -- That's the DTM adapter layer. Since DTMs are cached by the DTMManager, which in turn is owned by the XPath Environment, which is owned by the Transformer, it should persist as long as the tranformer does and then go away. org.apache.xpath.axes.AxesWalker -> org.apache.xml.dtm.ref.DTMDefaultBaseTraversers$RootTraverser -> -- Transient objects created by the XPath engine's evaluation layer. These should persist only for the duration of the transformation. Unless you're doing something strange with extension functions setting up additional persistant storage, or are not discarding the transformers after you're done with them, we really shouldn't be leaking any of these. We shouldn't be _able_ to leak them; there isn't much persistant storage that lasts beyond the end of a transformation. > memory leak with certain xalan objects > -------------------------------------- > > Key: XALANJ-1980 > URL: http://issues.apache.org/jira/browse/XALANJ-1980 > Project: XalanJ2 > Type: Bug > Components: Xalan > Versions: 2.5, 2.6 > Environment: Solaris, Sparc. > Reporter: Archna Monga > > Hi, > I am from Sun Microsystems and we are using XALAN for XSL processing. Our > application is apparently observing good heap size increase. Using JProbe > analysis tool, I find couple of objects collecting in xsl processing after a request > is completed - > org.apache.xpath.axes.AxesWalker -> > org.apache.xml.dtm.ref.DTMDefaultBaseTraversers$RootTraverser -> > org.apache.xml.dtm.ref.dom2dt.DOM2DTM -> Vector -> Object[] -> > AttrImpl/ElementImpl etc. > JProbe shows them as loitering objects created after we include a checkpoint to > monitor objects created only in the request. The result of above extra objects is > that heap size seems to keep growing as the load increases and in a period of time > the process size reached the max. > Each request in testing tends to serve search.xml: > search.xml (contains couple of tags that are expanded to obtain data) > search.xsl (which is translated to output html) > I am not sure what part of our code would result in that. We are using following > code for XSL transformation - > Transformer transformer = null; > if (xmlDoc == null) { > throw new XSLProcessingException("XSLProcessor: xmlDoc null"); > } > if (outputStream == null) > throw new XSLProcessingException("XSLProcessor: outputStream null"); > try { > transformer = _templates.newTransformer(); > } catch (TransformerConfigurationException tce) { > throw new XSLProcessingException("XSLProcessor: transformer could not be > created : " > +tce.getMessage()); > } > if (transformer == null) { > throw new XSLProcessingException("XSLProcessor: _transformer null"); > } > try { > transformer.transform( new DOMSource(xmlDoc), > new StreamResult(outputStream)); > } catch (TransformerException te) { > throw new XSLProcessingException("XSLProcessor: transform failed (" > +te.getMessage() + ")"); > } > } > > Please let me know if more information is required. It's quite urgent for us as our > application is released and the problem is reported by a customer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
