You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by xa...@xml.apache.org on 2004/10/24 09:09:26 UTC
[jira] Created: (XALANJ-1980) memory leak with certain xalan objects
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/XALANJ-1980
Here is an overview of the issue:
---------------------------------------------------------------------
Key: XALANJ-1980
Summary: memory leak with certain xalan objects
Type: Bug
Status: Unassigned
Priority: Major
Project: XalanJ2
Components:
Xalan
Versions:
2.5
2.6
Assignee:
Reporter: Archna Monga
Created: Sun, 24 Oct 2004 12:08 AM
Updated: Sun, 24 Oct 2004 12:08 AM
Environment: Solaris, Sparc.
Description:
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.
---------------------------------------------------------------------
JIRA INFORMATION:
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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Commented: (XALANJ-1980) memory leak with certain xalan objects
Posted by "Joe Kesselman (JIRA)" <xa...@xml.apache.org>.
[ 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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Commented: (XALANJ-1980) memory leak with certain xalan objects
Posted by "John Gentilin (JIRA)" <xa...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XALANJ-1980?page=comments#action_54685 ]
John Gentilin commented on XALANJ-1980:
---------------------------------------
I don't know if this is related but extensions that produce a DTM object, that are assigned to variables, are having a similar problem. This is on my do to list for the SQL extensions, where users that execute several queries per stylesheet are running out of memory.
IMHO, if a variable goes out of scope and it contains a DTM, the DTM should be released from the DTMManager / XPath enviorment.
I think the hook to manage this is when the VariableStack code rolls back the stack. Instead of just releasing the stack entries, iterate through them and call destroy().
-John G
> 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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Commented: (XALANJ-1980) memory leak with certain xalan objects
Posted by "Reza (JIRA)" <xa...@xml.apache.org>.
[ http://nagoya.apache.org/jira/browse/XALANJ-1980?page=comments#action_55641 ]
Reza commented on XALANJ-1980:
------------------------------
I had a similar problem and after upgrading to version 2.6 the memory leak is gone.
> memory leak with certain xalan objects
> --------------------------------------
>
> Key: XALANJ-1980
> URL: http://nagoya.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://nagoya.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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Commented: (XALANJ-1980) memory leak with certain xalan objects
Posted by "Archna Monga (JIRA)" <xa...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XALANJ-1980?page=comments#action_54645 ]
Archna Monga commented on XALANJ-1980:
--------------------------------------
Haven't seen any action on this bug. Please look into it as we are facing a major customer escalation due to this. Your prompt action will be much appreciated.
> 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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Commented: (XALANJ-1980) memory leak with certain xalan objects
Posted by "Henry Zongaro (JIRA)" <xa...@xml.apache.org>.
[ http://nagoya.apache.org/jira/browse/XALANJ-1980?page=comments#action_55632 ]
Henry Zongaro commented on XALANJ-1980:
---------------------------------------
Any further updates?
> memory leak with certain xalan objects
> --------------------------------------
>
> Key: XALANJ-1980
> URL: http://nagoya.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://nagoya.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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Resolved: (XALANJ-1980) memory leak with certain xalan objects
Posted by "Henry Zongaro (JIRA)" <xa...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XALANJ-1980?page=history ]
Henry Zongaro resolved XALANJ-1980:
-----------------------------------
Resolution: Cannot Reproduce
Without a test case, it's difficult to provide you with any assistance. I am closing this bug report. If you or your customer can still reproduce this problem, and you can provide further information, please reopen the bug report.
> 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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Commented: (XALANJ-1980) memory leak with certain xalan objects
Posted by "Archna Monga (JIRA)" <xa...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XALANJ-1980?page=comments#action_54670 ]
Archna Monga commented on XALANJ-1980:
--------------------------------------
Thanks Joe for responding. Apparently all the following objects are not created by our code:
AttrImpl/ElementImpl etc.
org.apache.xml.dtm.ref.dom2dt.DOM2DTM -> Vector -> Object[] ->
org.apache.xpath.axes.AxesWalker ->
org.apache.xml.dtm.ref.DTMDefaultBaseTraversers$RootTraverser ->
But they show up in the reference list. As far as I see we aren't using any of the extensions. It appears they are internally used by XALAN (not sure). Can you please provide more pointers based on the code provided in the bug where we might be doing something wrong if we are. If you require ful code, I can include that as the attachment.
> 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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Updated: (XALANJ-1980) memory leak with certain xalan objects
Posted by "Brian Minchau (JIRA)" <xa...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XALANJ-1980?page=all ]
Brian Minchau updated XALANJ-1980:
----------------------------------
Fix Version: 2.7
> 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
> Fix For: 2.7
>
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Commented: (XALANJ-1980) memory leak with certain xalan objects
Posted by "Archna Monga (JIRA)" <xa...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XALANJ-1980?page=comments#action_54825 ]
Archna Monga commented on XALANJ-1980:
--------------------------------------
Per your suggestion we are trying to use StreamSource instead of DOMSource. Also the version of the Xalan used is 2.3.1_01.
Will be updating my findings after applying the suggestion.
> 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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Commented: (XALANJ-1980) memory leak with certain xalan objects
Posted by "Joe Kesselman (JIRA)" <xa...@xml.apache.org>.
[ 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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Commented: (XALANJ-1980) memory leak with certain xalan objects
Posted by "Joe Kesselman (JIRA)" <xa...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XALANJ-1980?page=comments#action_54671 ]
Joe Kesselman commented on XALANJ-1980:
---------------------------------------
The *Impl objects *are* created by your code; that's the DOM you passed in by specifying a DOMSource.
The rest are internal Xalan objects, which should be created, but which should also Go Away after the Transformer has been discarded. Are you sure you're giving the GC time to clean things up before analysing your remaining heap?
> 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: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org