fix: gracefully terminate connections when closing http server - #5786
Merged
Conversation
Contributor
Performance Report鉁旓笍 no performance regression detected Full benchmark results
|
nflaig
force-pushed
the
nflaig/server-graceful-shutdown
branch
from
July 22, 2023 12:52
d2bf447 to
7a1e435
Compare
nflaig
commented
Jul 22, 2023
| // Don't log ErrorAborted errors, they happen on node shutdown and are not useful | ||
| // Don't log NodeISSyncing errors, they happen very frequently while syncing and the validator polls duties | ||
| // Don't log eventstream aborted errors if server instance is being closed on node shutdown | ||
| if (err instanceof ErrorAborted || err instanceof NodeIsSyncing || this.status === Status.Closed) return; |
Member
Author
There was a problem hiding this comment.
I added this in #5330 to avoid noisy errors on shutdown, however eventstream aborts are now properly handled and no more error are logged on shutdown.
Since we attempt to gracefully close connections now, it is highly unlikely to log any errors on shutdown since we should only get ErrorAborted which is already checked and not logged. Any error that is not caught here is unexpected and should be logged.
nflaig
force-pushed
the
nflaig/server-graceful-shutdown
branch
from
July 22, 2023 15:07
3db6051 to
49583c1
Compare
nflaig
marked this pull request as draft
July 22, 2023 15:21
nflaig
force-pushed
the
nflaig/server-graceful-shutdown
branch
from
July 22, 2023 16:23
49583c1 to
485a996
Compare
nflaig
force-pushed
the
nflaig/server-graceful-shutdown
branch
from
July 23, 2023 11:42
1cd9111 to
ff70972
Compare
nflaig
marked this pull request as ready for review
July 23, 2023 11:44
matthewkeil
reviewed
Jul 24, 2023
matthewkeil
left a comment
Member
There was a problem hiding this comment.
Post merge review. This is great!!!
Member
|
馃帀 This PR is included in v1.10.0 馃帀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
While looking into #5783 I noticed that our REST API server is not really "friendly" to clients, it abruptly terminates connections.
We should give the beacon node some time to complete pending requests and only forcefully close connections if timeout is reached. This improves client experience and prevents potential data corruption if request is writing data.
Description
Gracefully close HTTP server by waiting for all connections to drain until timeout
Connection: closeheaderFurther considerations
It might make sense to close server immediately to stop accepting new connections.
Right now, what happens is that while terminating, new connections are just force closed by destroying the socket.
lodestar/packages/beacon-node/src/api/rest/activeSockets.ts
Lines 28 to 29 in 485a996
This causes
curl: (56) Recv failure: Connection reset by peererror on the client.If the server is closed immediately it will cause
curl: (7) Failed to connect to localhost port 9596 after 0 ms: Connection refusedon the client as server stops listening for connections.The difference is likely insignificant in our case as the shutdown period is really short and the beacon node generally does not receive that many requests per second and in both cases the client will receive an error.
This has been discussed in http-terminator repository already gajus/http-terminator#22, but since our current and now updated implementation follows that of http-terminator closely, I kept the implementation to close server after terminating sockets.