Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an AcceptBackoffHandler to the async server bootstraps #2782

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

FranzBusch
Copy link
Member

Motivation

When encountering a file descriptor limit we are currently closing the server socket when using the async bootstraps since the error caught is delivered via the inbound sequence of the server socket async sequence.

Modification

This PR adds the AcceptBackoffHandler in the async bootstrap case to the pipeline to avoid us closing the server socket channel when we hit the file descriptor limit.

Result

We are now gracefully handling file descriptor limits.

# Motivation

When encountering a file descriptor limit we are currently closing the server socket when using the async bootstraps since the error caught is delivered via the `inbound` sequence of the server socket async sequence.

# Modification

This PR adds the `AcceptBackoffHandler` in the async bootstrap case to the pipeline to avoid us closing the server socket channel when we hit the file descriptor limit.

# Result

We are now gracefully handling file descriptor limits.
@FranzBusch
Copy link
Member Author

@Lukasa @glbrntt Would love to get your feedback on this approach before I add tests to it.

@glbrntt
Copy link
Contributor

glbrntt commented Jul 12, 2024

This seems reasonable for running out of descriptors, what other IOErrors do we expect, and is it reasonable to backoff for those rather than closing?

@@ -68,8 68,9 @@ public final class AcceptBackoffHandler: ChannelDuplexHandler, RemovableChannelH
scheduleRead(at: self.nextReadDeadlineNS!, context: context)
}
}
} else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm inclined to make this behaviour configurable. Users may be relying on the existing reporting, which makes sense as a default behaviour, but for the use-case we have it may well be sensible to suppress the error when it is "handled".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants