[
https://issues.apache.org/jira/browse/KAFKA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489286#comment-13489286
]
Swapnil Ghike commented on KAFKA-596:
-------------------------------------
Actually the modification in maybeRoll() in the conditions that determine
whether to roll a new segment or not, is enough for correctly fixing the issue
mentioned above. The fix rolls a new segment only if the size of messageSet is
> 0. So if we truncated the segment to size 0, maybeRoll() will not roll a new
segment at the same starting offset.
I kept those lines in Log.maybeRoll(), Logsement.truncateTo() and
Log.markedDeletedWhile() for optimization. Setting the firstAppendTime to None
whenever the size is found to be 0 will postpone the next time based roll and
also will not harm correctness.
> LogSegment.firstAppendTime not reset after truncate to
> ------------------------------------------------------
>
> Key: KAFKA-596
> URL: https://issues.apache.org/jira/browse/KAFKA-596
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 0.8
> Reporter: Jun Rao
> Assignee: Swapnil Ghike
> Labels: bugs
> Attachments: kafka-596.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently, we don't reset LogSegment.firstAppendTime after the segment is
> truncated. What can happen is that we truncate the segment to size 0 and on
> next append, a new log segment with the same starting offset is rolled
> because the time-based rolling is triggered.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
