[jira] [Resolved] (HTRACE-307) htraced: queries sometimes return no results even when many results exist due to confusion in iterator usage

["Masatake Iwasaki (JIRA)" <ji...@apache.org>]

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

Masatake Iwasaki resolved HTRACE-307.
-------------------------------------
       Resolution: Fixed
    Fix Version/s: 4.1

+1. committed this. Thanks, [~cmccabe].

> htraced: queries sometimes return no results even when many results exist due to confusion in iterator usage
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: HTRACE-307
>                 URL: https://issues.apache.org/jira/browse/HTRACE-307
>             Project: HTrace
>          Issue Type: Bug
>          Components: htraced
>    Affects Versions: 4.0
>            Reporter: Colin Patrick McCabe
>            Assignee: Colin Patrick McCabe
>             Fix For: 4.1
>
>         Attachments: HTRACE-307.001.patch
>
>
> htraced: queries sometimes return no results even when many results exist due to confusion in iterator usage
> When a range query such that greater than or less than is made, sometimes the value we are starting at is greater or less than the value of the relevant field in any span.  For example, let's say we have spans with end time 1, and 2, 3 and we do a query for end time < 999.  In that case, our leveldb iterator will actually not be in the 'end time index' section, but in the section after that, which happens to be the 'parent id index' section at the moment.  And so the following code will trigger and cut off the query results:
> {code}
>   if !bytes.HasPrefix(key, []byte{src.keyPrefix}) {
>     if lg.DebugEnabled() {
>       lg.Debugf("Can't populate: Iterator for shard %s does not have prefix %s\n",
>         shdPath, string(src.keyPrefix))
>     }
>   }
> {code}
> Of course, this is incorrect... there are 3 results, but we need to move the iterator backwards by one in leveldb to get to the last part of the "end time" index.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)