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 11:43 ------- About the System.gc() call: In our architecture we use a SoftReference which has a finalizer which clears a cache with hard references, based on some criteria (we're well aware of the limitation of GC and Java). The SoftReference() is just used as some memory-pressure notifier and care is taken to free lots of memory in the SoftReference finalizer. This works well in all current VMs (even under stress), just as long as no one is calling System.gc() at will. I misread your comment thinking that I should call System.gc() before invoking Xalan to make sure that enough RTFs were freed. Invoking it when you run out of DTM Id's would lower the number of calls to System.gc() but still sounds like a kludge (Note: i haven't looked at the Xalan code in detail to see what's going on, but relying on finalizers for this doesn't seem the way to do it, IMHO). A better way, perhaps, would be to clean up after each transformation explicitly, this would still put a cap on the maximal document length (which would be unexpected, but with a big fat warning acceptable), without relying on the garbage collector. Note, the document that poses a problem is not nearly as long as the one from the first bugreport, but it's the 4th document that is processed that throws up, each document being around 30Kb in length (XML-source, around 2000 nodes each). It works in 64M of memory when asked to (it's just slow as no caching will occur then). So I doubt that I'm hitting the 2**16 limit just with my source documents. Unless this limits is a total for both the source _and_ XSL stylesheets, in which case, this problem will come up more and more I think when XSL stylesheets are extended and re-used.
