Mailing-List: contact kafka-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: kafka-dev@incubator.apache.org
Date: Fri, 2 Nov 2012 07:02:14 +0000 (UTC)
From: "Swapnil Ghike (JIRA)" <jira@apache.org>
To: kafka-dev@incubator.apache.org
Message-ID: <255798547.59597.1351839734485.JavaMail.jiratomcat@arcas>
In-Reply-To: <219135262.51144.1351702152421.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (KAFKA-596) LogSegment.firstAppendTime not reset
 after truncate to
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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