This supports 128-bit traces via a new field traceIdHigh, which matches
other zipkin implementations. In encoded form, the trace ID is simply
twice as long (32 hex characters).
With this change in, a 128-bit trace propagated will not be downgraded
to 64-bits when sending downstream, reporting to Zipkin or adding to
the logging context.
This will be followed by a change to support initiating 128-bit traces.
This ensures spans that have remote set to true don't send
Span.timestamp/duration.
In the RPC span model, the client owns the timestamp and duration of the
span. If we were propagated an id, we can assume that we shouldn't
report timestamp or duration, rather let the client do that. Worst case
we were propagated an unreported ID and Zipkin backfills timestamp and
duration.
See https://github.com/openzipkin/openzipkin.github.io/issues/49
Now that Endpoint has ipv6, the factory method is even worse than it
was before. This switches to a builder instead.
Note: Endpoint now has a nice toString which should help debugging.
AsyncReporter is a more robust version of what we were doing before.
Notably, it can give a memory threshold instead of span count for the
backlog. This change ports to use AsyncReporter internally.
See https://github.com/openzipkin/zipkin-reporter-java#asyncreporter
it turned out that some of the tests were leaky and didn't catch that ExceptionUtils were throwing an exception (race condition with Hystrix). That was due to the fact that When Hystrix with Feign were doing retries the RequestInterceptor wasn't called. That means that a new span wasn't created but a parent span was closed.
With this change the only place where the span creation and closing takes place is TraceFeignClient. I removed the Feign RequestInterceptor. Now whenever there is a retry - a new span is created and closed after getting a response. There are no exceptions, special cases etc.
In addition to that since Feign is fully immutable and SpanInjector is by design made to mutate objects I had to wrap the immutable Request in an AtomicReference in order to change the contents of the Request. I'm ashamed but didn't have a better idea. Since that is packaged scope nobody should every see that (outside the package of course)
Formerly, `Span.getAccumulatedMillis()` worked, but could returns
imprecise measurements, particularly local spans. This changes the
internals of Span to keep track of a start tick. Using this, it can
return a more precise `Span.getAccumulatedMicros()`.
To ensure this precision isn't lost in serialization, this adds a
json field `durationMicros`, which is only set when the span is stopped.
This is set instead of start tick because `System.nanoTime()` is JVM
specific and so cannot be used across the network. `durationMicros` uses
null instead of zero comparisons because nano time can be negative.
Fixes#312
Removes wiremock as a test dependency in core (which created more
issues than you might expect because Tomcat and Jetty don't treay
HTTP headers in the same way apparently).
Also moves the spring-messaging dependency to where it is needed
in sleuth stream.
