[ http://issues.apache.org/jira/browse/XALANJ-1980?page=comments#action_54682 ] Joe Kesselman commented on XALANJ-1980: ---------------------------------------
BTW, performance and memory use from a text stream (URI or file) will be better if you use StreamSource rather than a DOMSource. That lets us create a native DTM, rather than creating a DOM and then wrapping a DTM adapter around it. I hate to ask the stupid question, but just to get it out of the way: Are you sure you're running against a current version of Xalan rather than the one that shipped with the JDK? I've seen too many people get confused by the 1.3/1.4 library-class-path feature and wind up running the version of Xalan which shipped with the JDK... which is, of course, downlevel from the current version. I seem to remember that the version of Xalan 2 which shipped with 1.3 *did* have some memory leak problems; I know it had other issues. (It's possible something odd happened in recent code, so I'm not 100% sure your report is wrong... I'd just find it very surprising.) > 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.6, 2.5 > 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]
