HttpServer Underlying Downstream HttpClient Connection Getting Closed Quietly about reactor-netty

[violetagg]

@ragini16071998 Please provide some reproducible example.

[ragini16071998]

Hi @violetagg ,
Find below the reproducible example.
Here client server dependency looks like:
client1 -> server1(client2 -> server2)

Since we are doing some logging on the server1 side by using some HttpClient methods like doOnRequestError, doOnResponse, doOnResponseError etc(refer client2 config), but in case of client1 responseTimeout, we are not able to log anything because the client2 channel gets closed quietly and it doesn't get captured neither in doOnRequestError method nor in doOnResponseError method hence for such client1 API calls we are not able to log response status.

    @Test
    public void testMethod() {

        HttpServer server2 =
                HttpServer.create()
                        .port(8086)
                        .route(r ->
                                r.get("/goodMorning",
                                        (req, res) ->
                                                res.sendString(Mono.just("Good Morning!").delayElement(java.time.Duration.ofSeconds(1))
                                                )));


        DisposableServer ds2 = server2.bindNow();

        HttpClient client2;
        client2 = HttpClient.create()
                .port(ds2.port())
                .doOnRequestError((req, error) -> System.out.println("RequestError: " + error.getMessage()))
                .doOnResponse((res, anything) -> System.out.println("ResponseMessage: " + res))
                .doOnResponseError((res, error) -> System.out.println("ResponseError: " + error.getMessage()))
                .doOnDisconnected((conn) -> System.out.println("Disconnected: " + conn));

        HttpServer server1 =
                HttpServer.create()
                        .port(8085)
                        .route(r -> r.get("/hello",
                                (req, res) ->

                                        res.sendString(client2.get()
                                                .uri("/goodMorning")
                                                .responseContent()
                                                .aggregate()
                                                .asString())));

        DisposableServer ds = server1.bindNow();

        HttpClient client1;
        client1 = HttpClient.create()
                .port(ds.port())
                .responseTimeout(java.time.Duration.ofMillis(5000));
        String response =
                client1.get()
                        .uri("/hello")
                        .responseContent()
                        .aggregate()
                        .asString()
                        .block();

        System.out.println("Final Response: " + response);
    }

[violetagg]

@ragini16071998 Thanks a lot for the test, this makes things clear.

You have this:

client1 -> server1(client2) -> server2
         ^                   ^
       connection1         connection2

Your configuration with doOn... covers the connection2, while what actually happens is that connection1 is closed due to a timeout.

When connection1 is closed, the only thing that the server1 will do is to cancel the Publisher provided by client2. You need to start listening for that kind of cancellations. Here is the configuration that you need:

HttpServer server1 =
		HttpServer.create()
			.port(8085)
			.route(r -> r.get("/hello",
				(req, res) ->
					res.sendString(client2.get()
							.uri("/goodMorning")
							.responseContent()
							.aggregate()
							.asString())
						.then()
--> listen for cancel signal			.doOnCancel(() -> System.out.println("Cancel signal received"))));

This explains why you are entering the code in your first comment -> because the inbound was canceled.

You can also add doOnCancel on the level of client2

client2.get()
	.uri("/goodMorning")
	.responseContent()
	.aggregate()
	.asString()
	.doOnCancel(...)

[violetagg]

Here you can find an interesting implementation similar to your test https://github.com/spring-cloud/spring-cloud-gateway/blob/fb3b782afc40db9c220667ff8cc52d4968075099/spring-cloud-gateway-server/src/main/java/org/springframework/cloud/gateway/filter/NettyWriteResponseFilter.java#L64-L104
https://github.com/spring-cloud/spring-cloud-gateway/blob/fb3b782afc40db9c220667ff8cc52d4968075099/spring-cloud-gateway-server/src/main/java/org/springframework/cloud/gateway/filter/NettyRoutingFilter.java#L147-L199

[violetagg]

@ragini16071998 I'm closing this as I think there is no issue with Reactor Netty. We can reopen it if needed.