[
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)
