[jsr356-experts] Re: Streaming API: was For Review: v002 API and example code
- From: Remy Maucherat <
- Subject: [jsr356-experts] Re: Streaming API: was For Review: v002 API and example code
- Date: Wed, 11 Jul 2012 17:01:31 +0200
- Organization: Red Hat Inc
On Wed, 2012-07-11 at 09:59 +0100, Mark Thomas wrote:
> That depends on how the client is (ab)using the protocol.
> If the client uses a very large frame size and sends data in drips and
> drabs then you have to read the frame using non-blocking if you want the
> server to be able to scale.
> One could argue that a client behaving in this manner is abusing the
> protocol and the client should be sending multiple smaller frames where
> the entire frame is sent. If we took that view, then non-blocking
> between frames and blocking within a frame is reasonable solution. This
> is still my favoured approach but I don't think it is a view that the
> rest of the EG supports. I be very happy if I was wrong on that though.
It's obvious people always abuse protocols and APIs. The source of the
design problem here is that websocket allows unlimited frames [while
everyone would have been very fine if frames were limited to only
16bit]. The argument is then that we should design the API for 16bit
frames, and sacrifice scalability for the rest.
Not convinced yet ... I am ok with fixing websockets though :)
> > It is important that the API can deliver partial frames to allow
> > implementations with a small fixed buffer.
> I agree there needs to be a way for large messages to be consumed
> without having to buffer the entire message. Given that there are a lot
> of APIs that expect streams and that it is much easier to implement
> chunking / partial frames (or whatever you want to call it) on top of a
> stream than it is to implement streams on top of chunking / partial
> frames then I think the underlying implementation should be streams with
> (optionally) the partial frames implemented on top.
But the Servlet API provides async IO underneath the websocket
implementation, so that makes async the default target for the JSR API.
Red Hat Inc