tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [OT] EOFException in AjpNioProcessor
Date Mon, 23 Dec 2013 13:37:58 GMT
Christopher Schultz wrote:
> Hash: SHA256
> Konstantin,
> On 12/22/13, 8:54 AM, Konstantin Preißer wrote:
>> 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 = > 0) {
>> ...} to test for the end of stream/data.
> It's important to note for beginners that you want the comparison
> operator to be ">=" and not just ">". If you use "0" than you run the
> risk of attempting to read from a stream that has stalled and getting
> zero bytes (and stopping) when there may future bytes on the stream.

So it seems that contrarily to what I was writing earlier, the EOFexception is thus not an

indication of something wrong in the logic.
After consulting the relevant Javadocs (which I should probably have done before writing 
nonsense, mea culpa), I am nevertheless under the impression that there are some 
inconsistencies in terms of what one could be expecting (in terms of exceptions) when 
reading the HttpRequest input stream.  The basic thing seems to be :
- if read() returns n > 0, then you have actually read something
- if read() returns n = 0, you have not read anything, but there was no error and there 
was no "end of file" condition.  (This should only happen when you are reading from 
something in non-blocking mode, though.)
- if read() returns n = -1, then you do not have an error, but you have reached the 
end-of-file; and if you read() again, you'll keep getting -1.
- if you get an exception, the basic thing seems to be an IOexception, but then it depends

of the actual sub-class which you are using for the stream, which can redefine this.

And considering how it happens, the EOFexception seems to be really misnamed, because it 
is /anything but/ an EOF condition.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message