[
https://issues.apache.org/jira/browse/KAFKA-19116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17942211#comment-17942211
]
Sushant Mahajan edited comment on KAFKA-19116 at 4/9/25 2:36 PM:
-----------------------------------------------------------------
The issue occurs due to SharePartitionManager re-using the same SharePartition
instance even after the the corresponding share partition
(group:topic:partition) is deleted using deleteOffsets or the delete groups
commands.
Internally, the SharePartitionManager maintains a cache of SharePartition keyed
on share partition key. After deletion of a share partition, the cache does not
update itself and continues using the older SharePartition instance, eventually
serving future shareFetch requests with it. Since the instance is already
initialized, it does not call persister.readState or query the replicaManager
for the offset information and results in the anomaly observed when servicing
post delete requests.
was (Author: JIRAUSER300816):
The issue occurs due to SharePartitionManager re-using the same SharePartition
instance even after the the corresponding share partition
(group:topic:partition) is deleted using deleteOffsets or the delete groups
commands.
Internally, the SharePartitionManager maintains a cache of SharePartition keyed
on share partition. After deletion of share partition, the cache does not
update itself and continues using the older instance. Eventually serving future
shareFetch requests using it. Since the instance is already initialized the
instance does not call persister.readState or query the replicaManager for the
offset information and results in the anomaly.
> Deletion of share group offsets does not reset the position as expected
> -----------------------------------------------------------------------
>
> Key: KAFKA-19116
> URL: https://issues.apache.org/jira/browse/KAFKA-19116
> Project: Kafka
> Issue Type: Sub-task
> Affects Versions: 4.1.0
> Reporter: Andrew Schofield
> Assignee: Apoorv Mittal
> Priority: Major
> Fix For: 4.1.0
>
>
> Here are the steps to reproduce.
> # Create a topic T1 with a single partition.
> $ kafka-topics.sh --create --topic T1
> # Start the console producer and produce three records "one", "two", "three".
> Leave it running.
> # Start the console share consumer, and leave it running.
> $ kafka-console-share-consumer.sh --topic T1
> No records are consumed.
> # Send another record "four" using the console producer.
> # Record "four" is consumed by the console share consumer.
> # Describe the share group "console-share-consumer".
> $ kafka-share-groups.sh --describe --group console-share-consumer
> There should be an offset for topic T1, partition 0.
> # Stop the console share consumer so that the group is empty.
> # Delete the offset for topic T1, partition 0.
> $ kafka-share-groups.sh --delete-offsets --group console-share-consumer
> --topic T1
> # Describe the share group again to confirm the offset is shown as "-".
> # Send another record "five" using the console producer.
> # Restart the console share consumer. In theory, no records will be consumed
> because the fetch position should be re-initialized as the latest offset.
> Actually, record "five" is consumed.
> # Send another record "six" using the console producer.
> # The console share consumer should consume "six" and should not have
> consumed "five".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
