[ http://nagoya.apache.org/jira/browse/XALANJ-1973?page=history ]
Ken Weiner updated XALANJ-1973:
-------------------------------
Attachment: screenshot-1.jpg
I am seeing a memory leak too that may be related. Attached is a screen shot
of a memory snapshot using YourKit profiler.
The picture shows the references that lead from a StylesheetRoot down to a
ElemForEach and eventually to the ChannelManager object which is an object in
my application that should have been garbage collected, but hasn't been because
of the strong reference remaining from within ElemForEach.
I suspect that the problem is in org.apache.xpath.axes.IteratorPool which seems
to hang on to objects in its m_freeStack for too long. If anyone could
elaborate on the intended behavior for IteratorPool, that would help me
determine if this class is the problem.
> Memory Leak, Extension functions that return a DTM
> --------------------------------------------------
>
> Key: XALANJ-1973
> URL: http://nagoya.apache.org/jira/browse/XALANJ-1973
> Project: XalanJ2
> Type: Bug
> Components: transformation
> Versions: CurrentCVS
> Environment: Xalan, current CVS
> JDK 1.4.2_04 (SUN)
> Reporter: John Gentilin
> Attachments: FanTest.xsl, screenshot-1.jpg,
> xsl-apply-templates-backtrace.mht, xsl-apply-templates-heap.mht,
> xsl-for-each-backtrace.mht
>
> It appears that when an extension function returns a DTM, a reference to the
> DTM object is held within the transformation engine.
> This problem is apparent within the SQL Extension but I don't think the
> extension code is the source of the problem.
> I am including a Stylesheet that can demonstrate the problem along with 2
> different back trace files and a heap dump produced from OptimizeIt. The heap
> dump represents the state of the JVM, after the transformation was completed
> with a forced GC. The back traces show the allocations of the SQLDocument
> which extends DTM.
> The stylesheet example is complete and does not require an XML data file. It
> does require a connection to a JDBC compliant Database. The stylesheet will
> create the table, insert the test data and run several iterations.
> At first we were using the xsl:for-each element. Comments in this code lead
> me to believe that the ElemForEach#transformSelectedNodes may have been
> responsible. The XSL was then refactored to use xsl:apply-templates but the
> same memory leak appeared.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
