You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Swapnil Ghike (JIRA)" <ji...@apache.org> on 2012/11/01 22:50:13 UTC
[jira] [Updated] (KAFKA-596) LogSegment.firstAppendTime not reset
after truncate to
[ https://issues.apache.org/jira/browse/KAFKA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Swapnil Ghike updated KAFKA-596:
--------------------------------
Attachment: kafka-596.patch
Yes, that's a pretty sharp observation. The current time based roll policy only checks whether the segment was not appended for its lifetime. This patch has three fixes:
1. Initial assignment of firstAppendTime in Logsegment, because the non-primary constructor could potentially initialize the messageSet and set its size > 0. (I don't know if this fix will affect any other jiras.)
2. In maybeRoll(), a new condition makes sure that roll() happens based on time only if the messageset size > 0, thus different segments cannot have identical starting offsets. It also makes sure that a new segment is not rolled if the last segment is not appended with messages until now.
2. A segment is reborn at three places by setting its firstAppendTime to None if the message set size is 0 -
i. Log.maybeRoll()
ii. Logsement.truncateTo()
iii. Log.markedDeletedWhile()
> 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