[
https://issues.apache.org/jira/browse/KAFKA-17796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sushant Mahajan updated KAFKA-17796:
------------------------------------
Description:
It is possible that a ReadShareStateRequest includes a higher leader epoch for
a specific share partition than previously seen by the share coordinator.
However, currently we are only persisting the leaderEpoch in the write state
calls. We need to implement the logic to write a record to the
__share_group_state internal topic when a higher leaderEpoch is seen in read
state calls.
One way to accomplish this is to make a an additional write state call with
every read call if the read state request contains a higher leaderEpoch for a
share partition. We are already maintaining highest leaderEpoch in share
coordinator soft state of the topic.
This will increase load on the share coordinator due to the occasional extra
write but the read calls are relatively rare (compared to write). Read calls
are made when a new share partition is initialized for the first time.
Classes to be affected:
{{ShareCoordinatorService.java, }}{{ShareCoordinatorShard.java}}
was:
It is possible that a ReadShareStateRequest includes a higher leader epoch for
a specific share partition than previously seen by the share coordinator.
However, currently we are only persisting the leaderEpoch in the write state
calls. We need to implement the logic to write a record to the
__share_group_state internal topic when a higher leaderEpoch is seen in read
state calls.
One way to accomplish this is to make a an additional write state call with
every read call if the read state request contains a higher leaderEpoch for a
share partition. We are already maintaining highest leaderEpoch in share
coordinator soft state of the topic.
This will increase load on the share coordinator due to the occasional extra
write but the read calls are relatively rare (compared to write). Read calls
are made when a new share partition is initialized for the first time.
Classes to be affected:
{{{}ShareCoordinatorService.java{}}}{{{}ShareCoordinatorShard.java{}}}
> Persist higher leaderEpoch in read state calls to the share coordinator.
> ------------------------------------------------------------------------
>
> Key: KAFKA-17796
> URL: https://issues.apache.org/jira/browse/KAFKA-17796
> Project: Kafka
> Issue Type: Sub-task
> Reporter: Sushant Mahajan
> Assignee: Sushant Mahajan
> Priority: Major
>
> It is possible that a ReadShareStateRequest includes a higher leader epoch
> for a specific share partition than previously seen by the share coordinator.
> However, currently we are only persisting the leaderEpoch in the write state
> calls. We need to implement the logic to write a record to the
> __share_group_state internal topic when a higher leaderEpoch is seen in read
> state calls.
> One way to accomplish this is to make a an additional write state call with
> every read call if the read state request contains a higher leaderEpoch for a
> share partition. We are already maintaining highest leaderEpoch in share
> coordinator soft state of the topic.
> This will increase load on the share coordinator due to the occasional extra
> write but the read calls are relatively rare (compared to write). Read calls
> are made when a new share partition is initialized for the first time.
>
> Classes to be affected:
> {{ShareCoordinatorService.java, }}{{ShareCoordinatorShard.java}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
