Close an HTTP/1.1 connection after delay #5616

dachshu · 2024-04-17T02:03:08Z

Motivation:

Closes Close an HTTP/1.1 connection after delay #4849
To suppress a server socket from remaining in the TIME_WAIT state instead of CLOSED when a connection is closed.

Modifications:

Remove the force shutdown mode of AbstractHttpResponseHandler that is activated when a user sets the Connection: close HTTP header
Create a schedule that waits and closes the connection to wait for the client-side connection to close, rather than closing the HTTP/1.1 connection immediately.

Result:

Closes Close an HTTP/1.1 connection after delay #4849
When a user wants to close an HTTP/1.1 server connection, the armeria server first waits for the client to close the connection for a while to make the connection state to CLOSED instead of TIME_WAIT.

CLAassistant · 2024-04-17T02:03:13Z

All committers have signed the CLA.

github-actions · 2024-04-17T03:21:30Z

🔍 Build Scan® (commit: `596b223`)

Job name	Status	Build Scan®
build-windows-latest-jdk-21	✅	https://ge.armeria.dev/s/5waqxdyew7bpw
build-self-hosted-unsafe-jdk-8	✅	https://ge.armeria.dev/s/invs7rd7eogyo
build-self-hosted-unsafe-jdk-21-snapshot-blockhound	✅	https://ge.armeria.dev/s/nza6his2f7dhy
build-self-hosted-unsafe-jdk-17-min-java-17-coverage	✅	https://ge.armeria.dev/s/ncas2zwrbv67i
build-self-hosted-unsafe-jdk-17-min-java-11	✅	https://ge.armeria.dev/s/qov5igwrcmcey
build-self-hosted-unsafe-jdk-17-leak	✅	https://ge.armeria.dev/s/nwk6m7sjehp62
build-self-hosted-unsafe-jdk-11	✅	https://ge.armeria.dev/s/ne7f4532ze7gm
build-macos-12-jdk-21	✅	https://ge.armeria.dev/s/2spxi2yyxc2uk

jrhee17

Looks good overall! Left some minor comments 🙇

jrhee17 · 2024-04-17T04:44:45Z

core/src/main/java/com/linecorp/armeria/server/HttpServerHandler.java

