You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/04/27 22:45:28 UTC
Why so many SocketExceptions thrown by Xalan?
People,
I'm currently writing a web application on top of Cocoon that requires
several callbacks to the server in order to complete the result.
A single page is composed of
1 HTML page (xslt-generated, 3 stages)
1 javascript file (xslt-generated, 1 stage)
5 javascript files (just read)
10 images (just read)
I restart the system. hit the page with my browser (IE6.0 on win2k) and
I get this on my error.log (turned debugging off)
[please see my comments intermixed, don't get scared by the stacktrace!
and remember that all this was generated out of a single page load]
[NOTE: running Cocoon 2.1-dev out of CVS HEAD of last week, which
includes Xalan 2.3.1]
HttpProcessor[8080][4]/TraxErrorHandler: Error in TraxTransformer:
javax.xml.transform.TransformerException: java.net.SocketException:
Connection aborted by peer: socket write error
javax.xml.transform.TransformerException: java.net.SocketException:
Connection aborted by peer: socket write error
at
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:725)
at
org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:422)
at
org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:226)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2243)
at
org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2069)
at
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1171)
at
org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3196)
at java.lang.Thread.run(Thread.java:484)
Now, the interesting thing is that it seems that Xalan is running it's
own thread. I don't recall seeing thread-forking code for Xalan spin-off
in Cocoon, so I wonder: is this a Xalan thing?
---------
java.net.SocketException: Connection aborted by peer: socket write error
at
org.apache.xalan.serialize.SerializerToXML.outputLineSep(SerializerToXML.java:199)
at
org.apache.xalan.serialize.SerializerToXML.indent(SerializerToXML.java:2387)
at
org.apache.xalan.serialize.SerializerToHTML.endElement(SerializerToHTML.java:731)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1047)
at
org.apache.cocoon.xml.AbstractXMLPipe.endElement(AbstractXMLPipe.java:147)
at
org.apache.cocoon.serialization.AbstractTextSerializer$NamespaceAsAttributes.endElement(AbstractTextSerializer.java:488)
at
org.apache.cocoon.xml.AbstractXMLPipe.endElement(AbstractXMLPipe.java:147)
at
org.apache.xalan.transformer.ResultTreeHandler.endElement(ResultTreeHandler.java:307)
at
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:716)
at
org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:422)
at
org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:226)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2243)
at
org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2069)
at
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1171)
at
org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3196)
at java.lang.Thread.run(Thread.java:484)
Again, another spinned-off xalan thread (calling a cocoon contenthandler
at some point)
---------
java.net.SocketException: Connection aborted by peer: socket write error
at java.net.SocketOutputStream.socketWrite(Native Method)
at java.net.SocketOutputStream.write(SocketOutputStream.java:96)
at
org.apache.catalina.connector.ResponseBase.flushBuffer(ResponseBase.java:679)
at
org.apache.catalina.connector.HttpResponseBase.flushBuffer(HttpResponseBase.java:741)
at
org.apache.catalina.connector.ResponseBase.write(ResponseBase.java:652)
at
org.apache.catalina.connector.ResponseStream.write(ResponseStream.java:312)
at
org.apache.catalina.connector.http.HttpResponseStream.write(HttpResponseStream.java:168)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:72)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:85)
at org.apache.xalan.serialize.WriterToUTF8.write(WriterToUTF8.java:138)
at
org.apache.xalan.serialize.SerializerToXML.outputLineSep(SerializerToXML.java:195)
at
org.apache.xalan.serialize.SerializerToXML.indent(SerializerToXML.java:2387)
at
org.apache.xalan.serialize.SerializerToHTML.endElement(SerializerToHTML.java:731)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1047)
at
org.apache.cocoon.xml.AbstractXMLPipe.endElement(AbstractXMLPipe.java:147)
at
org.apache.cocoon.serialization.AbstractTextSerializer$NamespaceAsAttributes.endElement(AbstractTextSerializer.java:488)
at
org.apache.cocoon.xml.AbstractXMLPipe.endElement(AbstractXMLPipe.java:147)
at
org.apache.xalan.transformer.ResultTreeHandler.endElement(ResultTreeHandler.java:307)
at
org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:716)
at
org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:422)
at
org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:226)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2243)
at
org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2069)
at
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1171)
at
org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3196)
at java.lang.Thread.run(Thread.java:484)
I can't tell if these exceptions come all from the same thread or are
some sort of browser-triggered concurrent exceptions.
But the *really* weird thing is that I also get this:
java.lang.RuntimeException: java.net.SocketException: Connection aborted
by peer: socket write error
at
org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3231)
at java.lang.Thread.run(Thread.java:484)
on STDERR!
I suspect this is a Xalan bug, but I'm not really that sure so I post it
on bost lists.
Functionally, everything is all right (even if, I suspect that some
files are sometimes reloaded from the browser cache!), but these
stacktraces really fill up the log files quickly and this is very
annoying.
Also, no library that is used on server side should write to STDERR:
it's not polite and many times these logs are just going straight to
/dev/null.
Thanks
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: Why so many SocketExceptions thrown by Xalan?
Posted by Peter Royal <pr...@apache.org>.
On Saturday 27 April 2002 04:45 pm, Stefano Mazzocchi wrote:
> Now, the interesting thing is that it seems that Xalan is running it's
> own thread. I don't recall seeing thread-forking code for Xalan spin-off
> in Cocoon, so I wonder: is this a Xalan thing?
yes.
> But the *really* weird thing is that I also get this:
>
> java.lang.RuntimeException: java.net.SocketException: Connection aborted
> by peer: socket write error
> at
> org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3231)
> at java.lang.Thread.run(Thread.java:484)
>
> on STDERR!
Try turning on "incremetal processing", you'll get those wrapped in
RuntimeException's instead :)
> I suspect this is a Xalan bug, but I'm not really that sure so I post it
> on bost lists.
I entered a bug for some of this, it appears that it is a somewhat-known
problem due to the comments in the xalan source.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8033
> Functionally, everything is all right (even if, I suspect that some
> files are sometimes reloaded from the browser cache!), but these
> stacktraces really fill up the log files quickly and this is very
> annoying.
I agree, it is very annoying to have such stacktraces fill the logs. This is
a behavior that started somewhere in the 2.2 series for Xalan. IIRC, 2.0
didn't have the same behavior
I'd like to know what the expected behavior from Xalan is so Cocoon can be
modified to expect it accordingly.
-pete
--
peter royal -> proyal@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org