You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "Nicolas Bonmariage (JIRA)" <xa...@xml.apache.org> on 2005/07/13 18:28:15 UTC

[jira] Created: (XALANJ-2171) Memory leak in case of concurrent access to Templates object

Memory leak in case of concurrent access to Templates object
------------------------------------------------------------

         Key: XALANJ-2171
         URL: http://issues.apache.org/jira/browse/XALANJ-2171
     Project: XalanJ2
        Type: Bug
  Components: transformation  
    Versions: 2.6, 2.4    
 Environment: JBoss 3.2.6 AS, JDK 1.4.2, Windows 2000
    Reporter: Nicolas Bonmariage
    Priority: Critical


I use Xalan/Xerces to perform FOP processing inside a J2EE application.
I recently introduced the use of Templates object as a performance optimization.
As the spec says Templates objects have to thread safe, I used it as static field from which I creates Transformer objects.
Note that each thread receives its own Transformer object, so the use seems correct regarding threading issues.
However I noticed thereafter a memory leak inside the AS in case of important load.
Using a profiling tool, I saw TransformerImpl objects (and the associated object graph) filling up the memory.
The root to the GC showed references from the static Templates field.

I observed this phenomenon wih Xalan 2.4.1 but upgrading to version 2.6 did not help.

The reference graph shows something like :
StylesheetRoot (static) -> Vector[ElemTemplate] -> ... -> SAX2DTM -> TransformerImpl

I can attach the full graph if needed.

I saw related issues talking about Iterator objects keeping references and there are indeed Iterator objects involved in the reference graph.
But in my case this shows up only in the case of an heavily threaded environment. 

Anyway, the result is an application server whose memory is filled up and unusable.


-- 
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-2171) Memory leak in case of concurrent access to Templates object

Posted by "Nicolas Bonmariage (JIRA)" <xa...@xml.apache.org>.
    [ http://issues.apache.org/jira/browse/XALANJ-2171?page=comments#action_12315770 ] 

Nicolas Bonmariage commented on XALANJ-2171:
--------------------------------------------

Concerning the object graph, the root is shown in red. It comes from version 2.4.1. The graph for version 2.6 is really huge, but the references are globally the same.

> Memory leak in case of concurrent access to Templates object
> ------------------------------------------------------------
>
>          Key: XALANJ-2171
>          URL: http://issues.apache.org/jira/browse/XALANJ-2171
>      Project: XalanJ2
>         Type: Bug
>   Components: transformation
>     Versions: 2.6, 2.4
>  Environment: JBoss 3.2.6 AS, JDK 1.4.2, Windows 2000
>     Reporter: Nicolas Bonmariage
>     Priority: Critical
>  Attachments: graph_3.png, historicOperationsNotConsolidated.xsl, report.xml, report.xsl
>
> I use Xalan/Xerces to perform FOP processing inside a J2EE application.
> I recently introduced the use of Templates object as a performance optimization.
> As the spec says Templates objects have to thread safe, I used it as static field from which I creates Transformer objects.
> Note that each thread receives its own Transformer object, so the use seems correct regarding threading issues.
> However I noticed thereafter a memory leak inside the AS in case of important load.
> Using a profiling tool, I saw TransformerImpl objects (and the associated object graph) filling up the memory.
> The root to the GC showed references from the static Templates field.
> I observed this phenomenon wih Xalan 2.4.1 but upgrading to version 2.6 did not help.
> The reference graph shows something like :
> StylesheetRoot (static) -> Vector[ElemTemplate] -> ... -> SAX2DTM -> TransformerImpl
> I can attach the full graph if needed.
> I saw related issues talking about Iterator objects keeping references and there are indeed Iterator objects involved in the reference graph.
> But in my case this shows up only in the case of an heavily threaded environment. 
> Anyway, the result is an application server whose memory is filled up and unusable.

-- 
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-2171) Memory leak in case of concurrent access to Templates object

