Hi Chuck,

Presumably this API is similar in intention to the request method used in
reactive streams (aka java.util.concurrent.Flow), that is, request is the
means by which backpressure is propagated. One major problem with JDK8
WebSockets is there's no way to asynchronously propagate backpressure, you
have to accept every message that comes as it comes, you can't tell the
other end to back off, which means if it's producing messages faster than
you can consume them, your only two options are to fail fast, or risk
running out of memory.  Reactive Streams solves this by requiring consumers
to signal demand for data/messages before they receive any - an invocation
of the request method is just saying how many more elements the consumer is
currently ready to receive, and can be invoked many times, as the consumer
processes messages and is ready to receive more. Generally, for Reactive
Streams, application developers are not expected to implement or invoke
these APIs directly, instead, they are expected to use reactive streams
implementations like Akka Streams, rxJava or Reactor, which efficiently
manage buffering and keeping the buffer at an appropriate level for the
application developer, so the application developer can just focus on their
business concerns.

But that brings me to a problem that I'd like to give as feedback to the
implementers - this API is not Reactive Streams, and so therefore can't
take advantage of Reactive Streams implementations, and more problematic,
can't interop with other Reactive Streams sinks/sources. If I wanted to
stream a WebSocket into a message broker that supports Reactive Streams, I
can't. I would definitely hope that Reactive Streams support could be added
to this API, at a minimum as a wrapper, so that application developers can
easily focus on their business problems, plumbing and transforming messages
from one place to another, rather than having to deal with implementing
concurrent code to pass messages. It may well require wrapping messages in
a high level object - text, binary, ping, pong, etc, to differentiate
between the message types.

For a broader context of how this would fit into the broader Reactive
Streams ecosystem, I've published a blog post of what it would look like if
Java EE/EE4J were to adopt Reactive Streams everywhere, as it happens this
also includes proposals for using Reactive Streams in the JSR 356 WebSocket




On 9 February 2018 at 19:16, Chuck Davis <cjgun...@gmail.com> wrote:

> I've been using jdk8 websockets to develop my desktop java
> applications.  Now that jdk9 is on my machine I started looking at
> websockets and I'm not at all sure I like what I see.  Can someone
> familiar with this feature please explain the rationale for what is
> happening?
> I'm concerned, at this initial stage, primarily by
> WebSocket.request(long).  This "feature" seems to have at least two
> very negative impacts:
> 1)  It appears to destroy the asynchronous nature of websockets;
> 2)  It appears to place programmers in the impossible position of
> guessing how many messages the server side might send.
> 1)  If everything has to stop while the client asks for more messages
> asynchronous communication is nullified.  The jdk8 implementation is,
> therefore, much more functional.
> 2)  It would appear the only logical use of WebSocket.request() would
> be to use a long value of Long.MAX_VALUE since there is no way to know
> how many messages may be received.  And what if the programmer asks
> for 1 message and the next message has 3 parts.  We're screwed.
> Additionally, the documentation specifically states that the
> WebSocket.Listener does not distinguish between partial and whole
> messages.  The jdk8 implementation decoders/encoders accumulate
> messages and assemble them until the message is complete and then pass
> it to the Endpoint -- much more satisfactory arrangement.
> I cannot fathom the meaning or improvement of this new wrinkle.
> Thanks for any insight

*James Roper*
*Senior Octonaut*

Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>

Reply via email to