DO NOT REPLY [Bug 4735] - Infinite loop processing large file

[bu...@apache.org]

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=4735>.
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=4735

Infinite loop processing large file

keshlam@us.ibm.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|xalan-dev@xml.apache.org    |keshlam@us.ibm.com



------- Additional Comments From keshlam@us.ibm.com  2001-11-08 08:27 -------
One can quibble about whether this is a bug per se or simply a design limitation 
of this implementation... but I'll accept it as a bug since we're looking for 
ways to improve it.

Xalan-J does currently have a maxiumum size limit on input documents; we can run 
out of slots in the DTM table, and I believe the failure mechanism could indeed 
be seen as a wrap back to the root of the document. We should be able to make 
that failure more diagnostically recognizable; I'll investigate that.

The best workaround I can offer for now is to subdivide the problem -- generate 
a number  of smaller documents rather than one huge one, and use document() to 
access them. That will reduce the load on each DTM model. However, the same 
issue means  we can run out of available DTMs... so if you've got a particularly 
large  dataset, it may indeed be impossible to get it all into a single Xalan 
execution and you may need to style separate chunks, then merge them via another 
tool.

We do have some ideas which might address this, either by changing the DTM 
handle representation (EXTREMELY painful, and we hope to avoid it) or by 
introducing some source-tree pruning (which would be a good thing from many 
points of view, but wouldn't cover all possible stylesheets.) A pruning 
prototype is in progress but is not yet ready to be checked in, and at this time 
our best guess is that it won't be included in reference releases of Xalan 
before version 2.4.