I am running saxon-ee-220.127.116.11 using the command line interface to transform
directories of XML files.
This error is reported, often several times with different input files:
I/O error reported by XML parser processing
end of file from server
While processing 120025C.SVG: Run-time errors were reported
On a directory containing 1000 input files, I typically see 50 to 100 errors,
but the numbers are pretty erratic.
However, I can rerun the process on the same directory and have a different
set files give the above error.
I have tested in Solaris and Ubuntu environments with both local and networked
disk and the errors occur in all environments; they are repeatable but not
I can run the same set of files through the transformation process specifying
a single input file rather than a directory, (one input file and one JVM,) and
have processed about 30,000 files this way in the past day and an I/O error
was reported on only one.
Has anyone else experienced this?
Strange - haven't seen anything like this before. Do any of the files require
access to web resources, e.g. DTDs hosted on the W3C server?
My experience is that the processor is looking for a file.
When it does not find it, it sends back this type of error.
"Unexpected end of file from server"
I am using -dtd:off, however the files are svg and do reference
I had two cases (out of about 58k) where it reported
Server returned HTTP response code: 502 for URL: http://www.w3.org/TR/2001
which I attributed to a network glitch, and those occurred when I was
processing a single file at a time rather than the entire directory. It did
not report the unexpected end of file, which does occur frequently when giving
if a directory rather than a file.
The DTD reference explains the problem. W3C no longer guarantee to satisfy
requests for these common DTD URL's - they can't cope with the traffic.
-dtd:off suppresses DTD validation, but the DTD is still fetched for other
purposes (such as entity expansion). The answer is to use catalogs to redirect
the reference to a local copy. The next Saxon release will have improved
support for this (though logically, this is a function that really belongs
with the XML parser...)
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.