DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6768>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6768 High Xms heap settings in JVM produce org.apache.xml.dtm.DTMException: No more DTM IDs are available. ------- Additional Comments From [EMAIL PROTECTED] 2002-03-06 16:29 ------- There _shouldn't_ be transformation-to-transformation issues. Each transformation obtains an independent XPathContext, which has its own DTMManager and thus its own pool of DTMs... or at least that's the intent. So this overflow is occuring within a single transformation. The only thing multiple transforms should be doing to us is indirectly affecting when GC, and hence finalizers, will run. Note that DTMs are used for Result Tree Fragments as well as for input documents (which is why XRTreeFrag's finalizer is involved in managing them.) If you're using RTFs heavily -- especially if you've got deep recursion with variables in an attempt to force XSLT to behave like a procedural language -- you may in fact be churning through RTFs rapidly enough that the fact that you're preventing GC is causing us to run out. I agree that the explicit System.gc() when the DTMManager thinks it's out of space is a kluge. But it seems to be a low-risk patch which is likely to solve your immediate problem while we consider whether there's a better way to manage the scope of references to RTFs. There's something to be said for treating the symptoms. Assuming the treatment works, of course. We should try it and find out whether it helps you.
