[
https://issues.apache.org/jira/browse/HTRACE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe updated HTRACE-307:
----------------------------------------
Description:
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.
was:
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.
> 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 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)
