[
https://issues.apache.org/jira/browse/KAFKA-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14735015#comment-14735015
]
Jiangjie Qin commented on KAFKA-2477:
-------------------------------------
[~hakon] Yes, that's correct.
The log appending does the following two things:
1. Append message to log
2. Update Log.nextOffsetMetadata.messageOffset.
If two follower reads come between 1 and 2. There will be a out of range
exception. I think the fix is to read up to
Log.nextOffsetMetadata.messageOffset for replicas instead of max size.
Are you interested in submitting a patch?
> 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
> 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)
