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.hega...@oracle.com> wrote: > Hi Sebastien, > > > On 5 Apr 2018, at 11:07, Sebastien Deleuze <sdele...@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 >
