kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jun Rao (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-596) LogSegment.firstAppendTime not reset after truncate to
Date Fri, 02 Nov 2012 15:13:12 GMT

    [ https://issues.apache.org/jira/browse/KAFKA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489473#comment-13489473

Jun Rao commented on KAFKA-596:

I agree that setting firstAppendTime to None in Logsement.truncateTo() is necessary. However,
I don't think this is necessary in Log.maybeRoll() and Log.markedDeletedWhile(). In both cases,
we are not changing the log segment. So whoever changed the segment last to make its size
0 (either through truncation or creation) would have set firstAppendTime properly. Note that
maybeRoll is called on every log append. We don't want to add unnecessary overhead.
> 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

View raw message