chia7712 commented on code in PR #19508:
URL: https://github.com/apache/kafka/pull/19508#discussion_r2080185161
##########
clients/src/main/java/org/apache/kafka/common/requests/ListGroupsRequest.java:
##########
@@ -50,8 +53,19 @@ public ListGroupsRequest build(short version) {
"v" + version + ", but we need v4 or newer to request
groups by states.");
}
if (!data.typesFilter().isEmpty() && version < 5) {
- throw new UnsupportedVersionException("The broker only
supports ListGroups " +
- "v" + version + ", but we need v5 or newer to request
groups by type.");
+ // Types filter is supported by brokers with version 4.0.0 or
later. Older brokers only support
+ // classic groups, so listing consumer groups on an older
broker does not need to use a types filter.
+ // If the types filter is only for consumer and classic, or
just classic groups, it can be safely omitted.
+ // This allows a modern admin client to list consumer groups
on older brokers in a straightforward way.
+ HashSet<String> typesCopy = new HashSet<>(data.typesFilter());
+ boolean containedClassic =
typesCopy.remove(GroupType.CLASSIC.toString());
+ boolean containedConsumer =
typesCopy.remove(GroupType.CONSUMER.toString());
+ if (!typesCopy.isEmpty() || (!containedClassic &&
containedConsumer)) {
Review Comment:
> Modern consumer groups would be reported as classic groups, because the
RPC response was not able to distinguish.
My point was the request
`ListGroupsOptions.withTypes(List.of(GroupType.CLASSIC))` will get both classic
and consumer groups from 3.7 broker when KIP-848 EA enabled. That is a bit
weird to me, as users are expected to receive only the classic groups. Hence,
maybe we should throw `UnsupportedVersionException` for that case?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
