Introduces SpanIdGenerator, used to control id generation.

[codefromthecrypt]

There are a few use cases that support decoupling ID generation

• allow an alternate random generator, or change its seed to avoid collisions
• opt out of span id == trace id for the root span
• make trace-id a request-id, for log correlation, regardless of sampling
• make Brave easier to test

See openzipkin/zipkin#849

[codefromthecrypt]

cc @eirslett @yurishkuro

[yurishkuro]

Hm, the difficult problem here is the encoding of the IDs on the wire once they are made opaque. Right now Brave doesn't have that since SpanId class still prescribes a Zipkin-esque structure. If you make SpanId completely opaque like I have in opentracing-go, you have to address two issues, (a) provide pluggable serialization mechanism (e.g. StringPickler in opentracing-go), and (b) find a way to deal with binary protocols, such as TChannel, which assumes tracing info to be of fixed length, and specifically to be Zipkin-esque. That last part is an unfortunate design choice in TChannel, imo, but the fixed length within a binary frame can be a common limitation.

Just curious, are you suggesting one of the ID implementations to be path-like IDs a.b.c.d? What is the benefit of it over Zipkin id + parentID scheme?

[pbetkier]

Uncomment?

(edit): oh, brave supports 1.7.

[codefromthecrypt]

This was intentional, but seems it failed to do the job ;) ex brave core is java <8, but I want this type to be a functional interface so it can be implemented with a lambda. I can make the note more explicit?

[codefromthecrypt]

PTAL updated the comment!

[pbetkier]

I guess adding a note like // @FunctionalInterface (commented out because of Java 7 support) or // @FunctionalInterface (uncomment after dropping Java 7 support) would help. But it's a minor thing :)

[pbetkier]

I added this last comment before seeing your changes. It's ok :)

[codefromthecrypt]

good feedback!

[codefromthecrypt]

Hey, Yuri Appreciate the feedback, but this wasn't an attempt to make brave not zipkin. You'll notice that requires far more work than this (ex. Zipkin span is used everywhere). This is mainly to make it possible to control id generation for the existing use cases without breaking compat. In other words a strategic move to be more different is indeed interesting, but I would at least title the pull request more profoundly if that were my intent!

[codefromthecrypt]

Ex at Twitter, different random seeds were used by device to avoid
collisions. This was done in zipkin format by controlling the random
generator.

Also trace ids are not mutated once created, so when brave creates a trace,
no chance something will change its encoding (inside the long) as the
encoding of long is currently fixed in zipkin v1 as big endian via thrift
tbinary protocol. This particular feature is not a high level goal of mine,
just something I heard from Eirik.

[eirslett]

Changing the way we generate span IDs was a suggestion from the Budapest workshop, Autolytics' software memory did something similar.
The idea is to encode the position in an execution tree, like "0.0.1.4.7", in the span ID. That value would be encoded as a long, so the span ID would always be a long (and not an arbitrary structure).

[codefromthecrypt]

ahh so you weren't referring to encoding into the bytes, more changing the structure of the ids so that they can hold a tree. gotcha.

[codefromthecrypt]

I'll remove the "encoding" part as I think this doesn't solve that problem as I now understand it. cheers.

[codefromthecrypt]

ok code is the same, but I updated the description/commit message

[codefromthecrypt]

PS this is no longer blocking me, as I found a way around it. We can close this or park it if there's no other person interested.

[codefromthecrypt]

Here's some rationale from @jcarres-mdsol about trace-id vs span-id

in Ruby we have something like "if I do not know the route you are talking about do nothing" . To avoid sending traces when scripts kiddies scan our apps for security holes. But we will even change that to "first create new span and properly set ids, then open thread, now we deal with everything zipkin related".
i.e creating new spans and ids is an operation that should always be successful and happen before we call anything else in this request.
But zipkin traces may depend on if the request is valid or on sample rate and may happen in a different thread, no problem

[codefromthecrypt]

closing for lack of interest and need. can always re-open