Re: EOFException in AjpNioProcessor
On Dec 23, 2013, at 12:50 PM, Konstantin Preißer kpreis...@apache.org wrote:
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
Thanks Konstantin - it doesn't sound like this is a problem that I can do
anything about, other than to catch the exception and ignore it.
--Jesse Barnum, President, 360Works
http://www.360works.com
Product updates and news on http://facebook.com/360Works
(770) 234-9293
== Don't lose your data! http://360works.com/safetynet/ for FileMaker Server ==
Re: EOFException in AjpNioProcessor
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:358) 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. --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293
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:358) 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: EOFException in AjpNioProcessor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jessie, On 12/23/13, 11:45 AM, 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:358) 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. What version of Tomcat are you running? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSuHAkAAoJEBzwKT+lPKRYWcYQAKJHqK08p7BPk4qNOGPfgbMK VA+DArjK+NnO1tNJxVWjVxDmEsU6SYaVbSveLL8zrXrRMnlRHsjNVF+Vu24clG3c 5FuyYvyNLu970j8AIPgQaKCCwmdd6o7rLoN3UgeUbGrZ5aNu9ov5VnohD4b9/Ftg 13CinwekjbdVoqhbm7BSoIZwXnI2ZgG6we2Lpi5+4DlnLOcAk94CV8sl/WlBIjaN QKxexjEV6sXK76re4ymAWhGk+FqMBH3dyFnFIengyvYlmh1uttVSMvDotvF4qOTm rM4YLSrcGKDYI+52LrRM/+dfFCN2kNAzTIGoNQoLdkr7Gs2FNweozakuKpvsWYhE EQviKWjAJI4dfPYjWeKwpjDOW4pc5hhMRNK1XOxeok4OCIJMRei7b61L67KCyEfq eJsCXFkitXJFlRvxSrK8oWdC915KwpY2x/a8l/6QwYvXBVANawWBNc7uVqcvwfre xayQ+nu1yavrCE5W/oqHdcbdWEMK6ghRQwiMuCmx/HEswY5gWyJ6Vzjcxe00eIbR pjsiXroZE6+HPdVxNyUgRwgIiXi6FRaZbT1lToKt4p/82srhcnO+EkWJazMklEdE V9FvJ45cy+144j7XWksHqIYBiK5E6h9UarBzdf7IEmo+/RXVn3GVIkrLF58HS3UH w0aPhRRCOhadHldbpHPY =Nfr/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: EOFException in AjpNioProcessor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 12/23/13, 12:09 PM, André Warnier wrote:
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:358)
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.
EOFException is likely being thrown directly from AjpNioProcessor.
This is lines 375-377 of current 7.0.x/trunk:
} else if (nRead == -1) {
//return false;
throw new EOFException(sm.getString(iib.eof.error));
So perhaps Tomcat is using that exception in a way that is unexpected.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSuHOMAAoJEBzwKT+lPKRYu18P/2fadeTxmZpuDTjoUD5U8mG+
ep7ViMTQigSGHo+y45UbwCGrfYtUtpRslqNziLwyrHnwvV6jPGvjsgabUEMWwVK4
OTKFPQVDIJ8TzZMWQSovZDAQCrnbYTirwj1ktVMBIPdtrAAETkaljotPZl5lIbhH
MG2NOp2APkPGofSGGkT0Ke8QuwVOcDaZEtsvE92X3KZDjo3hgenFMZ7nbBaYi1aG
7B7KFPsBzVqTngWVRiv+1kqGtr6lQYYyNVQx+l5Za3IWVeX56TvDMf3nsDQ2eEnB
jiWiIBPxnT9ykptemiQBYv2lw/JYs9MARp7dLj0hMYQUKPpgdVywag0nRH9M9/Y1
x153jT6fy7EZoEu0bQslrSQMS8H2yU8jBqb+EHAih5UVtNLKn2e77/8rUeMI1eI8
KindHFkyIgD4ejpu6HQoKwGYjnsQA6M0UBv8t2TWRSq1ey++bR5Xx6HTUuh/+0SL
xZ1uDARUgEuI9Ai+r+1+M058nbEXBinMjKmBF722WcaIi/SHLBZkJHH25UgJNvjX
EIcY7MozfA/RZ0X6hd8E+TsDI3DC68sbpHS25zDv7XkLzjaijfFnDkdybXIHCh5K
zhJyfqsn6n4R18I5VKKHHqDGRlsgtw2m8gBK3OGkjss9jXJ52sUvj7eYKbW8Z48q
M6BXCMR8U2ukdeGXVvGV
=FZYW
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: EOFException in AjpNioProcessor
Hi Jesse, -Original Message- From: Jesse Barnum [mailto:jsb_tom...@360works.com] Sent: Monday, December 23, 2013 5:46 PM To: Tomcat Users List Subject: Re: EOFException in AjpNioProcessor 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. An AbortException or SocketException would mean that there was a problem with the socket so that the connection closed abnormally (which could also happen if there are still bytes to send when the connection is closed by the client, and the linger timeout occurs). However, in the case of the EOFException, the problem is not the socket itself, but that the AJP client which is connected to the socket (HTTPD with mod_jk, IIS with ISAPI Redirector etc.) has unexpectedly closed the connection. This could be thought as of a protocol error. I have not much knowledge about how mod_jk, ISAPI redirectors or other AJP clients work, but if they intentionally close the connection, then I think this is because the AJP protocol does not have a message indicating that the HTTP connection to the client has failed, so it has to close the AJP connection to let Tomcat know there was an error on the HTTP connection side (I also could be wrong here, I'm just guessing). I agree that an EOFException can be a bit misleading in this case, but since it is a subclass of IOException, you should be fine if you already catch IOExceptions. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: EOFException in AjpNioProcessor
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
Re: EOFException in AjpNioProcessor
Jesse Barnum wrote: On Dec 18, 2013, at 1:40 PM, André Warnier a...@ice-sa.com wrote: Jesse Barnum wrote: On Dec 18, 2013, at 12:27 PM, Jesse Barnum jsb_tom...@360works.com wrote: I'm seeing this error a lot in my log files. It happens when I am trying to read from the request InputStream. Should I be concerned about this, or is it just the equivalent of the user clicking 'stop' in their browser? SEVERE: An error occurred while handling request /WSMRegister/LicenseCheck/handshake java.io.EOFException Forgot to mention, I'm running version 7.0.35 on Ubuntu Linux on Amazon EC2. Well, it seems that you have the explanation right there. If com.prosc.licensecheck.LicenseCheck.doPost is your code, then that's where the problem is : you are trying to read from the request input stream, when there is no more data to read and you have already seen it's EOF. Why there is no more data to read is another question, and it could be that the client did something wrong. But the code in those classes who do the read, obviously is not coping well with that case. Yes, com.prosc.licensecheck.ListCheck.doPost is my code. It would not be hard to catch the exception there and ignore it. I guess another way to phrase the question is, what would cause a java.io.EOFException to get thrown? I don't want to ignore it if it's trying to tell me something important. I am used to seeing ClientAbortException: java.net.SocketException: Broken pipe. Is the EOFException basically the same thing? My concern is that there might be some misconfiguration between the Apache front end and the Tomcat NIO connector that might be causing it. First I will state that I am not a Java specialist, so take the following with a grain of caution. This being said, I believe that these two exceptions mean two different things. A broken pipe exception occurs when your program can legitimately expect more data to be present on the stream being read, tries to read it, and gets back an error because the stream, unexpectedly, does not exist anymore (typically, because the other party supposed to write to that stream has gone away without warning). An EOF exception is different : you are reading from a stream. At some point, the read() returns an EOF condition, indicating that no more data is present. That's not an exception yet, it is a normal condition for which you should be testing, and when it occurs you should stop reading. (I do not remember precisely how your code should test for this in Java. It may be that an EOF is indicated by the fact that the read() returns 0 bytes. Or maybe you should test explicitly by means of something like if (stream.eof) then ..) after each read(). But you do NOT stop reading, and you do one more read() nevertheless. /Then/ you get this exception, because now, you are trying to read /past/ the end of the file/stream (EOF). (It's like : you are approaching train-track crossing; you see the red light, and you should stop; but you don't, and you proceed nevertheless. The EOF exception is the train that happens to be passing just then). Note that it may not be directly your code per se which already reads the request input-stream and already reaches the EOF. An earlier call to HttpServletRequest.getParameters() for example, would trigger the reading of the whole body of a POST request, to parse the POST parameters, and would already leave the request input-stream at EOF, before you even try your first explicit read(). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: EOFException in AjpNioProcessor
André Warnier wrote: Jesse Barnum wrote: On Dec 18, 2013, at 1:40 PM, André Warnier a...@ice-sa.com wrote: Jesse Barnum wrote: On Dec 18, 2013, at 12:27 PM, Jesse Barnum jsb_tom...@360works.com wrote: I'm seeing this error a lot in my log files. It happens when I am trying to read from the request InputStream. Should I be concerned about this, or is it just the equivalent of the user clicking 'stop' in their browser? SEVERE: An error occurred while handling request /WSMRegister/LicenseCheck/handshake java.io.EOFException Forgot to mention, I'm running version 7.0.35 on Ubuntu Linux on Amazon EC2. Well, it seems that you have the explanation right there. If com.prosc.licensecheck.LicenseCheck.doPost is your code, then that's where the problem is : you are trying to read from the request input stream, when there is no more data to read and you have already seen it's EOF. Why there is no more data to read is another question, and it could be that the client did something wrong. But the code in those classes who do the read, obviously is not coping well with that case. Yes, com.prosc.licensecheck.ListCheck.doPost is my code. It would not be hard to catch the exception there and ignore it. I guess another way to phrase the question is, what would cause a java.io.EOFException to get thrown? I don't want to ignore it if it's trying to tell me something important. I am used to seeing ClientAbortException: java.net.SocketException: Broken pipe. Is the EOFException basically the same thing? My concern is that there might be some misconfiguration between the Apache front end and the Tomcat NIO connector that might be causing it. First I will state that I am not a Java specialist, so take the following with a grain of caution. This being said, I believe that these two exceptions mean two different things. A broken pipe exception occurs when your program can legitimately expect more data to be present on the stream being read, tries to read it, and gets back an error because the stream, unexpectedly, does not exist anymore (typically, because the other party supposed to write to that stream has gone away without warning). An EOF exception is different : you are reading from a stream. At some point, the read() returns an EOF condition, indicating that no more data is present. That's not an exception yet, it is a normal condition for which you should be testing, and when it occurs you should stop reading. (I do not remember precisely how your code should test for this in Java. It may be that an EOF is indicated by the fact that the read() returns 0 bytes. Or maybe you should test explicitly by means of something like if (stream.eof) then ..) after each read(). But you do NOT stop reading, and you do one more read() nevertheless. /Then/ you get this exception, because now, you are trying to read /past/ the end of the file/stream (EOF). (It's like : you are approaching train-track crossing; you see the red light, and you should stop; but you don't, and you proceed nevertheless. The EOF exception is the train that happens to be passing just then). Note that it may not be directly your code per se which already reads the request input-stream and already reaches the EOF. An earlier call to HttpServletRequest.getParameters() for example, would trigger the reading of the whole body of a POST request, to parse the POST parameters, and would already leave the request input-stream at EOF, before you even try your first explicit read(). Just adding something, to make the distinction clearer still: These 2 exceptions are really different, in the sense that - for the broken pipe exception, there is essentially nothing that your code can do about it, other than catching the exception and trying to recover cleanly from it. That the client writing to the socket that you are reading, would suddenly abort and go away, is not something that you can control. - for the EOFexception however, it indicates that you do something wrong in your logic. You should not be trying to read from that stream anymore, because - either you already got a warning that it was at EOF, and you just ignored it - or else you are not properly testing for EOF while reading In this case, just catching the exception and ignoring it is not really the right thing to do. You should fix the logic that causes it to happen. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: EOFException in AjpNioProcessor
HI André,
-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Sunday, December 22, 2013 12:25 PM
To: Tomcat Users List
Subject: Re: EOFException in AjpNioProcessor
I guess another way to phrase the question is, what would cause a
java.io.EOFException to get thrown? I don't want to ignore it if it's trying
to
tell me something important.
I am used to seeing ClientAbortException: java.net.SocketException:
Broken pipe. Is the EOFException basically the same thing? My concern is
that there might be some misconfiguration between the Apache front end
and the Tomcat NIO connector that might be causing it.
First I will state that I am not a Java specialist, so take the following
with a
grain of
caution.
This being said, I believe that these two exceptions mean two different
things.
A broken pipe exception occurs when your program can legitimately
expect more data to be
present on the stream being read, tries to read it, and gets back an error
because the
stream, unexpectedly, does not exist anymore (typically, because the other
party supposed
to write to that stream has gone away without warning).
An EOF exception is different : you are reading from a stream. At some point,
the read()
returns an EOF condition, indicating that no more data is present. That's not
an
exception yet, it is a normal condition for which you should be testing, and
when it
occurs you should stop reading.
(I do not remember precisely how your code should test for this in Java. It
may be that
an EOF is indicated by the fact that the read() returns 0 bytes. Or maybe you
should test
explicitly by means of something like if (stream.eof) then ..) after each
read().
But you do NOT stop reading, and you do one more read() nevertheless.
/Then/ you get this
exception, because now, you are trying to read /past/ the end of the
file/stream (EOF).
(It's like : you are approaching train-track crossing; you see the red light,
and
you
should stop; but you don't, and you proceed nevertheless. The EOF
exception is the train
that happens to be passing just then).
Note that the reason for a EOFException is slightly different than just reading
from a stream when there is no more data present.
In Java (and .Net), when you read from a Stream which is finished (there is no
more data present), read() returns -1. Even when you repeatedly call read(),
you will still get -1, but no exception.
Normally you do just
while ((read = input.read(buffer)) 0) { ...}
to test for the end of stream/data.
An EOFException however indicates that a higher logic was processing data but
unexpectedly received the end of stream. In this case, it is the
AjpNioProcessor which reads from the AJP connection and expects further AJP
packets from the client, but the client unexpectedly closes the exception
instead of sending the required packets. This is why the EOFException is thrown.
This can indicate either a problem with the connection between Tomcat and the
AJP client (e.g. mod_jk, ISAPI redirector etc.), but 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.
So, the EOFException here is not caused by an error in the code, but it should
probably be catched (like an IOException) to properly handle it.
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: EOFException in AjpNioProcessor
On Dec 18, 2013, at 1:40 PM, André Warnier a...@ice-sa.com wrote: Jesse Barnum wrote: On Dec 18, 2013, at 12:27 PM, Jesse Barnum jsb_tom...@360works.com wrote: I'm seeing this error a lot in my log files. It happens when I am trying to read from the request InputStream. Should I be concerned about this, or is it just the equivalent of the user clicking 'stop' in their browser? SEVERE: An error occurred while handling request /WSMRegister/LicenseCheck/handshake java.io.EOFException Forgot to mention, I'm running version 7.0.35 on Ubuntu Linux on Amazon EC2. Well, it seems that you have the explanation right there. If com.prosc.licensecheck.LicenseCheck.doPost is your code, then that's where the problem is : you are trying to read from the request input stream, when there is no more data to read and you have already seen it's EOF. Why there is no more data to read is another question, and it could be that the client did something wrong. But the code in those classes who do the read, obviously is not coping well with that case. Yes, com.prosc.licensecheck.ListCheck.doPost is my code. It would not be hard to catch the exception there and ignore it. I guess another way to phrase the question is, what would cause a java.io.EOFException to get thrown? I don't want to ignore it if it's trying to tell me something important. I am used to seeing ClientAbortException: java.net.SocketException: Broken pipe. Is the EOFException basically the same thing? My concern is that there might be some misconfiguration between the Apache front end and the Tomcat NIO connector that might be causing it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: EOFException in AjpNioProcessor
Subject: Re: EOFException in AjpNioProcessor From: jsb_tom...@360works.com Date: Sat, 21 Dec 2013 16:58:07 -0500 To: users@tomcat.apache.org On Dec 18, 2013, at 1:40 PM, André Warnier a...@ice-sa.com wrote: Jesse Barnum wrote: On Dec 18, 2013, at 12:27 PM, Jesse Barnum jsb_tom...@360works.com wrote: I'm seeing this error a lot in my log files. It happens when I am trying to read from the request InputStream. Should I be concerned about this, or is it just the equivalent of the user clicking 'stop' in their browser? SEVERE: An error occurred while handling request /WSMRegister/LicenseCheck/handshake java.io.EOFException Forgot to mention, I'm running version 7.0.35 on Ubuntu Linux on Amazon EC2. Well, it seems that you have the explanation right there. If com.prosc.licensecheck.LicenseCheck.doPost is your code, then that's where the problem is : you are trying to read from the request input stream, when there is no more data to read and you have already seen it's EOF. Why there is no more data to read is another question, and it could be that the client did something wrong. But the code in those classes who do the read, obviously is not coping well with that case. Yes, com.prosc.licensecheck.ListCheck.doPost is my code. It would not be hard to catch the exception there and ignore it. I guess another way to phrase the question is, what would cause a java.io.EOFException to get thrown? I don't want to ignore it if it's trying to tell me something important. I am used to seeing ClientAbortException: java.net.SocketException: Broken pipe. MGError in Transport..your apache or tomcat servers(or one of intervening routers) is unable to complete the transmission Is the EOFException basically the same thing? MGAs andre said There is no more data from Request My concern is that there might be some misconfiguration between the Apache front end and the Tomcat NIO connector that might be causing it. MG..possibly...lets take a look.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: EOFException in AjpNioProcessor
On Dec 18, 2013, at 12:27 PM, Jesse Barnum jsb_tom...@360works.com wrote: I'm seeing this error a lot in my log files. It happens when I am trying to read from the request InputStream. Should I be concerned about this, or is it just the equivalent of the user clicking 'stop' in their browser? SEVERE: An error occurred while handling request /WSMRegister/LicenseCheck/handshake java.io.EOFException Forgot to mention, I'm running version 7.0.35 on Ubuntu Linux on Amazon EC2. --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293 == Don't lose your data! http://360works.com/safetynet/ for FileMaker Server ==
RE: EOFException in AjpNioProcessor
Hi Jesse, -Original Message- From: Jesse Barnum [mailto:jsb_tom...@360works.com] Sent: Wednesday, December 18, 2013 6:58 PM To: Tomcat Users List Subject: Re: EOFException in AjpNioProcessor On Dec 18, 2013, at 12:27 PM, Jesse Barnum jsb_tom...@360works.com wrote: I'm seeing this error a lot in my log files. It happens when I am trying to read from the request InputStream. Should I be concerned about this, or is it just the equivalent of the user clicking 'stop' in their browser? SEVERE: An error occurred while handling request /WSMRegister/LicenseCheck/handshake java.io.EOFException Forgot to mention, I'm running version 7.0.35 on Ubuntu Linux on Amazon EC2. I think this is the exception that occurs when the client (browser) closes the TCP connection (normal shutdown) without finishing to write the request body. This could happen if the user clicks the cancel button in their browser, so I don't think you need to be concerned about this exception itself, but you should catch it (or IOException) in your code so that Tomcat doesn't have to log this exception. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: EOFException in AjpNioProcessor
Jesse Barnum wrote: On Dec 18, 2013, at 12:27 PM, Jesse Barnum jsb_tom...@360works.com wrote: I'm seeing this error a lot in my log files. It happens when I am trying to read from the request InputStream. Should I be concerned about this, or is it just the equivalent of the user clicking 'stop' in their browser? SEVERE: An error occurred while handling request /WSMRegister/LicenseCheck/handshake java.io.EOFException Forgot to mention, I'm running version 7.0.35 on Ubuntu Linux on Amazon EC2. Well, it seems that you have the explanation right there. If com.prosc.licensecheck.LicenseCheck.doPost is your code, then that's where the problem is : you are trying to read from the request input stream, when there is no more data to read and you have already seen it's EOF. Why there is no more data to read is another question, and it could be that the client did something wrong. But the code in those classes who do the read, obviously is not coping well with that case. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
