[
https://issues.apache.org/jira/browse/KAFKA-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14944398#comment-14944398
]
Jiangjie Qin commented on KAFKA-2477:
-------------------------------------
[~junrao] I'll fix the nexOffsetMetadata in the patch.
Would the following case be what the last line was trying to address?
1. Leader is on broker 1, HW=X, LEO=Y, Y > X
2. A fetch request from follower goes to broker 1 to fetch from offset Z.
Assume X < Z < Y.
3. Broker 1 proceeds with fetch request and enters Log.read()
4. Leader migration occurs, log on broker 1 got truncated to X.
In this case, because the FetchRequest has passed the leader check before
leader migration, no NotLeaderForPartitionException would be thrown. Also
because the read does not grab any lock, the log truncation might occur before
the actual message search occur.
> Replicas spuriously deleting all segments in partition
> ------------------------------------------------------
>
> Key: KAFKA-2477
> URL: https://issues.apache.org/jira/browse/KAFKA-2477
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.8.2.1
> Reporter: Håkon Hitland
> Assignee: Jiangjie Qin
> Fix For: 0.9.0.0
>
> Attachments: kafka_log.txt, kafka_log_trace.txt
>
>
> We're seeing some strange behaviour in brokers: a replica will sometimes
> schedule all segments in a partition for deletion, and then immediately start
> replicating them back, triggering our check for under-replicating topics.
> This happens on average a couple of times a week, for different brokers and
> topics.
> We have per-topic retention.ms and retention.bytes configuration, the topics
> where we've seen this happen are hitting the size limit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
