+1 to the list of clarifications. ATM we also implement this the same
way as Jetty does.
Stuart
On Thu, Apr 7, 2016 at 8:48 AM, Greg Wilkins <gregw_at_webtide.com> wrote:
>
> 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