DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
| Code Block |
|---|
package org.apache.kafka.client.admin;
import org.apache.kafka.common.ShareGroupState;
/**
* A listing of a group in the cluster.
* <p>
* The API of this class is evolving, see {@link Admin} for details.
*/
@InterfaceStability.Evolving
public class GroupListing {
public GroupListing(String groupId, String protocol);
public GroupListing(String groupId, GroupType type, String protocol);
public GroupListing(String groupId, Optional<GroupType> type, String protocol);
/**
* The id of the group.
*/
public String groupId();
/**
* The group type.
*/
public Optional<GroupType> type();
/**
* The group protocol type.
*/
public String protocol();
} |
...
| Option | Description |
|---|---|
--bootstrap-server <String: server to connect to> | REQUIRED: The server(s) to connect to. |
--command-config <String: command config property file> | Property file containing configs to be passed to Admin Client. |
--consumer | Filters the groups based on group type and protocol in order to show consumer groupsgroups to show all kinds of consumer groups, including classic and simple consumer groups. This matches group type 'consumer', and group type 'classic' where the protocol type is 'consumer' or empty. |
--describe | Describe the details of the groups. |
--group-type <String: type> | Filters the groups based on group type. Valid types are: 'classic', 'consumer' and 'share'. |
--help | Print usage information. |
--list | List all groups. |
--protocol <String: protocol> | Filters the groups based on protocol type. |
--version | Display Kafka version. |
...
When writing this KIP, it seemed that perhaps the ListGroups RPC would need to be enhanced to create the AdminClient.listGroups() method. This turned out not to be necessary.
...
It would be possible to preserve the current behavior of AdminClient.describeConsumerGroups(Collection<String>) when used with a group which is not a consumer group and introduce an option to ask it to validate the group type rather than converting any indescribable group into a dead consumer group. This seems like an unnecessary complication with little benefit.
The error code INCONSISTENT_GROUP_PROTOCOL already exists and is used with the classic consumer group protocol if a member attempts to join the group with an inconsistent sub-protocol. You would see this if you started up a distributed Kafka connect worker with the default configuration and then tried to use kafka-console-consumer.sh with the group ID connect-cluster . Rather than overloading this error code, this KIP introduces the new error code INCONSISTENT_GROUP_TYPE which is similar but applies to the group type (consumer, share, classic) rather than the sub-protocol within the classic consumer group protocol.