[
https://issues.apache.org/jira/browse/KAFKA-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14971706#comment-14971706
]
Jason Gustafson commented on KAFKA-2687:
----------------------------------------
[~gwenshap] Good point. Suppose we made the following change to the request:
{code}
GroupMetadataRequest => Groups IncludeMetadata
Groups => [String]
IncludeMetadata => Boolean
{code}
Then we modified the response to include information for each requested group.
Then when the group list is empty in the request (or perhaps with a separate
flag), we could have the coordinator return the list of groups it knows about.
The includeMetadata then is especially helpful since it would keep the response
reasonably small. To get the full list of groups in the cluster, however, you'd
still have to query all the brokers separately. That's a basic limitation
without centralized storage of group information. What do you think?
> Allow GroupMetadataRequest to return member metadata when received by group
> coordinator
> ---------------------------------------------------------------------------------------
>
> Key: KAFKA-2687
> URL: https://issues.apache.org/jira/browse/KAFKA-2687
> Project: Kafka
> Issue Type: Improvement
> Reporter: Jason Gustafson
> Assignee: Jason Gustafson
>
> Since the new consumer currently has no persistence in Zookeeper (pending
> outcome of KAFKA-2017), there is no way for administrators to investigate
> group status including getting the list of members in the group and their
> partition assignments. We therefore propose to modify GroupMetadataRequest
> (previously known as ConsumerMetadataRequest) to return group metadata when
> received by the respective group's coordinator. When received by another
> broker, the request will be handled as before: by only returning coordinator
> host and port information.
> {code}
> GroupMetadataRequest => GroupId IncludeMetadata
> GroupId => String
> IncludeMetadata => Boolean
> GroupMetadataResponse => ErrorCode Coordinator GroupMetadata
> ErrorCode => int16
> Coordinator => Id Host Port
> Id => int32
> Host => string
> Port => int32
> GroupMetadata => State ProtocolType Generation Protocol Leader Members
> State => String
> ProtocolType => String
> Generation => int32
> Protocol => String
> Leader => String
> Members => [Member MemberMetadata MemberAssignment]
> Member => MemberIp ClientId
> MemberIp => String
> ClientId => String
> MemberMetadata => Bytes
> MemberAssignment => Bytes
> {code}
> The request schema includes a flag to indicate whether metadata is needed,
> which saves clients from having to read all group metadata when they are just
> trying to find the coordinator. This is important to reduce group overhead
> for use cases which involve a large number of topic subscriptions (e.g.
> mirror maker).
> Tools will use the protocol type to determine how to parse metadata. For
> example, when the protocolType is "consumer", the tool can use
> ConsumerProtocol to parse the member metadata as topic subscriptions and
> partition assignments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
