-
Notifications
You must be signed in to change notification settings - Fork 24
Use exponential backoff for connection retries #65
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
Conversation
a8d5c15 to
eee16d0
Compare
simo5
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
6cd07a4 to
4284384
Compare
|
I was trying to add the connection type, IP address, and port number in the warning message, but apparently such information cannot be fetched from the socket in Python 2. So I am doing to make some additional changes to report the timeout back to the parent function (where the address is available) to report the timeout rather than each connection failure. |
|
We still care about python 2 ? |
|
Yes, for RHEL 7 ELS until 2028. |
4284384 to
b33ebfa
Compare
|
I made some improvements to log the timeout only once per @simo5 I tested this code for Python 2. Could you enabled the CI tests so we can confirm it works with Python 3 too? |
b33ebfa to
c28dc0b
Compare
c054d97 to
75eb76f
Compare
Calls to socket.connect() are non-blocking, hence all subsequent calls to socket.sendall() will fail if the target KDC service is temporarily or indefinitely unreachable. Since the kdcproxy task uses busy-looping, it results in the journal to be flooded with warning logs. This commit introduces a per-socket reactivation delay which increases exponentially as the number of reties is incremented, until timeout is reached (i.e. 100ms, 200ms, 400ms, 800ms, 1.6s, 3.2s, ...). Signed-off-by: Julien Rische <jrische@redhat.com>
Signed-off-by: Julien Rische <jrische@redhat.com>
75eb76f to
c8a69db
Compare
Signed-off-by: Julien Rische <jrische@redhat.com>
Calls to
socket.connect()are non-blocking, hence all subsequent calls tosocket.sendall()will fail if the target KDC service is temporarily or indefinitely unreachable. Since the kdcproxy task uses busy-looping, it results in the journal to be flooded with warning logs.This pull request introduces a per-socket reactivation delay which increases exponentially as the number of reties is incremented, until timeout is reached (i.e. 100ms, 200ms, 400ms, 800ms, 1.6s, 3.2s, ...).
(Also replaces the default
rootlogger with a dedicatedkdcproxyone)