[
https://issues.apache.org/jira/browse/HTRACE-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14336938#comment-14336938
]
Colin Patrick McCabe commented on HTRACE-115:
---------------------------------------------
{{query.go}}: forgot to run format.sh last time... fix a formatting issue there.
{{span.go}}: SpanId should now be defined in terms of a uint64, not an int64.
{{datastore.go}}: get rid of a lot of places that used int64 in a sloppy way.
We want everything to be unsigned here. Most of all, we want to use the
{{common.SpanId}} type to represent span IDs whenever possible. Probably the
trickiest part of this is dealing with begin, end, and duration times, which
are signed. When creating leveldb indices for these, we flip the highest bit
so that they compare as expected in the unsigned world.
Why don't we just enforce that Begin, End, and Duration are non-negative?
Well, it's more work to do things that way. Keep in mind, if we have clock
skew, Duration can easily be negative. Things can get hairy when you're
subtracting unsigned numbers and you come up with a result that "should be"
negative. So it's easier to just encode the negative durations as described
earlier when creating or searching indexes. That way we don't have to think
about this issue after we apply the encoding.
{{rest.go}}: fix more sloppiness here. We should just use the
{{common.SpanId}} type whenever referring to span ids.
> The htraced datastore should use uint64 for span ids rather than int64
> ----------------------------------------------------------------------
>
> Key: HTRACE-115
> URL: https://issues.apache.org/jira/browse/HTRACE-115
> Project: HTrace
> Issue Type: Bug
> Affects Versions: 3.2.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HTRACE-115.001.patch
>
>
> Currently we manipulate span IDs as int64 rather than uint64 in some places
> in the htraced datastore. This is wrong since it makes the comparison
> operators work differently than would be expected. We should fix it to use
> uint64.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
