onComplete of All Data Received Signal Available Without Receive about reactor-netty HOT 5 CLOSED

@nebhale do you have a more specific use-case? As you said, the Mono<HttpClientResponse> does indeed complete based on the reception of the response headers, aka the request has been done.

There are several caveats that make your feature request impractical. Most notably, waiting for the receiveContent() to complete before emitting the response would make the body of the response unusable:

• the FluxReceiver will release() http content as it is emitted
• it only allows one subscription

So the idiomatic way of working with the response would be to flatMap to receiveContent() and deal with the content (before it is released).

That said, if you're only interested in the headers or status code, but you only want to evaluate those once the response has completed, you could now use delayUntil(HttpClientResponse::receiveContent).

How does that sound? Do you feel there's really a need for a deeper cross-cutting change in the behavior and design of FluxReceiver?

from reactor-netty.

@simonbasle I don't believe that the receiveContent() hook is sufficient, as it puts you in a situation where you cannot generically handle the end of a response. If you take a look at AbstractReactorOperations we want to be able to time how long a request and response pair takes.

At the moment, it's wrong on both ends. We can only intercept the onSubscribe, not when the first byte of the request goes out. So you could imagine a chain of multiple requests each using data from the previous request. The timer on the final one starts long before it actually sends a request. Then at the other end, we can only generically intercept the finish of the response, not when all of the data is actually complete. As you can see in that class, it's a generic base class that is supposed to remove all of the "standard" logging, error handling, etc. But since we hand back the Mono<HttpClientResponse> back to the caller, potentially before any .receive* is called, we can't intercept that late and still have all the appropriate timing context. It also would break the the point of the class that it handles a bunch of "standard" behavior so the thousands of other users don't have to.

from reactor-netty.

🤔 just a wild thought: for the purpose of this kind of measurements, closer to the wire, I wonder if a workaround could be to add a special netty handler to the pipeline that does the timings. Did you explore that solution by any chance?

from reactor-netty.

I did not because I'm a reactor-netty user, not a Netty user 😉. It means that I have to drop to a non-blocking, but non-reactive API which seems onerous for a reactor-netty user. I chose to use a higher-level API in part because I didn't want to write to Netty's API. I find Reactor so much better and easier to use, that something as simple as intercepting first and last byte shouldn't require abandoning it.

from reactor-netty.

@nebhale @simonbasle I believe this can be achieved with the lifecycle callbacks.
https://projectreactor.io/docs/netty/snapshot/reference/index.html#_lifecycle_callbacks_4

from reactor-netty.