[
https://issues.apache.org/jira/browse/KAFKA-7313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dong Lin updated KAFKA-7313:
----------------------------
Description:
This patch fixes two issues:
1) Currently if a broker received StopReplicaRequest with delete=true for the
same offline replica, the first StopRelicaRequest will show
KafkaStorageException and the second StopRelicaRequest will show
ReplicaNotAvailableException. This is because the first StopRelicaRequest will
remove the mapping (tp -> ReplicaManager.OfflinePartition) from
ReplicaManager.allPartitions before returning KafkaStorageException, thus the
second StopRelicaRequest will not find this partition as offline.
This result appears to be inconsistent. And since the replica is already
offline and broker will not be able to delete file for this replica, the
StopReplicaRequest should fail without making any change and broker should
still remember that this replica is offline.
2) Currently if broker receives StopReplicaRequest with delete=true, the broker
will attempt to remove future replica for the partition, which will cause
KafkaStorageException in the StopReplicaResponse if this replica does not have
future replica. It is problematic to always return KafkaStorageException in the
response if future replica does not exist.
was:
This patch fixes two issues:
1) Currently if a broker received StopReplicaRequest with delete=true for the
same offline replica, the first StopRelicaRequest will show
KafkaStorageException and the second StopRelicaRequest will show
ReplicaNotAvailableException. This is because the first StopRelicaRequest will
remove the mapping (tp -> ReplicaManager.OfflinePartition) from
ReplicaManager.allPartitions before returning KafkaStorageException, thus the
second StopRelicaRequest will not find this partition as offline.
This result appears to be inconsistent. And since the replica is already
offline and broker will not be able to delete file for this replica, the
StopReplicaRequest should fail without making any change and broker should
still remember that this replica is offline.
2) Currently if broker receives StopReplicaRequest with delete=true, the broker
will attempt to remove future replica for the partition, which will cause
KafkaStorageException in the StopReplicaResponse if this replica does not have
future replica. It is problematic to always return KafkaStorageException in the
response if future replica does not exist.
> KAFKA-7313; StopReplicaRequest should attempt to remove future replica for
> the partition only if future replica exists
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-7313
> URL: https://issues.apache.org/jira/browse/KAFKA-7313
> Project: Kafka
> Issue Type: Improvement
> Reporter: Dong Lin
> Assignee: Dong Lin
> Priority: Major
>
> This patch fixes two issues:
> 1) Currently if a broker received StopReplicaRequest with delete=true for the
> same offline replica, the first StopRelicaRequest will show
> KafkaStorageException and the second StopRelicaRequest will show
> ReplicaNotAvailableException. This is because the first StopRelicaRequest
> will remove the mapping (tp -> ReplicaManager.OfflinePartition) from
> ReplicaManager.allPartitions before returning KafkaStorageException, thus the
> second StopRelicaRequest will not find this partition as offline.
> This result appears to be inconsistent. And since the replica is already
> offline and broker will not be able to delete file for this replica, the
> StopReplicaRequest should fail without making any change and broker should
> still remember that this replica is offline.
> 2) Currently if broker receives StopReplicaRequest with delete=true, the
> broker will attempt to remove future replica for the partition, which will
> cause KafkaStorageException in the StopReplicaResponse if this replica does
> not have future replica. It is problematic to always return
> KafkaStorageException in the response if future replica does not exist.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
