2017-02-08 0:51 GMT+01:00 Mark Thomas <ma...@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
