On Tue, 2011-10-11 at 01:45 +1100, Greg Wilkins wrote:
> On 10 October 2011 23:52, Remy Maucherat <rmaucher_at_redhat.com> wrote:
> Ok, so this test is about the old comet model in your specific
> implementation, placed in an ideal usage scenario. Nice, but
> how is this
> relevant ?
>
> It is as relevant as any single data point can be. It shows that at
> least in some circumstances blocking is not a problem.
We should pretend we're doing something more ambitious, like a
multipoint web conference application :)
> The main problem is that without non blocking controls on
> output, your
> websocket server can be easily taken down by a handful of slow
> clients.
> Either because it uses a single thread to send data back (it
> would
> become unresponsive), or because the unwritten data will need
> to be
> fully buffered across all clients (it would OOM). This is
> actually a DoS
> class security issue for any application that needs to send
> back
> sizeable amounts of data.
>
> But we already have a blocking API for
>
> servletResponse.getWriter().write(somedata);
>
> Servlets can block and hold a container thread today. Having a
> blocking sendMessage is no different to what we already have for
> servlets. Yes there are DOS attacks that can be based on this blocking
> style, but you have to get the server to send you a large HTTP
> response or a large WS message or lots and lots of small WS messages.
> Async IO is better in this regard, but async can be a tough
> application API for application/framework developers.
Going back to Rajiv's proposal for HTTP Servlets 3.1, it adds flags to
indicate if something may block, so that the application can stop
writing data until it gets a callback from the container telling it this
particular client can again accept data without blocking. This allows
doing output for all clients with - potentially - one single thread
writing all the data. Surely this will scale far better, and use in
clouds where resources are limited will be possible.
Websockets seem to be more important for media rich apps rather than the
stock ticker (HTTP Servlets 3.1 should provide very good scalability for
that), so they'd need the same thing, which can be used either blocking
or non blocking depending on the application needs. So it covers all use
cases with the minimum amount of complexity for application developers
(especially if they are happy enough with blocking IO, in that case it
is simply the same as your current API), but it is certainly more
difficult to implement for container developers.
> BTW, I also continue to believe having control over frames is
> useful,
> but this is not the place to discuss this.
>
>
> In the context of a JSR specifically for WS, I agree that it should
> have full access to frames, opcodes, extensions and other stuff hidden
> from the javascript clients.
> It is only in the context of the servlet specification that I'm
> advocating a minimal application level only API.
Ah ok, I understand better then, sorry for the trouble. I would have
compromised on abstracting frames in the context of JSR 340.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc