tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rémy Maucherat <r...@apache.org>
Subject Re: Read events suspend/resume logic in websocket impl to achieve backpressure
Date Wed, 08 Feb 2017 08:54:02 GMT
2017-02-08 0:51 GMT+01:00 Mark Thomas <markt@apache.org>:

> On 06/02/17 19:55, Violeta Georgieva wrote:
>
>> Hi,
>>
>> Currently JSR356 provides possibility to add message handlers in order to
>> receive web socket
>> messages but there is no way to instruct the web socket implementation to
>> suspend for a while
>> the incoming messages (backpressure) so that the application is able to
>> process the already delivered messages.
>> The other web containers (Jetty, Undertow) supports such functionality so
>> I
>> would like to introduce it in Tomcat.
>> Here [1] I prepared one possible implementation.
>>
>> What do you think about this feature and the proposed implementation?
>>
>
> I suggest you go ahead and commit (and back-port) the formatting updates.
> They all look good and getting those out of the way will make the diff
> easier to read.
>
> I'm currently undecided on this.
>
> I understand the requirement but rather than have proprietary methods
> added to various WebSocket implementations, I would have preferred to see a
> reactive wrapper provided for Java WebSocket that would have used
> Server->Client WebSocket messages to communicate back pressure to the
> client.
>
> However, that doesn't work if the aim is to feed 'uncontrolled' WebSocket
> clients into a reactive server side framework. Blocking is going to be only
> option to apply back-pressure and better to do that just on the client
> rather than on the client and the server - which means this feature is
> required in some form.
>
> I guess that makes me reluctantly in favour of it in principle but I'd
> very much prefer to review a patch proposal minus the reformatting.
>
> This new solution says that it should be the network that takes care of
the congestion. Personally, I prefer thinking the application should
decouple its IO from the actual processing and take care of the backlog
itself. One example: with some APIs, we've noticed that when a server
disconnects or become unresponsive, they become notified with an error like
... Never. Or, even better, as you say, the server should send something to
the client to actually give it information, but it's all proprietary then
(client + server).

Overall, I don't really see the point of retrofitting this new stuff into
already old things like websockets, while HTTP/2 should have this server ->
client "control" capability (minus an actual API to use it from Servlets, I
guess).

If this is still included, I suppose you will make sure the performance
doesn't go down BTW.

Rémy

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message