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

[Sebastien Deleuze]

Michael, Chris,

Thanks for your feedback, indeed with PublishingBodySubscriber, it works
also for streaming use cases and it provides the behavior I was trying to
achieve.
So +1 for inclusion of JDK-8201186 in JDK 11.

On Thu, Apr 5, 2018 at 6:12 PM, Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Hi Sebastien,
>
> > On 5 Apr 2018, at 11:07, Sebastien Deleuze <sdeleuze at pivotal.io> wrote:
> >
> > Hi,
> >
> > I am currently implementing a draft support for JDK new HTTP client in
> Spring Framework 5 [1] (using JDK 10 for now) in order to be able to
> leverage it as a WebClient [2] engine.
>
> Great that you are trying this out.
>
> > Our integration tests all pass with regular HTTP/1.1 web services
>
> Good to hear this.
>
> > (we have not tested the HTTP/2 support yet), but not with streaming APIs.
>
> Reactive streams APIs consist of both Publishers and Subscribers, but
> in your specific case you appear to most interested in Publishers. I'll
> assume "streaming APIs” here means "RS Publishers", since the HTTP
> Client quite obvious interoperates with Subscribers.
>
> > Based on my current understanding, it seems the CompletableFuture<HttpResponse>
> returned by HttpClient#sendAsync completes only when all the data of the
> response body is available, not asap the status code + headers are
> available like with Jetty or Reactor Netty clients (which prevents to
> consume infinite streams via Reactive Streams API).
>
> As Michael has already said, it can operate either way depending on the
> actual higher-level Java type that the body is being converted to. In
> fact, you can even write your own BodyHandler that returns a Subscriber
> with an already complete body CF. So there is no issue working with
> infinite streams via RS, if that is what you want.
>
> I believe what you are actually seeking is a
> `BodyHandler<Publisher<List<ByteBuffer>>>`, that makes its HttpResponse
> available once the headers have been received. This has come up just
> recently, in this email thread [1]. A JIRA issue has been filed to track
> the addition of such a BodyHandler [2].
>
> In the interim, until the new handler can been added, it should be
> possible to either write your own ( Daniel has similar,
> `static class PublishingBodySubscriber implements
>     BodySubscriber<Publisher<List<ByteBuffer>>>`, in a test [3] ). Or
> if your library, or reactor, provides functionality similar to
> `io.reactivex.processors.PublishProcessor`, then you can use it as the
> BodyHandler type and write a delegating BodySubscriber that
> completes its body CF immediately with an instance of that processor.
>
> > Is consuming streaming HTTP/1.1 endpoints (like JSON streaming or SSE)
> supported by current implementation?
>
>
> Yes, but of course not out of the box, you need to hook up to a JSON
> Subscriber, etc.
>
> -Chris.
>
> [1] http://mail.openjdk.java.net/pipermail/net-dev/2018-April/011314.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8201186
> [3] http://hg.openjdk.java.net/jdk/sandbox/file/c59f684f1eda/
> test/jdk/java/net/httpclient/ResponsePublisher.java
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180405/0d7ed98f/attachment.html>