[
https://issues.apache.org/jira/browse/KAFKA-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14971660#comment-14971660
]
Jason Gustafson commented on KAFKA-2687:
----------------------------------------
[~junrao] [~guozhang] I can write up a KIP for this if you think it's
necessary. I think we need this for the 0.9 release if we decide to delay
implementation of group persistence in KAFKA-2017. The consequence of not
having it is that users will have to inspect consumer/broker logs to find group
metadata.
> 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)
