Hi André,
> -----Original Message-----
> From: André Warnier [mailto:a...@ice-sa.com]
> Sent: Monday, December 23, 2013 6:09 PM
> To: Tomcat Users List
> Subject: Re: EOFException in AjpNioProcessor
>
> Jesse Barnum wrote:
> > On Dec 22, 2013, at 8:54 AM, Konstantin Preißer <kpreis...@apache.org>
> wrote:
> >
> >> I suspect the AJP client intentionally closes the connection if e.g. the
> >> HTTP
> client which connected to the outer Webserver (HTTPD, IIS) aborted the
> HTTP connection (or there was some other error) so this error is reflected at
> Tomcat (which can therefore throw this exception). Otherwise Tomcat or the
> Webappp would not know that there was an error and if it e.g. was sending a
> 10 GB file, it would continue to send it.
> >
> > If this is the case, then shouldn't the AJP client include the
> > AbortException
> as the 'causedBy' property for the EOFException? The last line in the stack
> trace is:
> >
> >> at
> org.apache.coyote.ajp.AjpNioProcessor.readSocket(AjpNioProcessor.java:35
> 8)
> >
> > So something went wrong when it tried to read the socket, but I would
> think there would be some java.net.* or java.io.* exception (ie.
> AbortException, SocketException) corresponding to that problem. Throwing
> the EOFException without an associated cause sounds like there is something
> wrong with the state of the data being received, not with the underlying
> network socket itself.
> >
> >
> Take this with a grain of salt again, but from the reading I've done, I
> believe
> that the
> EOFexception comes from the class which you use for read()-ing the input
> stream.
> It is that class which "translates" the underlying exception to EOFexception.
In that case, the stacktrace would show that the Exception is thrown in the
webapp's code (and if the Exception is created using a cause, it would show a
"Caused by: ..." stacktrace showing the original source).
However, the stacktrace from Jesse shows that the EOFException is thrown by
Tomcat's AjpNioProcessor class:
> java.io.EOFException
> at
> org.apache.coyote.ajp.AjpNioProcessor.readSocket(AjpNioProcessor.java:358)
> at
> org.apache.coyote.ajp.AjpNioProcessor.read(AjpNioProcessor.java:314)
> at
> org.apache.coyote.ajp.AjpNioProcessor.readMessage(AjpNioProcessor.java:406)
> at
> org.apache.coyote.ajp.AjpNioProcessor.receive(AjpNioProcessor.java:375)
> at
> org.apache.coyote.ajp.AbstractAjpProcessor$SocketInputBuffer.doRead(AbstractAjpProcessor.java:1066)
> at org.apache.coyote.Request.doRead(Request.java:422)
> at
> org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:290)
> at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:431)
> at
> org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:315)
> at
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:167)
> at com.prosc.io.IOUtils.writeInputToOutput(IOUtils.java:49)
> at com.prosc.io.IOUtils.inputStreamAsBytes(IOUtils.java:116)
> at com.prosc.io.IOUtils.inputStreamAsString(IOUtils.java:136)
> at com.prosc.io.IOUtils.inputStreamAsString(IOUtils.java:127)
> at com.prosc.licensecheck.LicenseCheck.doPost(LicenseCheck.java:164)
> [...]
Lines 351-361 of Tomcat 7.0.35's AjpNioProcessor#readSocket() are as follows:
351 if (nRead > 0) {
352 socket.getBufHandler().getReadBuffer().flip();
353 socket.getBufHandler().getReadBuffer().limit(nRead);
354 socket.getBufHandler().getReadBuffer().get(buf, pos, nRead);
355 return nRead;
356 } else if (nRead == -1) {
357 //return false;
358 throw new EOFException(sm.getString("iib.eof.error"));
359 } else {
360 return 0;
361 }
Line 358 throws the EOFException because there was no more data to read on the
AJP connection although (I think) the AJP connector expected the client to send
further data (the request body).
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
