> > I know that can be difficult, but async is hard and it does us no good to
> > > pretend otherwise. Allowing blocking calls to be interspersed with async
> > > calls is fraught. We had that discussion back when we were considering
> > if
> > > we could revert to blocking IO - and that proved to be too difficult.
> >
> > I just think that there is a potential for problems if error handling code
> > attempts to end the request and it fails. A simple example is what happens
> > if a request times out while a write is in progress? According to the spec
> > the container needs to call complete(), however if we have made this
> > illegal what happens then?
> >
> > I just think that if a user has indicated that they want to complete the
> > request we need to make sure it completes, and does not just leave a
> > hanging connection.
> >
>
> Well it should never be left hanging, as it should eventually timeout.
>
> But I agree it would be nice to have a simple call that would bring the
> request cycle to an end no matter what. Perhaps we need to say that if
> complete is called with a pending write then that write is aborted -
> onError is called with a WriteInterruptedException and then the complete
> takes place (if the onError has not already called complete or dispatch).
>
> ie I think it would be safer for complete to really be complete. Queuing
> complete just leaves us open to more strangeness for events that happen
> while it is in the queue.
>
> So if you want your write to work, wait for isReady()==true before calling
> complete(). But if you call complete() before then, it will complete, but
> you may truncate the response.
+1
I think it makes sense to handle it this way. It will result in a broken connection in most cases but I think that is an acceptable tradeoff, as this is not something that should happen in normal usage.
I wonder if the same behavior should also apply to ServletOutputStream.close() if it is called when isReady()==false?
I think we also need to cover how flush() behaves when using non blocking IO. I think it should have the same semantics as write(), i.e.:
- You can only call it when isReady()==true
- After it has been called you need to check the ready state again
Stuart
>
>
> cheers
>
>
>
>
>
>
>
> --
> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
>