-
Notifications
You must be signed in to change notification settings - Fork 344
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
Simplify connection close logic #559
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.
We could also do something like
var err error
var host *url.URL
var rpcResult *RPCResult
backoff := Backoff{100 * time.Millisecond}
var timeoutCh <-chan time.Time
for {
host, err = c.serviceNameResolver.ResolveHost()
if err != nil {
c.log.WithError(err).Errorf("rpc client failed to resolve host")
return nil, err
}
rpcResult, err = c.Request(host, host, requestID, cmdType, message)
// success we got a response
if err == nil {
break
}
retryTime := backoff.Next()
sleepCh := time.After(retryTime)
if timeoutCh == nil {
timeoutCh = time.After(c.requestTimeout)
}
c.log.Debugf("Retrying request in {%v} with timeout in {%v}", retryTime, c.requestTimeout)
select {
case <- sleepCh:
break
case <- timeoutCh:
return rpcResult, err
}
}
And we may want to think about adding a context (in another PR) if can we need to cancel this when shutting down producer or consumer on reconnect?
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.
Great Jobs
Hello @cckellogg , In connection start, we first judge whether the TCP connection is established successfully.
If the connection is established successfully but the handshake fails, we will branch else, but here we just change the connection status to
But in the Close function, when the connection is in the
So here in the reconnect process, it will cause multiple TCP connections to be created locally, resulting in TCP connection resources leakage. Here for the |
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.
Hello @cckellogg Here I have confusion. When we change the connection status to connectionClosed
, when did we actually close the TCP connection?
For example, in https://github.com/apache/pulsar-client-go/blob/master/pulsar/internal/connection.go#L222-L224, When the handshake fails, we have created a new connection, but we directly changed the status to connectionClosed but did not actually close the connection |
Changed the code to call Close() instead of setting the state to connectionClosed. This should cleanup and close the connection. |
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.
Thanks @cckellogg Great changes LGTM +1
Motivation
Simplify the connection close logic into one function. I thinks this makes the code easier to reason about and maintain.