Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

[Viktor Klang]

On Tue, Apr 17, 2018 at 6:28 PM, Chris Hegarty <chris.hega...@oracle.com>
wrote:

> On 17 Apr 2018, at 17:52, Viktor Klang <viktor.kl...@gmail.com> wrote:
> > ...
> > There is technical and non-technical effort required. It is non-trivial.
> > That said, we’re making every effort possible to move this forward.
> >
> > Hi Chris,
> >
> > how can we help?
>
> Thank you for asking, but I think we have it under control. I hope
> to have news on this in the next couple of weeks.
>

Ok!


>
> -Chris.




-- 
Cheers,
√

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

[Viktor Klang]

On Tue, Apr 17, 2018 at 9:55 AM, Chris Hegarty 
wrote:

> Simone,
>
> > On 16 Apr 2018, at 18:47, Simone Bordet  wrote:
> >
> >> ...
> >
> > Out of curiosity, is this code implementing the ReactiveStreams TCK
> > (in its Flow declination) ?
>
> The code should be compliant with the RS TCK.
>
> > I ask because I have recently implemented it for Jetty's Reactive
> > HttpClient (https://github.com/jetty-project/jetty-reactive-httpclient)
> > and found a few surprising failures.
>
> If you encounter failures can you please report those to us, since
> we are not aware of such.
>
> > It will be great if this can be done because all ReactiveStreams
> > implementations implement the ReactiveStreams TCK, and so there is an
> > assumed baseline of how these libraries should work that is beneficial
> > for interoperability.
>
> Of course, interoperability is of utmost importance.
>
> > The effort is not much: each Publisher/Processor/Subscriber
> > implementation should just extend a ReactiveStream TCK class
> > overriding a few methods, for example:
> > https://github.com/jetty-project/jetty-reactive-
> httpclient/blob/master/src/test/java/org/eclipse/jetty/
> reactive/client/internal/QueuedSinglePublisherTCKTest.java
>
> There is technical and non-technical effort required. It is non-trivial.
> That said, we’re making every effort possible to move this forward.
>

Hi Chris,

how can we help?


>
> -Chris.
>
>


-- 
Cheers,
√

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

[Viktor Klang]

Hi Simone!

:)

I think James conveyed basically everything I had in mind to respond, but I
felt compelled to address the following:

>Forcing users to implement Subscribers or Processors (because that's
what the API requires, despite having a few utilities that cover the
common cases) is way more difficult for users than just passing around
a Publisher.

Simply because an API has an interface type as an parameter or a return
value does not (in my mind) in any way imply that end-users (think:
application developers) are required, encouraged, forced, or otherwise, to
create their own implementations of said interface types to be able to use
it. What is pretty awesome though is if someone has a need for
functionality not provided elsewhere, is that Reactive Streams has a formal
specification and a—free and readily available—TCK to guide implementors to
implement them correctly.


On Mon, Apr 2, 2018 at 2:09 PM, Simone Bordet 
wrote:

> James,
>
> perhaps I was not clear enough.
>
> The JDK will offer an API based on RS, so that's a user-facing API.
>
> Given that, the question is whether the surface of exposition to users
> when they want to use the JDK HttpClient API should be limited to
> Publishers, or expanded to Publishers, Subscribers and Processors.
> My suggestion was to limit it to Publishers only.
> Forcing users to implement Subscribers or Processors (because that's
> what the API requires, despite having a few utilities that cover the
> common cases) is way more difficult for users than just passing around
> a Publisher.
>
> It is by exposing Publishers only that you get rid of the need for
> users to implement any of the RS interfaces to interoperate with other
> libraries.
>
> I'm not sure I buy your opinion on the RxJava2 and Reactor libraries
> (peace! :)
> Both have plenty APIs to create a Flowable/Flux from Publishers, and
> almost none to handle Subscribers: Publishers are exposed, Subscribers
> hidden.
> I don't see any confusion.
>
> Thanks !
>
> --
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz
>



-- 
Cheers,
√

Re: websockets

[Viktor Klang]

Hi Chuck,

(Disclosure: I'm an RS SIG founding member.)

On Sat, Feb 10, 2018 at 7:14 PM, Chuck Davis  wrote:

> Hi James:
>
> Thanks for your response and the information in your (and other)
> blog(s).  I haven't had time to learn all the new features of jdk9 yet
> so a look at Flow was interesting.
>
> My first impression is that a time constraint would be better than
> destroying asynchrony.


The good new is that no asynchrony is destroyed. The first sentence of
reactive-streams.org quite literally says:

"Reactive Streams is an initiative to provide a standard for *asynchronous*
stream processing with non-blocking back pressure." (emphasis mine)


> Rather than telling the source to only send
> one message and thus effectively make it a synchronous process, tell
> the source to only send one message per 100 millis or 1000 millis or
> whatever is appropriate back-pressure while my other threads are doing
> their thing ??


Not only would that not work—as in solve the problem—and it would lead to
abysmal performance.



> When the WebSocket.Listener has a complete message
> trigger a notification event to registered listeners.  And if the
> programmer wants to process intermediate results that would not be too
> difficult for the listener to track.
>
> I can understand the potential need for "back-pressure" but I think
> conserving the asynchronous nature of WebSocket is a high priority as
> well.  Indeed, I've built my application on that feature of
> WebSockets.
>

Fortunately there is no tradeoff needed there. :-)


>
> Thanks again.  At least I'm a bit more enlightened about the issue
> being addressed.
>
> Chuck
>
>
>
>
>
> On Fri, Feb 9, 2018 at 11:38 PM, James Roper  wrote:
> > 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
> > spec:
> >
> > https://developer.lightbend.com/blog/2018-02-06-reactive-
> streams-ee4j/index.html
> >
> > Regards,
> >
> > James
> >
> > On 9 February 2018 at 19:16, Chuck Davis  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
>