[
https://issues.apache.org/jira/browse/KAFKA-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751766#comment-16751766
]
Jun Rao commented on KAFKA-7837:
--------------------------------
[~dhruvilshah], the following is the description of the iterator of
ConcurrentHashmap.
"The view's {{iterator}} is a "weakly consistent" iterator that will never
throw
[{{ConcurrentModificationException}}|https://docs.oracle.com/javase/7/docs/api/java/util/ConcurrentModificationException.html],
and guarantees to traverse elements as they existed upon construction of the
iterator, and may (but is not guaranteed to) reflect any modifications
subsequent to construction."
So, it only traverses elements existed at the construction of the iterator. The
following update changes an existing element. So, I am not sure if it's
guaranteed to be reflected during the iteration.
{code:java}
allPartitions.put(topicPartition, ReplicaManager.OfflinePartition){code}
> maybeShrinkIsr may not reflect OfflinePartitions immediately
> ------------------------------------------------------------
>
> Key: KAFKA-7837
> URL: https://issues.apache.org/jira/browse/KAFKA-7837
> Project: Kafka
> Issue Type: Improvement
> Reporter: Jun Rao
> Assignee: Dhruvil Shah
> Priority: Major
>
> When a partition is marked offline due to a failed disk, the leader is
> supposed to not shrink its ISR any more. In ReplicaManager.maybeShrinkIsr(),
> we iterate through all non-offline partitions to shrink the ISR. If an ISR
> needs to shrink, we need to write the new ISR to ZK, which can take a bit of
> time. In this window, some partitions could now be marked as offline, but may
> not be picked up by the iterator since it only reflects the state at that
> point. This can cause all in-sync followers to be dropped out of ISR
> unnecessarily and prevents a clean leader election.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
