Add client.Isr to determine in-sync replicas #872
Conversation
There was a problem hiding this comment.
If I'm reading the linked issue correctly, that issue has been resolved since Kafka 0.9
Hmm, that's also how I'm reading the linked issue, but I'm a bit suspicious still because I thought I had been following this issue more closely and that there were further complications. Perhaps I'm just being paranoid though, I can't find any of the problems I seem to remember.
client.go
Outdated
| @@ -38,6 +38,9 @@ type Client interface { | |||
| // Replicas returns the set of all replica IDs for the given partition. | |||
| Replicas(topic string, partitionID int32) ([]int32, error) | |||
|
|
|||
| // Isr returns the set of in-sync replica IDs for the given partition. | |||
| Isr(topic string, partitionID int32) ([]int32, error) | |||
There was a problem hiding this comment.
For a public API I would prefer this be a bit more explicit: ReplicasInSync or InSyncReplicas or something like that. It would also be nice if the docs explained (or linked to an explanation) of what it means to be in sync.
|
@eapache I've renamed it to Improved documentation suggestions welcome. =) |
|
This is great, thanks! |
To get access to the `client.InSyncReplicas` function, added here: IBM/sarama#872
This restores the commit from @funkygao in PR #566, with an additional commit to expose the function on the
Clientinterface and add some basic tests around its functionality.The PR was previously closed with the suggestion that Zookeeper should be used directly, because, at the time, it was possible to receive stale information from Kafka. If I'm reading the linked issue correctly, that issue has been resolved since Kafka 0.9, so I'd like this patch to be reconsidered now.
I personally want this so that I can then add ISR support to the excellent kt, which is the workhorse of a fair amount of the Kafka automation tooling I use.