@@ -780,7 +780,9 @@ private void handleRequestOrResponseComplete() {
                        // Stop receiving new requests.
                        handledLastRequest = true;
                        if (unfinishedRequests.isEmpty()) {
-                            ctx.writeAndFlush(Unpooled.EMPTY_BUFFER).addListener(CLOSE);
+                            ctx.executor().schedule(() ->


ServiceRequestContext#executor isn't necessarily the same as Channel#eventLoop

armeria/core/src/main/java/com/linecorp/armeria/server/HttpServerHandler.java

Lines 375 to 387 in 1d268aa

final EventLoopGroup serviceWorkerGroup = serviceCfg.serviceWorkerGroup();

if (serviceWorkerGroup == config.workerGroup()) {

serviceEventLoop = channelEventLoop;

needsDirectExecution = true;

} else {

serviceEventLoop = serviceWorkerGroup.next();

needsDirectExecution = serviceEventLoop == channelEventLoop;

}

final DefaultServiceRequestContext reqCtx = new DefaultServiceRequestContext(

serviceCfg, channel, serviceEventLoop, config.meterRegistry(), protocol,

nextRequestId(routingCtx, serviceCfg), routingCtx, routingResult, req.exchangeType(),

req, sslSession, proxiedAddresses, clientAddress, remoteAddress, localAddress,

req.requestStartTimeNanos(), req.requestStartTimeMicros(), serviceCfg.contextHook());

We probably want to close from the channel's event loop (otherwise, an exception will be raised)

Suggested change

ctx.executor().schedule(() ->

ctx.channel().eventLoop().schedule(() ->

Oh I missed it. Thanks for letting me know.
I fixed it to use the channel's event loop.

jrhee17 · 2024-04-17T04:45:38Z

core/src/main/java/com/linecorp/armeria/server/HttpServerHandler.java

-                            ctx.writeAndFlush(Unpooled.EMPTY_BUFFER).addListener(CLOSE);
+                            ctx.executor().schedule(() ->
+                                            ctx.writeAndFlush(Unpooled.EMPTY_BUFFER).addListener(CLOSE),
+                                            1000, TimeUnit.MILLISECONDS);


optional nit; using seconds is probably slightly easier to reason about

Suggested change

1000, TimeUnit.MILLISECONDS);

1, TimeUnit.SECONDS);

I think this value can be configured in milliseconds on fast networks.

jrhee17 · 2024-04-17T05:35:12Z

#5616 (comment)
Please also sign the CLA 🙇

ikhoon · 2024-04-22T09:22:44Z

core/src/main/java/com/linecorp/armeria/server/HttpServerHandler.java

@@ -780,7 +780,9 @@ private void handleRequestOrResponseComplete() {
                        // Stop receiving new requests.
                        handledLastRequest = true;
                        if (unfinishedRequests.isEmpty()) {
-                            ctx.writeAndFlush(Unpooled.EMPTY_BUFFER).addListener(CLOSE);
+                            ctx.executor().schedule(() ->
+                                            ctx.writeAndFlush(Unpooled.EMPTY_BUFFER).addListener(CLOSE),


Could we check if the channel is still active? Meanwhile, the channel may have been closed.

Thanks for checking! I added to check ctx.channel().isActive() before executing the close task.

trustin

We need a test case. You might want to implement a simple low-level HTTP/1 client in your test to know the socket-level timings.

I'd recommend checking out the source code of Http1ServerKeepAliveTest to get the basic ideas.

…th the flag

…ent loop

…thTest

…or the server to close the connection

…tionTest

…ction

…nectionTest

…layedCloseConnectionTest

jrhee17 · 2024-04-30T08:43:20Z

Looking into the failing test, I guess there is a case where Connection: close header isn't sent but we set needsDisconnection() somewhere.

jrhee17

Looks good overall! Left a few style related comments 🙇

jrhee17 · 2024-04-30T06:46:21Z

core/src/main/java/com/linecorp/armeria/server/HttpServerHandler.java

+                            ctx.channel().eventLoop().schedule(() -> {
+                                    if (ctx.channel().isActive()) {
+                                        ctx.writeAndFlush(Unpooled.EMPTY_BUFFER).addListener(CLOSE);
+                                    }
+                                }, Flags.defaultHttp1ConnectionCloseDelayMillis(), TimeUnit.MILLISECONDS);


Can you align these lines? (you may also want to check if code style is correctly set in your IDE ref: https://armeria.dev/community/developer-guide#setting-up-your-ide)

Suggested change

ctx.channel().eventLoop().schedule(() -> {

if (ctx.channel().isActive()) {

ctx.writeAndFlush(Unpooled.EMPTY_BUFFER).addListener(CLOSE);

}

}, Flags.defaultHttp1ConnectionCloseDelayMillis(), TimeUnit.MILLISECONDS);

ctx.channel().eventLoop().schedule(() -> {

if (ctx.channel().isActive()) {

ctx.writeAndFlush(Unpooled.EMPTY_BUFFER).addListener(CLOSE);

}

}, Flags.defaultHttp1ConnectionCloseDelayMillis(), TimeUnit.MILLISECONDS);

Thanks for letting me know. I have checked that the code style setting was not set correctly.
I have fixed the code above.

jrhee17 · 2024-04-30T07:00:55Z

core/src/test/java/com/linecorp/armeria/server/HttpServerPathTest.java

@@ -121,7 +121,11 @@ private static void urlPathAssertion(HttpStatus expected, String path) throws Ex
        try (Socket s = new Socket(NetUtil.LOCALHOST, server.httpPort())) {
            s.setSoTimeout(10000);
            s.getOutputStream().write(requestString.getBytes(StandardCharsets.US_ASCII));
-            assertThat(new String(ByteStreams.toByteArray(s.getInputStream()), StandardCharsets.US_ASCII))
+            final BufferedReader in = new BufferedReader(


Question) I think the previous approach of collecting all bytes was correct (in the off-chance that the bytes are fragmented). What do you think of reverting this file?

Due to the following implementation, the ByteStreams.toByteArray(s.getInputStream()) call returns the value when the inputStream is closed which is only happened when the connection is closed from the server.
https://github.com/google/guava/blob/master/guava/src/com/google/common/io/ByteStreams.java#L195~L198

With this PR, I changed the server to wait for the client to close first instead of closing the connection immediately. However in this test, the client receives the Connection: Close header from the server but ignores it. So the test waits for the server to close the connction, causing the test timeout.
I tried to adjust the defaultHttp1ConnectionCloseDelayMillis using @SetSystemProperty or System.setProperty() to reduce the test time, but it didn't work well in shadedTest 😭
Since only the first line is needed for this test validation, I changed it to read only the first line and check the result to make the test take less time.
If it is a problem, I would consider reducing the defaultHttp1ConnectionCloseDelayMillis.

I see, I think I missed this point. I think it's fine to leave as-is then. Thanks for the explanation 👍

I tried to adjust the defaultHttp1ConnectionCloseDelayMillis using @SetSystemProperty or System.setProperty() to reduce the test time, but it didn't work well in shadedTest

I assume this is because Flags is already initialized when other tests are run or ServerExtension is constructed.

jrhee17 · 2024-04-30T07:02:08Z

core/src/test/java/com/linecorp/armeria/server/Http1ServerDelayedCloseConnectionTest.java

+    }
+
+    @Test
+    void shouldWaitForDisconnectByClientSideFirst() throws IOException {


Question) I didn't understand the intention of this test. If the functionality isn't very different from shouldDelayDisconnectByServerSideIfClientDoesNotHandleConnectionClose, what do you think of just removing it?

The shouldWaitForDisconnectByClientSideFirst test checks if the server sends the Connection: close header and waits for the client to close the connection first, rather than closing the connection immediately. It additionally checks if the server closes the connection after the client closes it.
On the other hand, the shouldDelayDisconnectByServerSideIfClientDoesNotHandleConnectionClose test verifies that if the client receives the Connection: close header but ignores it without attempting to close the connection, and the close connection task scheduled by the server executes well waiting for the set time on the sever side before closing the connection.
Therefore, I wrote two tests because I think the purpose of the two tests and what they verify are different.

I see, I think I missed that point in the last review cycle. Thanks for the explanation 👍

jrhee17 · 2024-04-30T07:11:14Z

core/src/test/java/com/linecorp/armeria/server/Http1ServerDelayedCloseConnectionTest.java

+        final short localPort = (short) random.nextInt(Short.MAX_VALUE + 1);
+        try (Socket socket = new Socket("127.0.0.1", server.httpPort(),  null, localPort)) {


I think it's 1) overkill to check the socket state as this is out of our control 2) binding to a random socket introduces unnecessary flakiness.

Instead of testing the OS's behavior of managing TCP states, what do you think of sticking to testing the behavior of the server-side closing the connection? (So what do you think of removing the localPort related logic?)

I thought the purpose of this PR is to prevent the server's socket state from getting in TIME_WAIT by waiting for the client to close the connection first. Therefore, I thought it was necessary to check which side closed the connection, and as a way to check this behaviour I thought it was meaningful to try to reuse the client socket and check which side performed the close first through immediate reusability.
In order to try to reuse the client socket, it is necessary to test by setting the port number directly instead of using the port number assigned by the OS, so I implemented the test by setting the localPort number.
I agree with the risk of using a random port number as you mentioned, and I found there is a function socket.getLocalPort(). So I fixed it to reuse the port number assigned from the OS.
However, if checking the socket state like this is unnecessary, I would remove the part about checking if the socket is in TIME_WAIT or CLOSE state through socket reuse!

I think as long as the test consistently passes it is OK to keep the behavior 👍

jrhee17 · 2024-04-30T10:03:16Z

Went through the code, and I think the issue is the following:

The test failure occurs when testTooLargeContentToNonExistentService is run, and then testStreamingResponseWithSlowClient is run with HTTP1.1. The two use the same ClientFactory, and hence reuse connections.
- armeria/core/src/test/java/com/linecorp/armeria/server/HttpServerStreamingTest.java
  
  Line 161 in 0a5a3d7
  
  void testTooLargeContentToNonExistentService(WebClient client) throws Exception {
- armeria/core/src/test/java/com/linecorp/armeria/server/HttpServerStreamingTest.java
  
  Line 220 in 0a5a3d7
  
  void testStreamingResponseWithSlowClient(WebClient client) throws Exception {
When testTooLargeContentToNonExistentService is run, a 404 is returned from the FallbackService. This response is subsequently written to the wire without rescheduling.
- armeria/core/src/main/java/com/linecorp/armeria/server/FallbackService.java
  
  Line 46 in 0a5a3d7
  
  return handleNotFound(ctx, routingCtx);
However, afterwards the request is continuously consumed and reaches maxRequestLength. At this point, we set disconnectWhenFinished although the response has already been written. Hence, we don't have a chance to send a Connection: close header to the client.
- armeria/core/src/main/java/com/linecorp/armeria/server/Http1RequestDecoder.java
  
  Line 324 in 0a5a3d7
  
  keepAliveHandler.disconnectWhenFinished();
Since we don't close the connection immediately, the client believes the connection is healthy and tries to reuse this connection. However, the discarding flag is already set and ensuing requests are silently ignored
- armeria/core/src/main/java/com/linecorp/armeria/server/Http1RequestDecoder.java
  
  Line 320 in 0a5a3d7
  
  discarding = true;
Lastly, the idle timeout kicks in which fails the test

Overall, I think it's probably fine to just close the connection immediately if we can't write the 413 response headers. This isn't a perfect solution, but at least preserves backwards compatibility.

We can check encoder.isResponseHeadersSent(id, 1) at the following location, and close the channel immediately if the response headers have already been written.
- armeria/core/src/main/java/com/linecorp/armeria/server/Http1RequestDecoder.java
  
  Lines 324 to 325 in 0a5a3d7
  
  keepAliveHandler.disconnectWhenFinished();
  
  shouldReset = false;
Otherwise the 413 with Connection: close will be written, so we can preserve the previous behavior.

…dy sent on HTTP1.1

dachshu · 2024-05-06T13:01:40Z

#5616 (comment)

When also I analysed the reason for the failure of this test, I found that the response is sent immediately at 404. And when the content size exceeds maxRequestLength while reading the rest of the request content, the Connetion: close header is not sent and the server closes the connection. The problem was that the connection discarding flag was set and the will be closed soon was reused in the next test. Because this PR does not check if a response has already been sent, but just waits for the set time before closing the connection, the client didn't know that the connection was about to be closed and reused it causing the connection to be closed during the test.
To solve this, I was trying to figure out how to make it fail fast, as I think the correct behaviour is to ignore the content if it's a 404.
If I knew the length of the content, it shouldn't be a problem. But I thought there might be an issue with using chunked transfer encoding.
I also wondered if it would be better to just set discarding to true and read the request to the end and send the response, since even in the 404, the server reads all the content sent by the client anyway.
When I thought about the method you advised, it might be a problem when it takes a long time to reach the content max length so the same phenomenon can occur like in the test. It would look like the connection is suddenly closed from the client's point of view.
However, I will modify it to ensure backwards compatibility as you advised and consider a better way as another issue.
Thanks for your advice 🙇

jrhee17

Looks good for merging to me. Thanks for tackling this difficult issue @dachshu! 🙇 👍 🙇

jrhee17 · 2024-05-08T00:51:25Z

core/src/test/java/com/linecorp/armeria/server/HttpServerPathTest.java

@@ -121,7 +121,11 @@ private static void urlPathAssertion(HttpStatus expected, String path) throws Ex
        try (Socket s = new Socket(NetUtil.LOCALHOST, server.httpPort())) {
            s.setSoTimeout(10000);
            s.getOutputStream().write(requestString.getBytes(StandardCharsets.US_ASCII));
-            assertThat(new String(ByteStreams.toByteArray(s.getInputStream()), StandardCharsets.US_ASCII))
+            final BufferedReader in = new BufferedReader(


I see, I think I missed this point. I think it's fine to leave as-is then. Thanks for the explanation 👍

I tried to adjust the defaultHttp1ConnectionCloseDelayMillis using @SetSystemProperty or System.setProperty() to reduce the test time, but it didn't work well in shadedTest

I assume this is because Flags is already initialized when other tests are run or ServerExtension is constructed.

jrhee17 · 2024-05-08T01:12:24Z

core/src/test/java/com/linecorp/armeria/server/Http1ServerDelayedCloseConnectionTest.java

+            final BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
+            assertThat(in.readLine()).isEqualTo("HTTP/1.1 200 OK");
+
+            String line;
+            boolean hasConnectionClose = false;
+            while ((line = in.readLine()) != null) {
+                if ("connection: close".equalsIgnoreCase(line)) {
+                    hasConnectionClose = true;
+                }
+                if (line.isEmpty() || line.contains(":")) {
+                    continue;
+                }
+                if (line.startsWith("OK")) {
+                    break;
+                }
+            }
+            assertThat(hasConnectionClose).isTrue();


ditto

Suggested change

final BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()));

assertThat(in.readLine()).isEqualTo("HTTP/1.1 200 OK");

String line;

boolean hasConnectionClose = false;

while ((line = in.readLine()) != null) {

if ("connection: close".equalsIgnoreCase(line)) {

hasConnectionClose = true;

}

if (line.isEmpty() || line.contains(":")) {

continue;

}

if (line.startsWith("OK")) {

break;

}

}

assertThat(hasConnectionClose).isTrue();

final BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()));

assertThat(in.readLine()).isEqualTo("HTTP/1.1 200 OK");

in.readLine(); // content-type

in.readLine(); // content-length

in.readLine(); // server

in.readLine(); // date

assertThat(in.readLine()).isEqualToIgnoringCase("connection: close");

assertThat(in.readLine()).isEmpty();

assertThat(in.readLine()).isEqualToIgnoringCase("OK");

I changed it to read reads each line!

jrhee17 · 2024-05-08T01:12:46Z

core/src/test/java/com/linecorp/armeria/server/Http1ServerDelayedCloseConnectionTest.java

+            final BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
+            assertThat(in.readLine()).isEqualTo("HTTP/1.1 200 OK");
+
+            String line;
+            boolean hasConnectionClose = false;
+            while ((line = in.readLine()) != null) {
+                if ("connection: close".equalsIgnoreCase(line)) {
+                    hasConnectionClose = true;
+                }
+                if (line.isEmpty() || line.contains(":")) {
+                    continue;
+                }
+                if (line.startsWith("OK")) {
+                    break;
+                }
+            }


nit, can we just explicitly check each line?

Suggested change

final BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()));

assertThat(in.readLine()).isEqualTo("HTTP/1.1 200 OK");

String line;

boolean hasConnectionClose = false;

while ((line = in.readLine()) != null) {

if ("connection: close".equalsIgnoreCase(line)) {

hasConnectionClose = true;

}

if (line.isEmpty() || line.contains(":")) {

continue;

}

if (line.startsWith("OK")) {

break;

}

}

final BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()));

assertThat(in.readLine()).isEqualTo("HTTP/1.1 200 OK");

in.readLine(); // content-type

in.readLine(); // content-length

in.readLine(); // server

in.readLine(); // date

assertThat(in.readLine()).isEqualToIgnoringCase("connection: close");

assertThat(in.readLine()).isEmpty();

assertThat(in.readLine()).isEqualToIgnoringCase("OK");

I refactored it too 🙇

jrhee17 · 2024-05-08T01:13:03Z

core/src/test/java/com/linecorp/armeria/server/Http1ServerDelayedCloseConnectionTest.java

+    }
+
+    @Test
+    void shouldWaitForDisconnectByClientSideFirst() throws IOException {


I see, I think I missed that point in the last review cycle. Thanks for the explanation 👍

jrhee17 · 2024-05-08T01:13:47Z

core/src/test/java/com/linecorp/armeria/server/Http1ServerDelayedCloseConnectionTest.java

+            assertThatThrownBy(
+                    () -> {
+                        final Socket reuseSock = new Socket("127.0.0.1", server.httpPort(), null, socketPort);
+                        reuseSock.close();


So that we know why this logic exists

Suggested change

reuseSock.close();

// close the socket in case initializing the socket doesn't throw an exception

reuseSock.close();

Thanks for good suggestions 🙇

jrhee17 · 2024-05-08T01:15:22Z

core/src/test/java/com/linecorp/armeria/server/Http1ServerDelayedCloseConnectionTest.java

+        final short localPort = (short) random.nextInt(Short.MAX_VALUE + 1);
+        try (Socket socket = new Socket("127.0.0.1", server.httpPort(),  null, localPort)) {


I think as long as the test consistently passes it is OK to keep the behavior 👍

jrhee17 · 2024-05-08T01:20:07Z

However, I will modify it to ensure backwards compatibility as you advised and consider a better way as another issue.

Thanks! Let us know if you would like to try handling this as a follow-up issue.

trustin

LGTM once @jrhee17's comments are all addressed. Nice job, @dachshu!

ikhoon

Looks good. Left minor comments.

ikhoon · 2024-05-08T06:52:00Z

core/src/main/java/com/linecorp/armeria/common/FlagsProvider.java

@@ -1159,4 +1159,20 @@ default Long defaultUnhandledExceptionsReportIntervalMillis() {
    default DistributionStatisticConfig distributionStatisticConfig() {
        return null;
    }
+
+    /**
+     * Returns the default time in milliseconds to wait before closing an HTTP1 connection when a server needs


nit:

Suggested change

* Returns the default time in milliseconds to wait before closing an HTTP1 connection when a server needs

* Returns the default time in milliseconds to wait before closing an HTTP/1 connection when a server needs

Thank you for helping to correct 🙇

core/src/main/java/com/linecorp/armeria/server/HttpServerHandler.java

minwoox

Left just small suggestions. Thanks!

core/src/main/java/com/linecorp/armeria/common/Flags.java

core/src/main/java/com/linecorp/armeria/server/HttpServerHandler.java

core/src/test/java/com/linecorp/armeria/server/Http1ServerDelayedCloseConnectionTest.java

dachshu · 2024-05-09T12:09:21Z

However, I will modify it to ensure backwards compatibility as you advised and consider a better way as another issue.

Thanks! Let us know if you would like to try handling this as a follow-up issue.

Yes, I would like to!

…ltHttp1ConnectionCloseDelayMillis is 0

…tp1ConnectionCloseDelayMillis is 0

jrhee17

Still looks good to me! 👍 👍

minwoox

Great work, thanks a lot, @dachshu! 👍 👍 👍

ikhoon

Thanks, @dachshu! 🙇‍♂️👍

Motivation: - Closes line#4849 - To suppress a server socket from remaining in the `TIME_WAIT` state instead of `CLOSED` when a connection is closed. Modifications: - Remove the force shutdown mode of `AbstractHttpResponseHandler` that is activated when a user sets the `Connection: close` HTTP header - Create a schedule that waits and closes the connection to wait for the client-side connection to close, rather than closing the HTTP/1.1 connection immediately. Result: - Closes line#4849 - When a user wants to close an HTTP/1.1 server connection, the armeria server first waits for the client to close the connection for a while to make the connection state to `CLOSED` instead of `TIME_WAIT`.

github-actions bot requested review from ikhoon, jrhee17, minwoox and trustin April 17, 2024 02:03

jrhee17 reviewed Apr 17, 2024

View reviewed changes

jrhee17 added the defect label Apr 17, 2024

jrhee17 added this to the 1.29.0 milestone Apr 17, 2024

ikhoon reviewed Apr 22, 2024

View reviewed changes

trustin reviewed Apr 23, 2024

View reviewed changes

dachshu added 6 commits April 24, 2024 09:30

refactor: remove the Force shutdown mode

5b6a9fd

feat: create a schedule for waiting and closing in HTTP1

f01ca8a

feat: define a defaultHttp1ConnectionCloseDelayMillis Flag

824bb23

refactor: replace hardcoded defaultHttp1ConnectionCloseDelayMillis wi…

1d764aa

…th the flag

fix: to schedule the close connection task to run in the channel's ev…

5820fe9

…ent loop

refactor: fix import order

4a7f0ef

dachshu force-pushed the ISSUE-4849-close-connection-after-delay branch from 42f87ea to 4a7f0ef Compare April 24, 2024 00:33

dachshu added 11 commits April 24, 2024 18:12

test: set defaultHttp1ConnectionCloseDelayMillis to 0 on HttpServerPa…

90b5509

…thTest

feat: check the active status of a channel before running a close task

ae86f29

test: read only a first line in HttpServerPathTest to does not wait f…

e74d182

…or the server to close the connection

test: implement test cases for Http1ServerDelayedCloseConnectionTest

4ec928d

test: fix lint errors

abbfc56

test: remove setReuseAddress(true) from Http1ServerDelayedCloseConnec…

f2c64e6

…tionTest

test: add await().untilAsserted to wait for server to close the conne…

29308dd

…ction

test: set socket.setReuseAddress(false) to Http1ServerDelayedCloseCon…

a0c1787

…nectionTest

test: set socket.setReuseAddress(false) to reuseSock in Http1ServerDe…

f966235

…layedCloseConnectionTest

Merge branch 'main' into ISSUE-4849-close-connection-after-delay

38d644e

test: make the bind socket test run only in linux and macos

e0155d7

jrhee17 reviewed Apr 30, 2024

View reviewed changes

dachshu added 2 commits May 3, 2024 22:28

lint: apply code style

151ff7a

feat: make closing connection immediately when the response was alrea…

12a536d

…dy sent on HTTP1.1

feat: fix to not use random port

bbc35b7

dachshu force-pushed the ISSUE-4849-close-connection-after-delay branch from fd7e68e to bbc35b7 Compare May 7, 2024 11:35

Merge branch 'main' into ISSUE-4849-close-connection-after-delay

cd2d1a4

jrhee17 approved these changes May 8, 2024

View reviewed changes

trustin approved these changes May 8, 2024

View reviewed changes

ikhoon reviewed May 8, 2024

View reviewed changes

minwoox reviewed May 8, 2024

View reviewed changes

test: refactor to read each line

32cda15

dachshu added 4 commits May 9, 2024 21:25

docs: clarify the server closes the connection immediately when defau…

83d7ba2

…ltHttp1ConnectionCloseDelayMillis is 0

feat: make the server close the connection immediately when defaultHt…

4a9496f

…tp1ConnectionCloseDelayMillis is 0

test: increase the duration of the connection closure time

3b45ee8

Merge branch 'main' into ISSUE-4849-close-connection-after-delay

51986e3

jrhee17 approved these changes May 10, 2024

View reviewed changes

Merge branch 'main' into ISSUE-4849-close-connection-after-delay

596b223

minwoox approved these changes May 10, 2024

View reviewed changes

ikhoon approved these changes May 10, 2024

View reviewed changes

trustin merged commit 550b931 into line:main May 11, 2024
15 checks passed

minwoox added defect new feature and removed defect labels Jun 4, 2024

minwoox mentioned this pull request Jun 4, 2024

Add ServerBuilder.http1ConnectionCloseDelayMillis() #5721

Open

	final EventLoopGroup serviceWorkerGroup = serviceCfg.serviceWorkerGroup();
	if (serviceWorkerGroup == config.workerGroup()) {
	serviceEventLoop = channelEventLoop;
	needsDirectExecution = true;
	} else {
	serviceEventLoop = serviceWorkerGroup.next();
	needsDirectExecution = serviceEventLoop == channelEventLoop;
	}
	final DefaultServiceRequestContext reqCtx = new DefaultServiceRequestContext(
	serviceCfg, channel, serviceEventLoop, config.meterRegistry(), protocol,
	nextRequestId(routingCtx, serviceCfg), routingCtx, routingResult, req.exchangeType(),
	req, sslSession, proxiedAddresses, clientAddress, remoteAddress, localAddress,
	req.requestStartTimeNanos(), req.requestStartTimeMicros(), serviceCfg.contextHook());

	ctx.executor().schedule(() ->
	ctx.channel().eventLoop().schedule(() ->

		final short localPort = (short) random.nextInt(Short.MAX_VALUE + 1);
		try (Socket socket = new Socket("127.0.0.1", server.httpPort(), null, localPort)) {

	reuseSock.close();
	// close the socket in case initializing the socket doesn't throw an exception
	reuseSock.close();

	* Returns the default time in milliseconds to wait before closing an HTTP1 connection when a server needs
	* Returns the default time in milliseconds to wait before closing an HTTP/1 connection when a server needs

Close an HTTP/1.1 connection after delay #5616

Close an HTTP/1.1 connection after delay #5616

Conversation

dachshu commented Apr 17, 2024

CLAassistant commented Apr 17, 2024 • edited Loading

github-actions bot commented Apr 17, 2024 • edited Loading

🔍 Build Scan® (commit: 596b223)

jrhee17 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jrhee17 commented Apr 17, 2024

ikhoon Apr 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

trustin left a comment

Choose a reason for hiding this comment

jrhee17 commented Apr 30, 2024

jrhee17 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dachshu May 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dachshu May 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jrhee17 commented Apr 30, 2024

dachshu commented May 6, 2024

jrhee17 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dachshu May 9, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jrhee17 commented May 8, 2024

trustin left a comment

Choose a reason for hiding this comment

ikhoon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

minwoox left a comment

Choose a reason for hiding this comment

dachshu commented May 9, 2024

jrhee17 left a comment

Choose a reason for hiding this comment

minwoox left a comment

Choose a reason for hiding this comment

ikhoon left a comment

Choose a reason for hiding this comment

CLAassistant commented Apr 17, 2024 •

edited

Loading

github-actions bot commented Apr 17, 2024 •

edited

Loading

🔍 Build Scan® (commit: `596b223`)

ikhoon Apr 22, 2024 •

edited

Loading

dachshu May 5, 2024 •

edited

Loading

dachshu May 5, 2024 •

edited

Loading

dachshu May 9, 2024 •

edited

Loading