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?
> I just want to expand on this one - as I can see alternatives and it
> would be good to be really clear on to strive for a single behaviour.
>
> Consider the following code:
>
> @Override
> public void onDataAvailable() throws IOException
> {
> while(in.isReady() && !in.isFinished())
> {
> if(in.read()<0)
> asyncContext.complete();
> }
> }
>
> Image this has been called while the server is in possession of a
> chunked body with several chunks ending with the final 0 chunk. We
> could expect an implementation to iterate reading bytes until EOF is
> reached.
>
> But the behaviour of isFinished() will determine if this code completes
> correct or not.
>
> If when isReady() is called, the impl will need to check the buffer
> contents to see if it has more data available. At this point it will
> eventually see the 0 chunk and it will know that -1 can be read so it
> will return true. At this point it knows EOF is there, so it could
> also return true for isFinished(), but if it did then the loop would
> exit and complete would never be called. Thus what I'm proposing is
> that we say that isFinished() should not return true until either -1 has
> been read or onAllDataRead is called.
>
> By having this strict definition of when isFinished goes true, I believe
> we will avoid subtle bugs like the one above. Note that there are
> better ways of writing that loop (eg using onAllDataRead to call
> complete), but I have definitely seen users write code like that above.
+1. I am all for clear, strict definitions.
Mark