Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka >> mail # dev >> [jira] [Issue Comment Deleted] (KAFKA-1018) tidy up the POM from what feedback has come from the 0.8 beta and publishing to maven

Copy link to this message
[jira] [Issue Comment Deleted] (KAFKA-1093) Log.getOffsetsBefore(t, …) does not return the last confirmed offset before t

     [ https://issues.apache.org/jira/browse/KAFKA-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Swapnil Ghike updated KAFKA-1093:

    Comment: was deleted

(was: Created reviewboard https://reviews.apache.org/r/14772/

> Log.getOffsetsBefore(t, …) does not return the last confirmed offset before t
> -----------------------------------------------------------------------------
>                 Key: KAFKA-1093
>                 URL: https://issues.apache.org/jira/browse/KAFKA-1093
>             Project: Kafka
>          Issue Type: Bug
>    Affects Versions: 0.8
>            Reporter: Swapnil Ghike
>            Assignee: Swapnil Ghike
>         Attachments: KAFKA-1093.patch
> Let's say there are three log segments s1, s2, s3.
> In Log.getoffsetsBefore(t, …), the offsetTimeArray will look like - [(s1.start, s1.lastModified), (s2.start, s2.lastModified), (s3.start, s3.lastModified), (logEndOffset, currentTimeMs)].
> Let's say s2.lastModified < t < s3.lastModified. getOffsetsBefore(t, 1) will return Seq(s2.start).
> However, we already know s3.firstAppendTime (s3.created in trunk). So, if s3.firstAppendTime < t < s3.lastModified, we should rather return s3.start.
> This also resolves another bug wherein the log has only one segment and getOffsetsBefore() returns an empty Seq if the timestamp provided is less than the lastModified of the only segment. We should rather return the startOffset of the segment if the timestamp is greater than the firstAppendTime of the segment.

This message was sent by Atlassian JIRA