You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 8, 2020. It is now read-only.
For Example, Add Config.Group.Member.UserData []byte and propagate with JoinGroup requests.
The Kafka protocol appears to allow consumer group members to provide 'user data' for partition assignment balancing protocols. This user- data is shared with the balancer, which is selected from one of the members of the consumer group. The balancer then allocates partitions to the group members, possibly based on the user-data.
Even though the current sarama-cluster balancer implementation does not act on user-data it provides value to external tools: E.g. external routing of a web request to a specific partition-owner in consumer group (if the user data contained http host:port info).
External tools could extract this info from the broker without joining the group by something like:
Not sure how one would watch for changes to the partition assignments without being part of the consumer group though. In a reasonably stable environment this may not be too bad so long as there is a fall back for routing (e.g. a redirect).
The text was updated successfully, but these errors were encountered:
For Example, Add Config.Group.Member.UserData []byte and propagate with JoinGroup requests.
The Kafka protocol appears to allow consumer group members to provide 'user data' for partition assignment balancing protocols. This user- data is shared with the balancer, which is selected from one of the members of the consumer group. The balancer then allocates partitions to the group members, possibly based on the user-data.
Even though the current sarama-cluster balancer implementation does not act on user-data it provides value to external tools: E.g. external routing of a web request to a specific partition-owner in consumer group (if the user data contained http host:port info).
External tools could extract this info from the broker without joining the group by something like:
Not sure how one would watch for changes to the partition assignments without being part of the consumer group though. In a reasonably stable environment this may not be too bad so long as there is a fall back for routing (e.g. a redirect).
The text was updated successfully, but these errors were encountered: