[
https://issues.apache.org/jira/browse/HTTPCLIENT-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589200#comment-16589200
]
Ryan Schmitt commented on HTTPCLIENT-1942:
------------------------------------------
{quote}You might want to re-consider this approach and use a custom callback to
signal availability of {code}Publisher<ByteBuffer>{code} and use
{code}FutureCallback{code} for its original purpose.{quote}
Thanks, this is definitely a better fit. Here's what I have currently, let me
know if you think the use of {code}Future<Void>{code} is too weird:
{code|java}
final ReactiveResponseConsumer consumer = new
ReactiveResponseConsumer();
final Future<Void> future = requester.execute(request, consumer,
Timeout.ofSeconds(5),
new FutureCallback<Void>() {
public void completed(Void result) {}
public void failed(Exception ex) {}
public void cancelled() {}
}
);
Message<HttpResponse, Publisher<ByteBuffer>> response =
consumer.getResponseFuture().get();
{code}
{quote}That depends on the exception type. If an exception is deemed severe
enough to make the entire connection unreliable for all streams the protocol
handler sends GOAWAY frame to the opposite endpoint.{quote}
This is true; the problem is that I'm only able to throw a "severe" exception.
In the call stack for the {code}produce{code} method, there are three
interesting catch blocks:
1. {code}AbstractHttp2StreamMultiplexer$Http2Stream{code} catches
{code}ProtocolException{code} and invokes {code}localReset(ex,
H2Error.PROTOCOL_ERROR){code}
2. {code}AbstractHttp2IOEventHandler{code} catches {code}HttpException{code}
and invokes {code}streamMultiplexer.onException(ex){code}
3. {code}InternalChannel{code} catches {code}Exception{code} and invokes
{code}onException(ex){code} (which also ends up delegating to the
{code}streamMultiplexer{code}, in my case)
This appears to mean that {code}ProtocolException{code} is what I actually want
to throw; the problem is that that is a checked exception, and not derived from
{code}IOException{code} (the only exception declared by
{code}AsyncDataProducer#produce{code}). If I use the sneaky throw technique to
throw {code}ProtocolException{code} anyway, my
{code}ReactiveResponseConsumer{code} gets called back with the thrown exception
before {code}releaseResources{code} is called, whereas previously only
{code}releaseResources{code} was being called.
How should this be handled? I can see a few options:
1. Continue to sneaky-throw a {code}ProtocolException{code}
2. Change the {code}AsyncDataProducer{code} interface to include
{code}ProtocolException{code} or {code}HttpException{code}
3. Catch some unchecked exception in
{code}AbstractHttp2StreamMultiplexer$Http2Stream{code} that will be treated
like a {code}ProtocolException{code}
Let me know what your preference is.
> Add support for Reactive Streams
> --------------------------------
>
> Key: HTTPCLIENT-1942
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1942
> Project: HttpComponents HttpClient
> Issue Type: Wish
> Components: HttpClient (async)
> Affects Versions: 5.0 Beta1
> Reporter: Ryan Schmitt
> Priority: Major
> Labels: stuck, volunteers-wanted
> Fix For: Future
>
>
> It would be very helpful to me if the Apache client provided an
> implementation of the [Reactive Streams|http://www.reactive-streams.org/]
> spec, particularly as an implementation of the standard
> [interfaces|https://search.maven.org/artifact/org.reactivestreams/reactive-streams/1.0.2/jar].
> These interfaces are JDK6-compatible and have no other dependencies, but
> they unlock interoperability with many other frameworks, such as RxJava.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
