Dear Ryan, > This is what I originally tried to do, but to no avail. > At first, I looked to java.sun.com and saw similar issues with related > solutions; aside from increasing the stack, a solution was to rewrite > readObject/writeObject as the Java string serializer has a poor > performance due to recursion (which brings the stack to max).
I don't understand what you mean here but I suppose it is not important? > When serializing a DOM tree, I'm assuming that the > serialization algorithm > is using a recursive approach. Is this correct? Yes, in serializeNode of BaseMarkupSerializer serializeNode is called recursively for the children of an element. In our product (not Xerces) we see people with very large documents, but never with a depth of 10.000, are you sure this is the most logical way to store the data (so is subelement A really 'a part' of parent B in all those 10.000 cases?). I ask because I think you are going to run into many more problems with other tools when processing such a document, as it is very enticing for programmers to use recursion in processing an XML tree. > Oh, one other interesting thing I noticed...I stopped getting > the overflow > when I switched one of my upper classes to a thread instead > of a regular > object. Does Java have different parameters for stack sizes? > (As I write > this, I'm looking into it...but if somebody already knows, > that would be > greatly appreciated.) Not sure, but I think the -Xss parameter applies to each thread in Java. In other words every time you create a Thread a stack with the -Xss size is allocated for it. So if it works better if you have just started a new Thread, I would think that the stack of the original thread was just too small to perform the action (a part of the thread-stack being in use by the program initialization). Kind regards, --Sander. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
