[
https://issues.apache.org/jira/browse/HTRACE-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640939#comment-14640939
]
Masatake Iwasaki commented on HTRACE-209:
-----------------------------------------
bq. Rebase on earlier patches.
Both of {{git apply}} and {{patch}} have errors on many files. It seems not to
be just rebasing issue. Could you create new patch again? (htrace-core had few
errors and I succeeded to build and test by manually fixing rejected hunks.)
bq. We also now have a better format for span ID, based on the standard UUID
format: 00000000-0000-0000-0000-000000000000.
Is it misleading using UUID format for what is not UUID? Even random based UUID
seems to be little bit different from random number.
http://tools.ietf.org/html/rfc4122
{noformat}
-public class TraceInfo {
- public final long traceId;
- public final long spanId;
-
- public TraceInfo(long traceId, long spanId) {
- this.traceId = traceId;
- this.spanId = spanId;
- }
-
- @Override
- public String toString() {
- return "TraceInfo(traceId=" + traceId + ", spanId=" + spanId + ")";
- }
-
- public static TraceInfo fromSpan(Span s) {
- if (s == null) return null;
- return new TraceInfo(s.getTraceId(), s.getSpanId());
- }
-}
{noformat}
The patch effectively makes traceId and spanId tightly coupled. Because the
current TraceInfo has equivalent information with new SpanId, is it possible to
make the change backward compatible by leaving {{TraceInfo}} and
{{Trace#startSpan(String description, TraceInfo tinfo)}}?
> Make span ID 128 bit to avoid collisions
> ----------------------------------------
>
> Key: HTRACE-209
> URL: https://issues.apache.org/jira/browse/HTRACE-209
> Project: HTrace
> Issue Type: Sub-task
> Affects Versions: 4.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HTRACE-209.001.patch, HTRACE-209.002.patch,
> HTRACE-209.004.patch
>
>
> Make span ID 128 bit to avoid collisions in htrace 4.x
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
