[
https://issues.apache.org/jira/browse/HTRACE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025657#comment-15025657
]
Colin Patrick McCabe commented on HTRACE-307:
---------------------------------------------
The patch adds a {{checkKeyPrefix}} function which examines the leveldb key
prefix to see if it is before or after the relevant section in leveldb that we
are "supposed" to be in for the query. Of course, "before" and "after" are
inverted when we are doing a descending query such as "less than". This fix is
similar to the fix in HTRACE-304 (and the bug is similar too).
> 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
> 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 begin time 10,
> and 11, 12 and we do a query for begin time > 0. In that case, our leveldb
> iterator will actually not be in the 'begin time index' section, but in the
> section before that. 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 step
> forward by one key in leveldb to see them in the begin time index.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
