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-08 17:55 ------- What suggest we try, as a stopgap, is to modify the DTMManagerDefault.addDTM() process -- either by moving the DTM ID number assignment into this function or by moving the test up to the caller -- so that if (and only if) we are out of space in the table we call System.gc(), wait to try to be sure GC has had a reasonable opportunity to run, and call getFirstFreeDTMID() try getting another (hopefully smaller) DTM ID. If that succeeds we can proceed; if not, the exception really does have to be thrown Note that this would request a GC _only_ when we've run out of DTM slots, so it should be infrequent and is probably tolerable. A better solution would be to detect when the XRTreeFrag is about to be discarded and call its release operation rather than waiting for the finalizer. I haven't had time yet to investigate how much re-architecting that would require. Actually, if you're managing to run out of DTM IDs I'm somewhat terrified by how much time you're spending in the getFirstFreeDTMID() function... for your case I suspect that improving this to maintain a real free-list might more than compensate for the effects of the GC. Not hard to do, just requires time to focus on it.
