-
Notifications
You must be signed in to change notification settings - Fork 1k
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
No good way to watch leadership #426
Comments
.. and immediately send the current leadership state over the channel. This way it can be used by multiple pieces of code with disrupting another. Sending the value immediately avoids strange race conditions when RaftState gets updated at a slightly different moment. fixes hashicorp#426
Hey there, |
still relevant |
Howdy @Jille, Thank you! |
Hey @s-christoff. I wrote a library that marks the gRPC server as unhealthy if it's not the raft leader. With the current implementation only one place can get the channel and watch it for leader changes. If multiple places would use it, they would steal events from the channel from another and they'd all get an incomplete view. This makes it impossible for a library to use it, because it can't guarantee that the application isn't using it. https://github.com/Jille/raft-grpc-leader-rpc/blob/reliable-leaderch/leaderhealth/leaderhealth.go#L24 checks whether my patch (#427) is in and uses it if available. The alternative is using LeaderObservation, but that has race conditions. |
Hi @Jille, Sorry this has dragged on for so long. Can you elaborate on the race you speak of with LeaderObservation? I'm aware that it can be lossy, but you can specify that you want blocking, such that events will not be discarded. I think the PR you've authored is probably fine, but I'd prefer to avoid having multiple mechanisms for doing this if possible. |
Hey there, This issue has been automatically closed because there hasn't been any activity for a while. If you are still experiencing problems, or still have questions, feel free to open a new one :+1 |
Raft.LeaderCh()
has two problems: It always returns the same channel and it doesn't prepopulate the channel with the current value. Reconstructing this has proven error prone/impossible.RegisterObserver()
was my next attempt, but the LocalAddress isn't exposed (except by the Transport, which not be available to library code).I propose to make Raft.LeaderCh() return a new channel per call, and prepopulate that with the current value. That's a slight behavior change, but I don't expect it to break clients.
The text was updated successfully, but these errors were encountered: