This conversation was left hanging last year. So I'd just like to
confirm if we all agree on the interpretation summarized in the last post.
Specifically I'd like to confirm the interpretation of what should happen
when an EOF arrives while a thread is already dispatched within
onDataAvailable reading previous data.
The code will be written in the pattern:
while(in.isReady())
{
int b = in.read();
if (b<0)
break;
// handle b;
}
Eventually when the EOF arrives, the isReady() call will still return true
(can't return false as that implies that onDataAvailable will be called
again and we are already here). The read() will then return -1 and the
loop will exit and the method will return. Once the method has returned
the onAllDataRead() method will be called.
The alternate interpretation (that some users are asking for) is that the
code is written in the form:
while(in.isReady())
{
int b = in.read();
// handle b;
}
Eventually when the EOF arrives, the isReady() call will return false (we
probably need to update javadoc to indicate that onDataAvailable not be
called after this false ). The loop will exit and the method will return.
Once the method has returned the onAllDataRead() method will be called.
In this interpretation -1 is never read.
Jetty currently is implementing the former interpretation.
On 6 February 2015 at 09:26, Greg Wilkins <gregw_at_intalio.com> wrote:
>
>
> On 5 February 2015 at 19:50, Mark Thomas <markt_at_apache.org> wrote:
>
>> On 05/02/2015 01:41, Greg Wilkins wrote:
>> >
>> > On 5 February 2015 at 09:35, Greg Wilkins <gregw_at_intalio.com
>> > <mailto:gregw_at_intalio.com>> wrote:
>> >
>> > isFinished() will return false until such time as EOF has been
>> > communicated to the application ether by reading -1 or by calling
>> > onDataAvailable()
>>
>> You mean onAllDataRead here don't you?
>>
>
> Doh! yes! So much for clarity!
>
> So again, here is the list of behaviours that I would like to javadoc if
> there are no objections:
>
> - onAllDataRead will always be called once and only once when EOF
> stream is reached in the input stream (with the exception for completion -
> see below).
> - The call to onAllDataRead will NOT be concurrent with any other
> callbacks associated with the stream (onDataAvailable, onWritePossible,
> service etc.). onAllDataRead will only be called once the prior callback
> returns.
> - It is possible for -1 to be read from a stream during such a
> callback to onDataAvailable.
> - It is possible for onAllDataRead to be called directly without -1
> being read during a call to onDataAvailable.
> - If isReady() returns false, then a callback to onDataAvailable()
> will be scheduled for when a read can proceed.
> - If the stream is at EOF, then isReady() will return true as -1 can
> be read.
> - isFinished() will return false until such time as EOF has been
> communicated to the application ether by reading -1 or by calling
> onAllDataRead()
> - If the AsyncContext.complete() method is called, or a
> Servlet.service ASYNC dispatch returns without another startAsync, then the
> request/response lifecycle is completed and no further callbacks
> (onDataAvailable, onAllDataRead, onWritePossible, service, filter) will be
> dispatched for that request/response.
>
>
> Currently our jetty-9.2 release does not act in this way, but our 9.3
> snapshot has been made to do so. The result is that it is a bit more
> forgiving of user code - ie I think it is harder to write fragile code with
> these assumptions. The reason being is that you can choose your EOF
> abstraction (onAddDataRead or read -1) you wish to act on and you are
> guaranteed of seeing that. Without these assumptions, it is possible for
> these EOF signals to be skipped in some circumstances.
>
> cheers
>
>
>
>
> --
> Greg Wilkins <gregw_at_intalio.com> @ Webtide - *an Intalio subsidiary*
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com advice and support for jetty and cometd.
>
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com