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=11945>. 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=11945 Too much memory and time spent parsing large message ------- Additional Comments From [EMAIL PROTECTED] 2003-02-14 20:45 ------- I have a thought on why this might be happening. In Java 1.4, the implementation of java.lang.StringBuffer.setLength() was changed. It used to be possible to recycle StringBuffers by invoking setLength(0), which would, as a side effect, shrink the capacity of the buffer back to the default size of 16, allowing the larger char array to be GC'ed. As of Java 1.4, this is no longer true, and so recycled StringBuffers can leak memory. This is currently one of the top 25 bugs on Sun's BugParade, and it's had a big impact on the memory profile of existing code, such as JDOM, which use this technique. I see that Axis also has this problem: SimpleDeserializer's reset() method uses setLength(0) to recycle the "val" stringbuffer. Under Java 1.4, this may trigger the memory leak. Sun's position (see the bug parade for details) is that the new behavior is what was originally specified and so people should not cache StringBuffers in this way. Replacing the setLength(0) with a call to new StringBuffer() in SimpleDeserializer might help with the memory consumption problem reported here.
