-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
NRG: Wait for goroutines to shutdown when recreating group #5832
base: main
Are you sure you want to change the base?
Conversation
9613916
to
01a15f8
Compare
01a15f8
to
0ec0f43
Compare
61b9a2e
to
3cc6288
Compare
This should fix some logical races where multiple sets of goroutines can fight over the same store directory, i.e. when shutting down and recreating a group rapidly. Signed-off-by: Neil Twigg <[email protected]>
3cc6288
to
751dec0
Compare
Have rebased, this one is ready for review. |
if node := s.lookupRaftNode(rg.Name); node != nil { | ||
if node.State() == Closed { |
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.
Feels like there may be a better approach here.
Also I think we need to check that the peer lists are the same if we are going to re-use.
// Wait for goroutines to shut down before trying to clean up | ||
// the log below, otherwise we might end up deleting the store | ||
// from underneath running goroutines. | ||
n.Unlock() |
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 have these patterns for sure elsewhere but I try hard to avoid them if at all possible.
This should fix some logical races where multiple sets of goroutines can fight over the same store directory, i.e. when shutting down and recreating a group rapidly.
Signed-off-by: Neil Twigg [email protected]