[
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)
