You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Antonio Pires (Jira)" <ji...@apache.org> on 2020/05/22 13:38:00 UTC
[jira] [Updated] (KAFKA-10032) Response to ApiVersionRequest
returns wrong Produce(0) version
[ https://issues.apache.org/jira/browse/KAFKA-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonio Pires updated KAFKA-10032:
----------------------------------
Description:
The response to {{ApiVersionRequest}} returns incorrect information for the Production {{_ApiKey_}} as it is not considering {{_log.message.format.version_}} config when being overwritten. While the internals, {{_Log.append()_}}, use {{log.message.format.version}} when adding a new record set to the active segment, the version exposed to clients is not the same, which can generate unexpected behaviour.
For example
Using version _>0.11.0_ with {{_log.message.format.version_}} set to a previous version (0.10.2), the broker returns
{{(id: 1 rack: null) -> (}}
{{ Produce(0): 0 to 3 [usable: 3],}}
{{ Fetch(1): 0 to 5 [usable: 5],}}
{{ ...}}
)
and should instead be responding with
{{(id: 1 rack: null) -> (}}
{{ Produce(0): 0 to 2 [usable: 2],}}
{{ Fetch(1): 0 to 5 [usable: 5],}}
{{ ...}}
)
Shouldn't a single source of truth be used to get this version?
In {{_Log.append()_}}, instead of directly getting the version from the config, shouldn't we use the {{_ApiVersions.maxUsableProduceMagic()_}} that, in turn, should take the config in consideration.
was:
The response to {{ApiVersionRequest}} returns incorrect information for the Production {{_ApiKey_}} as it is not considering {{_log.message.format.version_}} config when being overwritten. While the internals, {{_Log.append()_}}, use {{log.message.format.version}} when adding a new record set to the active segment, the version exposed to clients is not the same, which can generate unexpected behaviour.
For example
Using version _>0.11.0_ with {{_log.message.format.version_}} set to a previous version (0.10.2), the broker returns
{{(id: 1 rack: null) -> (}}
{{ Produce(0): 0 to 3 [usable: 3],}}
{{ Fetch(1): 0 to 5 [usable: 5],}}
{{ ...}}
\{{ )}}
and should instead be responding with
{{(id: 1 rack: null) -> (}}
{{ Produce(0): 0 to 2 [usable: 2],}}
{{ Fetch(1): 0 to 5 [usable: 5],}}
{{ ...}}
\{{ )}}
Shouldn't a single source of truth be used to get this version?
In {{_Log.append()_}}, instead of directly getting the version from the config, shouldn't we use the {{_ApiVersions.maxUsableProduceMagic()_}} that, in turn, should take the config in consideration.
> Response to ApiVersionRequest returns wrong Produce(0) version
> --------------------------------------------------------------
>
> Key: KAFKA-10032
> URL: https://issues.apache.org/jira/browse/KAFKA-10032
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.11.0.0, 2.4.0
> Reporter: Antonio Pires
> Priority: Major
>
> The response to {{ApiVersionRequest}} returns incorrect information for the Production {{_ApiKey_}} as it is not considering {{_log.message.format.version_}} config when being overwritten. While the internals, {{_Log.append()_}}, use {{log.message.format.version}} when adding a new record set to the active segment, the version exposed to clients is not the same, which can generate unexpected behaviour.
> For example
> Using version _>0.11.0_ with {{_log.message.format.version_}} set to a previous version (0.10.2), the broker returns
> {{(id: 1 rack: null) -> (}}
> {{ Produce(0): 0 to 3 [usable: 3],}}
> {{ Fetch(1): 0 to 5 [usable: 5],}}
> {{ ...}}
> )
> and should instead be responding with
> {{(id: 1 rack: null) -> (}}
> {{ Produce(0): 0 to 2 [usable: 2],}}
> {{ Fetch(1): 0 to 5 [usable: 5],}}
> {{ ...}}
> )
> Shouldn't a single source of truth be used to get this version?
> In {{_Log.append()_}}, instead of directly getting the version from the config, shouldn't we use the {{_ApiVersions.maxUsableProduceMagic()_}} that, in turn, should take the config in consideration.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)