Posted by "Henry Zongaro (JIRA)" <xa...@xml.apache.org>.
    [ http://issues.apache.org/jira/browse/XALANJ-2171?page=comments#action_12315763 ] 

Henry Zongaro commented on XALANJ-2171:
---------------------------------------

I think a sample stylesheet and input document along with the complete object graph would help us to determine the cause of the problem (and whether it's already been fixed).

> Memory leak in case of concurrent access to Templates object
> ------------------------------------------------------------
>
>          Key: XALANJ-2171
>          URL: http://issues.apache.org/jira/browse/XALANJ-2171
>      Project: XalanJ2
>         Type: Bug
>   Components: transformation
>     Versions: 2.6, 2.4
>  Environment: JBoss 3.2.6 AS, JDK 1.4.2, Windows 2000
>     Reporter: Nicolas Bonmariage
>     Priority: Critical

>
> I use Xalan/Xerces to perform FOP processing inside a J2EE application.
> I recently introduced the use of Templates object as a performance optimization.
> As the spec says Templates objects have to thread safe, I used it as static field from which I creates Transformer objects.
> Note that each thread receives its own Transformer object, so the use seems correct regarding threading issues.
> However I noticed thereafter a memory leak inside the AS in case of important load.
> Using a profiling tool, I saw TransformerImpl objects (and the associated object graph) filling up the memory.
> The root to the GC showed references from the static Templates field.
> I observed this phenomenon wih Xalan 2.4.1 but upgrading to version 2.6 did not help.
> The reference graph shows something like :
> StylesheetRoot (static) -> Vector[ElemTemplate] -> ... -> SAX2DTM -> TransformerImpl
> I can attach the full graph if needed.
> I saw related issues talking about Iterator objects keeping references and there are indeed Iterator objects involved in the reference graph.
> But in my case this shows up only in the case of an heavily threaded environment. 
> Anyway, the result is an application server whose memory is filled up and unusable.

-- 
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] Updated: (XALANJ-2171) Memory leak in case of concurrent access to Templates object

Posted by "Nicolas Bonmariage (JIRA)" <xa...@xml.apache.org>.
     [ http://issues.apache.org/jira/browse/XALANJ-2171?page=all ]

Nicolas Bonmariage updated XALANJ-2171:
---------------------------------------

    Attachment: report.xml

> Memory leak in case of concurrent access to Templates object
> ------------------------------------------------------------
>
>          Key: XALANJ-2171
>          URL: http://issues.apache.org/jira/browse/XALANJ-2171
>      Project: XalanJ2
>         Type: Bug
>   Components: transformation
>     Versions: 2.6, 2.4
>  Environment: JBoss 3.2.6 AS, JDK 1.4.2, Windows 2000
>     Reporter: Nicolas Bonmariage
>     Priority: Critical
>  Attachments: historicOperationsNotConsolidated.xsl, report.xml, report.xsl
>
> I use Xalan/Xerces to perform FOP processing inside a J2EE application.
> I recently introduced the use of Templates object as a performance optimization.
> As the spec says Templates objects have to thread safe, I used it as static field from which I creates Transformer objects.
> Note that each thread receives its own Transformer object, so the use seems correct regarding threading issues.
> However I noticed thereafter a memory leak inside the AS in case of important load.
> Using a profiling tool, I saw TransformerImpl objects (and the associated object graph) filling up the memory.
> The root to the GC showed references from the static Templates field.
> I observed this phenomenon wih Xalan 2.4.1 but upgrading to version 2.6 did not help.
> The reference graph shows something like :
> StylesheetRoot (static) -> Vector[ElemTemplate] -> ... -> SAX2DTM -> TransformerImpl
> I can attach the full graph if needed.
> I saw related issues talking about Iterator objects keeping references and there are indeed Iterator objects involved in the reference graph.
> But in my case this shows up only in the case of an heavily threaded environment. 
> Anyway, the result is an application server whose memory is filled up and unusable.

-- 
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] Updated: (XALANJ-2171) Memory leak in case of concurrent access to Templates object

Posted by "Nicolas Bonmariage (JIRA)" <xa...@xml.apache.org>.
     [ http://issues.apache.org/jira/browse/XALANJ-2171?page=all ]

Nicolas Bonmariage updated XALANJ-2171:
---------------------------------------

    Attachment: historicOperationsNotConsolidated.xsl

> Memory leak in case of concurrent access to Templates object
> ------------------------------------------------------------
>
>          Key: XALANJ-2171
>          URL: http://issues.apache.org/jira/browse/XALANJ-2171
>      Project: XalanJ2
>         Type: Bug
>   Components: transformation
>     Versions: 2.6, 2.4
>  Environment: JBoss 3.2.6 AS, JDK 1.4.2, Windows 2000
>     Reporter: Nicolas Bonmariage
>     Priority: Critical
>  Attachments: graph_3.png, historicOperationsNotConsolidated.xsl, report.xml, report.xsl
>
> I use Xalan/Xerces to perform FOP processing inside a J2EE application.
> I recently introduced the use of Templates object as a performance optimization.
> As the spec says Templates objects have to thread safe, I used it as static field from which I creates Transformer objects.
> Note that each thread receives its own Transformer object, so the use seems correct regarding threading issues.
> However I noticed thereafter a memory leak inside the AS in case of important load.
> Using a profiling tool, I saw TransformerImpl objects (and the associated object graph) filling up the memory.
> The root to the GC showed references from the static Templates field.
> I observed this phenomenon wih Xalan 2.4.1 but upgrading to version 2.6 did not help.
> The reference graph shows something like :
> StylesheetRoot (static) -> Vector[ElemTemplate] -> ... -> SAX2DTM -> TransformerImpl
> I can attach the full graph if needed.
> I saw related issues talking about Iterator objects keeping references and there are indeed Iterator objects involved in the reference graph.
> But in my case this shows up only in the case of an heavily threaded environment. 
> Anyway, the result is an application server whose memory is filled up and unusable.

-- 
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-2171) Memory leak in case of concurrent access to Templates object

Posted by "Nicolas Bonmariage (JIRA)" <xa...@xml.apache.org>.
    [ http://issues.apache.org/jira/browse/XALANJ-2171?page=comments#action_12315766 ] 

Nicolas Bonmariage commented on XALANJ-2171:
--------------------------------------------

I attached the object graph as a PNG image.

I also attached the source XML and the associated XSLs.

The Java code executed in each thread is standard:

Source src = new StreamSource(...);
Result res = new SAXResult(...);
Transformer transformer = templates.newTransformer();
transformer.transform(src, res);

where templates is static field of type Templates

> Memory leak in case of concurrent access to Templates object
> ------------------------------------------------------------
>
>          Key: XALANJ-2171
>          URL: http://issues.apache.org/jira/browse/XALANJ-2171
>      Project: XalanJ2
>         Type: Bug
>   Components: transformation
>     Versions: 2.6, 2.4
>  Environment: JBoss 3.2.6 AS, JDK 1.4.2, Windows 2000
>     Reporter: Nicolas Bonmariage
>     Priority: Critical
>  Attachments: graph_3.png, historicOperationsNotConsolidated.xsl, report.xml, report.xsl
>
> I use Xalan/Xerces to perform FOP processing inside a J2EE application.
> I recently introduced the use of Templates object as a performance optimization.
> As the spec says Templates objects have to thread safe, I used it as static field from which I creates Transformer objects.
> Note that each thread receives its own Transformer object, so the use seems correct regarding threading issues.
> However I noticed thereafter a memory leak inside the AS in case of important load.
> Using a profiling tool, I saw TransformerImpl objects (and the associated object graph) filling up the memory.
> The root to the GC showed references from the static Templates field.
> I observed this phenomenon wih Xalan 2.4.1 but upgrading to version 2.6 did not help.
> The reference graph shows something like :
> StylesheetRoot (static) -> Vector[ElemTemplate] -> ... -> SAX2DTM -> TransformerImpl
> I can attach the full graph if needed.
> I saw related issues talking about Iterator objects keeping references and there are indeed Iterator objects involved in the reference graph.
> But in my case this shows up only in the case of an heavily threaded environment. 
> Anyway, the result is an application server whose memory is filled up and unusable.

-- 
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] Updated: (XALANJ-2171) Memory leak in case of concurrent access to Templates object

Posted by "Nicolas Bonmariage (JIRA)" <xa...@xml.apache.org>.
     [ http://issues.apache.org/jira/browse/XALANJ-2171?page=all ]

Nicolas Bonmariage updated XALANJ-2171:
---------------------------------------

    Attachment: report.xsl

> Memory leak in case of concurrent access to Templates object
> ------------------------------------------------------------
>
>          Key: XALANJ-2171
>          URL: http://issues.apache.org/jira/browse/XALANJ-2171
>      Project: XalanJ2
>         Type: Bug
>   Components: transformation
>     Versions: 2.6, 2.4
>  Environment: JBoss 3.2.6 AS, JDK 1.4.2, Windows 2000
>     Reporter: Nicolas Bonmariage
>     Priority: Critical
>  Attachments: historicOperationsNotConsolidated.xsl, report.xml, report.xsl
>
> I use Xalan/Xerces to perform FOP processing inside a J2EE application.
> I recently introduced the use of Templates object as a performance optimization.
> As the spec says Templates objects have to thread safe, I used it as static field from which I creates Transformer objects.
> Note that each thread receives its own Transformer object, so the use seems correct regarding threading issues.
> However I noticed thereafter a memory leak inside the AS in case of important load.
> Using a profiling tool, I saw TransformerImpl objects (and the associated object graph) filling up the memory.
> The root to the GC showed references from the static Templates field.
> I observed this phenomenon wih Xalan 2.4.1 but upgrading to version 2.6 did not help.
> The reference graph shows something like :
> StylesheetRoot (static) -> Vector[ElemTemplate] -> ... -> SAX2DTM -> TransformerImpl
> I can attach the full graph if needed.
> I saw related issues talking about Iterator objects keeping references and there are indeed Iterator objects involved in the reference graph.
> But in my case this shows up only in the case of an heavily threaded environment. 
> Anyway, the result is an application server whose memory is filled up and unusable.

-- 
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] Updated: (XALANJ-2171) Memory leak in case of concurrent access to Templates object

Posted by "Nicolas Bonmariage (JIRA)" <xa...@xml.apache.org>.
     [ http://issues.apache.org/jira/browse/XALANJ-2171?page=all ]

Nicolas Bonmariage updated XALANJ-2171:
---------------------------------------

    Attachment: graph_3.png

> Memory leak in case of concurrent access to Templates object
> ------------------------------------------------------------
>
>          Key: XALANJ-2171
>          URL: http://issues.apache.org/jira/browse/XALANJ-2171
>      Project: XalanJ2
>         Type: Bug
>   Components: transformation
>     Versions: 2.6, 2.4
>  Environment: JBoss 3.2.6 AS, JDK 1.4.2, Windows 2000
>     Reporter: Nicolas Bonmariage
>     Priority: Critical
>  Attachments: graph_3.png, historicOperationsNotConsolidated.xsl, report.xml, report.xsl
>
> I use Xalan/Xerces to perform FOP processing inside a J2EE application.
> I recently introduced the use of Templates object as a performance optimization.
> As the spec says Templates objects have to thread safe, I used it as static field from which I creates Transformer objects.
> Note that each thread receives its own Transformer object, so the use seems correct regarding threading issues.
> However I noticed thereafter a memory leak inside the AS in case of important load.
> Using a profiling tool, I saw TransformerImpl objects (and the associated object graph) filling up the memory.
> The root to the GC showed references from the static Templates field.
> I observed this phenomenon wih Xalan 2.4.1 but upgrading to version 2.6 did not help.
> The reference graph shows something like :
> StylesheetRoot (static) -> Vector[ElemTemplate] -> ... -> SAX2DTM -> TransformerImpl
> I can attach the full graph if needed.
> I saw related issues talking about Iterator objects keeping references and there are indeed Iterator objects involved in the reference graph.
> But in my case this shows up only in the case of an heavily threaded environment. 
> Anyway, the result is an application server whose memory is filled up and unusable.

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