-
Notifications
You must be signed in to change notification settings - Fork 9
zmq: prevent unnecessary timeouts and return EOF on connection termination #3
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
zmq: prevent unnecessary timeouts and return EOF on connection termination #3
Conversation
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 ✅
We'll only set read deadlines on the underlying connection when reading messages of multiple frames after the first frame has been read. This is done to ensure we receive all of the frames of a message within a reasonable time frame. When reading the first frame, we want to avoid setting them as we don't know when a new message will be available for us to read, causing us to block until its delivery.
If the connection is explicitly terminated, we should not try to re-establish the connection since doing so signals that the connection is no longer needed.
@@ -0,0 +1,3 @@ | |||
module github.com/lightninglabs/gozmq | |||
|
|||
go 1.12 |
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.
why is this defined here?
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.
if err != nil { | ||
// Prevent CPU overuse by refused reconnection attempts. | ||
time.Sleep(c.timeout) | ||
} else { | ||
c.Close() | ||
*c = *newConn | ||
c.conn.Close() |
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.
No error to return here?
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.
We still want to return errTimeout
. Closing this connection seems like more of a best effort thing.
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 🗿
In this PR, we address an issue where it's possible for us to time out connections when there aren't any messages to read. To address this, we'll only set read deadlines on the underlying connection when reading messages of multiple frames after the first frame has been read. This is done to ensure we receive all of the frames of a message within a reasonable time frame. When reading the first frame, we want to avoid setting them as we don't know when a new message will be available for us to read, causing us to block until its delivery. As a result, a separate issue was discovered where connections would attempt to be re-established even when the user of the connection had explicitly terminated it.