Actually none, no XML was involved and no XML related jars in any classpath. I believe the problem has been reduced significantly due to some configuration changes on the server invloving the min and maxHeapSize values in jvm12.conf.
BEFORE
#jvm.minHeapSize=1048576
#jvm.maxHeapSize=16777216
On our system these were initially commented out, so I do not know what the default guess is going to be.
AFTER
jvm.minHeapSize=33554432
jvm.maxHeapSize=134217728
iPlanet makes no effort to give us any idea of appropriate values for this. Nor do they explain what the server does in the case that no values are specified (or when commented out which for some reason ours were).
After racking our brains over outOfMemoryError s and searching our servlets for \"leaks\" we determined that the
default behavior of memory allocation seemed to be sufficient for testing one or two servlets in a dev environment. Way too low for heavy production. Just raising the max did not solve very much either. The servlets would still periodicaly crash with ome s. Finally we raised the min as well and no more out of memory errors. The rate at wich we got jvm Aborts dropped significantly as well. However they still happen here and there.
We will be switching all remaining servers to Apache / tomcat so we have not taken the time to dig for the offending methods.