On 23 May 2013 18:38, Rémy Maucherat <rmaucher_at_redhat.com> wrote:
> Once a write is in progress, it cannot change retroactively between
> blocking and async (and this is the issue with websockets which allows
> blocking the container thread after making an async write). I don't see the
> issue since I mentioned this was like NIO2, so:
> - No concurrent writes (it a write is pending, there is an exception).
>
agreed.
> - A write can be async or blocking and the choice is made when calling the
> write.
>
I don't see how this choice can be made for blocking? You signal an async
write by calling isReady() before calling write. So a blocking write is
chosen by not calling isReady, but then you can't know if the previous
write is complete and can't avoid the concurrent write. Fragile code will
result that will mostly work until confronted by a slow client.
> OTOH, since autoblocking (or my take on it) doesn't solve websockets,
> adding it is not required.
>
That may be the best way to avoid these issue.
regards
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.
Intalio, the modern way to build business applications.