You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Jason Gustafson (Jira)" <ji...@apache.org> on 2022/07/07 21:29:00 UTC

[jira] [Resolved] (KAFKA-14050) Older clients cannot deserialize ApiVersions response with finalized feature epoch

     [ https://issues.apache.org/jira/browse/KAFKA-14050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Gustafson resolved KAFKA-14050.
-------------------------------------
    Resolution: Not A Problem

I'm going to close this since the incompatible schema change did not affect any released versions. 

> Older clients cannot deserialize ApiVersions response with finalized feature epoch
> ----------------------------------------------------------------------------------
>
>                 Key: KAFKA-14050
>                 URL: https://issues.apache.org/jira/browse/KAFKA-14050
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Jason Gustafson
>            Priority: Blocker
>             Fix For: 3.3.0
>
>
> When testing kraft locally, we encountered this exception from an older client:
> {code:java}
> [ERROR] 2022-07-05 16:45:01,165 [kafka-admin-client-thread | adminclient-1394] org.apache.kafka.common.utils.KafkaThread lambda$configureThread$0 - Uncaught exception in thread 'kafka-admin-client-thread | adminclient-1394':
> org.apache.kafka.common.protocol.types.SchemaException: Error reading field 'api_keys': Error reading array of size 1207959552, only 579 bytes available
>         at org.apache.kafka.common.protocol.types.Schema.read(Schema.java:118)
>         at org.apache.kafka.common.protocol.ApiKeys.parseResponse(ApiKeys.java:378)
>         at org.apache.kafka.common.protocol.ApiKeys$1.parseResponse(ApiKeys.java:187)
>         at org.apache.kafka.clients.NetworkClient$DefaultClientInterceptor.parseResponse(NetworkClient.java:1333)
>         at org.apache.kafka.clients.NetworkClient.parseStructMaybeUpdateThrottleTimeMetrics(NetworkClient.java:752)
>         at org.apache.kafka.clients.NetworkClient.handleCompletedReceives(NetworkClient.java:888)
>         at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:577)
>         at org.apache.kafka.clients.admin.KafkaAdminClient$AdminClientRunnable.processRequests(KafkaAdminClient.java:1329)
>         at org.apache.kafka.clients.admin.KafkaAdminClient$AdminClientRunnable.run(KafkaAdminClient.java:1260)
>         at java.base/java.lang.Thread.run(Thread.java:832) {code}
> The cause appears to be from a change to the type of the `FinalizedFeaturesEpoch` field in the `ApiVersions` response from int32 to int64: [https://github.com/apache/kafka/pull/9001/files#diff-32006e8becae918416debdb9ac76bf8a1ad12b83aaaf5f8819b6ecc00c1fb56bR58.]
> Fortunately, `FinalizedFeaturesEpoch` is a tagged field, so we can fix this by creating a new field. We will have to leave the existing tag in the protocol spec and consider it dead.
> Credit for this find goes to [~dajac] .



--
This message was sent by Atlassian Jira
(v8.20.10#820010)