-
Notifications
You must be signed in to change notification settings - Fork 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
Implement zero downtime reconnects for workers draining #79
base: main
Are you sure you want to change the base?
Implement zero downtime reconnects for workers draining #79
Conversation
…nects-for-workers-draining
When using the same goroutine to handle channel selects and sending to an unbuffered channel, there's no way for the channel receive to work. This is fixed by not using a channel for control flow from error group to error group. This way, the same goroutine can be used.
config := sdk.RegisterRequest{ | ||
URL: fmt.Sprintf("%s://%s%s", scheme, host, pathAndParams), | ||
V: "1", | ||
DeployType: deployType, | ||
DeployType: sdk.DeployTypePing, |
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 just ping now and not use the connect type?
notifyConnectedChan := make(chan struct{}) | ||
|
||
// Channel to imperatively initiate a connection | ||
initiateConnectionChan := make(chan struct{}) |
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 not make these channels part of the connectHandler
instead of passing them around?
looks like it can be all done with a NewConnectHandler
function.
No description provided.