-
Notifications
You must be signed in to change notification settings - Fork 14.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KAFKA-18659: librdkafka compressed produce fails unless api versions returns produce v0 #18727
base: trunk
Are you sure you want to change the base?
Changes from all commits
a252374
243771e
8a5d335
6420650
b38a7ef
593db8b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -149,6 +149,15 @@ public enum ApiKeys { | |
private static final Map<Integer, ApiKeys> ID_TO_TYPE = Arrays.stream(ApiKeys.values()) | ||
.collect(Collectors.toMap(key -> (int) key.id, Function.identity())); | ||
|
||
// Versions 0-2 were removed in Apache Kafka 4.0, version 3 is the new baseline. Due to a bug in librdkafka, | ||
// these versions have to be included in the api versions response (see KAFKA-18659). In order to achieve that, | ||
// we keep such versions in the protocol definition files, but override `oldestVersion` to return the correct value. | ||
// We also adjust `toApiVersion` to return `0` for produce in the broker listener. | ||
// An alternative approach would be to remove versions `0-2` from the protocol definition files and only override the | ||
// behavior in this file - the main downside is that it would no longer be possible to send requests with produce v0-v2, | ||
// which would make testing significantly harder (it would probably have to be a ducktape test). | ||
public static final short PRODUCE_OLDEST_VERSION = 3; | ||
|
||
/** the permanent and immutable id of an API - this can't change ever */ | ||
public final short id; | ||
|
||
|
@@ -227,6 +236,9 @@ public short latestVersion(boolean enableUnstableLastVersion) { | |
} | ||
|
||
public short oldestVersion() { | ||
// See #PRODUCE_OLDEST_VERSION for details of why we do this | ||
if (this == PRODUCE) | ||
return PRODUCE_OLDEST_VERSION; | ||
return messageType.lowestSupportedVersion(); | ||
} | ||
|
||
|
@@ -264,8 +276,11 @@ public boolean hasValidVersion() { | |
return oldestVersion() <= latestVersion(); | ||
} | ||
|
||
public Optional<ApiVersionsResponseData.ApiVersion> toApiVersion(boolean enableUnstableLastVersion) { | ||
short oldestVersion = oldestVersion(); | ||
public Optional<ApiVersionsResponseData.ApiVersion> toApiVersion(boolean enableUnstableLastVersion, | ||
Optional<ApiMessageType.ListenerType> listenerType) { | ||
// see `PRODUCE_OLDEST_VERSION` for details on why we do this | ||
short oldestVersion = (this == PRODUCE && listenerType.map(l -> l == ApiMessageType.ListenerType.BROKER).orElse(false)) ? | ||
messageType.lowestSupportedVersion() : oldestVersion(); | ||
short latestVersion = latestVersion(enableUnstableLastVersion); | ||
|
||
// API is entirely disabled if latestStableVersion is smaller than oldestVersion. | ||
|
@@ -299,7 +314,7 @@ static String toHtml() { | |
b.append("<th>Key</th>\n"); | ||
b.append("</tr>"); | ||
clientApis().stream() | ||
.filter(apiKey -> apiKey.toApiVersion(false).isPresent()) | ||
.filter(apiKey -> apiKey.toApiVersion(false, Optional.empty()).isPresent()) | ||
.forEach(apiKey -> { | ||
b.append("<tr>\n"); | ||
b.append("<td>"); | ||
|
@@ -341,10 +356,7 @@ public static EnumSet<ApiKeys> controllerApis() { | |
} | ||
|
||
public static EnumSet<ApiKeys> clientApis() { | ||
List<ApiKeys> apis = Arrays.stream(ApiKeys.values()) | ||
.filter(apiKey -> apiKey.inScope(ApiMessageType.ListenerType.BROKER)) | ||
.collect(Collectors.toList()); | ||
return EnumSet.copyOf(apis); | ||
return brokerApis(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This simplification is unrelated to the main change in this PR - just something I noticed could be cleaned up. |
||
} | ||
|
||
public static EnumSet<ApiKeys> apisForListener(ApiMessageType.ListenerType listener) { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -208,26 +208,26 @@ public static String toHtml() { | |
// Responses | ||
b.append("<b>Responses:</b><br>\n"); | ||
Schema[] responses = key.messageType.responseSchemas(); | ||
for (int i = 0; i < responses.length; i++) { | ||
Schema schema = responses[i]; | ||
for (int version = key.oldestVersion(); version < key.latestVersion(); version++) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Use the same approach we use for requests for consistency - it should result in the same behavior, but fail more clearly if there is some inconsistency. |
||
Schema schema = responses[version]; | ||
if (schema == null) | ||
throw new IllegalStateException("Unexpected null schema for " + key + " with version " + version); | ||
// Schema | ||
if (schema != null) { | ||
b.append("<div>"); | ||
// Version header | ||
b.append("<pre>"); | ||
b.append(key.name); | ||
b.append(" Response (Version: "); | ||
b.append(i); | ||
b.append(") => "); | ||
schemaToBnfHtml(responses[i], b, 2); | ||
b.append("</pre>"); | ||
|
||
b.append("<p><b>Response header version:</b> "); | ||
b.append(key.responseHeaderVersion((short) i)); | ||
b.append("</p>\n"); | ||
|
||
schemaToFieldTableHtml(responses[i], b); | ||
} | ||
b.append("<div>"); | ||
// Version header | ||
b.append("<pre>"); | ||
b.append(key.name); | ||
b.append(" Response (Version: "); | ||
b.append(version); | ||
b.append(") => "); | ||
schemaToBnfHtml(responses[version], b, 2); | ||
b.append("</pre>"); | ||
|
||
b.append("<p><b>Response header version:</b> "); | ||
b.append(key.responseHeaderVersion((short) version)); | ||
b.append("</p>\n"); | ||
|
||
schemaToFieldTableHtml(responses[version], b); | ||
b.append("</div>\n"); | ||
} | ||
} | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -18,7 +18,9 @@ | |
"type": "request", | ||
"listeners": ["broker"], | ||
"name": "ProduceRequest", | ||
// Versions 0-2 were removed in Apache Kafka 4.0, Version 3 is the new baseline. | ||
// Versions 0-2 were removed in Apache Kafka 4.0, version 3 is the new baseline. Due to a bug in librdkafka, | ||
// these versions have to be included in the api versions response (see KAFKA-18659) and are included in `validVersion`. | ||
// See `ApiKeys.PRODUCE_OLDEST_VERSION` for more details. | ||
// | ||
// Version 1 and 2 are the same as version 0. | ||
// | ||
|
@@ -44,7 +46,7 @@ | |
// transaction V2 (KIP_890 part 2) is enabled, the produce request will also include the function for a | ||
// AddPartitionsToTxn call. If V2 is disabled, the client can't use produce request version higher than 11 within | ||
// a transaction. | ||
"validVersions": "3-12", | ||
"validVersions": "0-12", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Instead of bringing back v0 and v1, could we just customize the minVersion of the produce ApiKey in ApiResponse? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am indeed exploring something involving customizing ApiKey/ApiResponse (that's what I meant when I said that there may be a cleaner way to make the change). But I was planning to leave 0-12 here and reduce the range within the code. The main advantage is that you get appropriate errors if you try to produce with v0-2. The option you suggest would result in a disconnection. I think a disconnection is too confusing if the given version is included as part of the api versions response. Thoughts? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree that it's nearly impossible to make the experience for these super ancient clients good. I was more thinking about client developers implementing the kafka protocol. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, we could make an effort to send a more meaningful error code for produce v0-v2. But since they are not really supported on the broker, just doing a disconnect like any other unsupported version also seems reasonable. |
||
"flexibleVersions": "9+", | ||
"fields": [ | ||
{ "name": "TransactionalId", "type": "string", "versions": "3+", "nullableVersions": "3+", "default": "null", "entityType": "transactionalId", | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excuse me, but why change the (produce) schema version after we decided to change the API response? I assumed all we needed to do was return the API response including v0-v2 produce requests to fix the librdkafka issue. Then, the schema could remain at v3-v12, so the v0-v2 requests would still be rejected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will explain the changes in more detail after I confirm that the test results are passing.