without this change there was a gap in passing tracing info to executors.
With this change the Executors are wrapped in LazyTraceExecutor and ThreadPoolTaskExecutors are wrapped in their tracing representation too
fixes#410
The first step of transitioning to 128bit `X-B3-TraceId` is tolerantly reading 32 character long ids by throwing away the high bits (any characters left of 16 characters). This allows the tracing system to more flexibly introduce 128bit trace id support in the future.
Ex. when `X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124` is received, parse the lower 64 bits (right most 16 characters ex48485a3953bb6124) as the trace id.
without this change we were wrapping the ZuulHandlerMapping in its tracing representation.
with this change we are simplifing that by adding interceptors
fixes#399
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)
when TLBFC is throwing an exception the span wasn't closed. Throwing exception can occurr when IOExcepiton is thrown. Then the span wouldn't be closed and the whole series of problems occur.
fixes#393
after making TraceFilter process different dispatch types we've introduced a bug related to filter ordering. TraceFilter was registered with a default ordering which is of lowest precedence.
With this change we ensure that the ordering of TraceFilter is fixed.
Fixes#380
with this change we no longer treat retries as a continuation of a previous span. That way the Feign code simplifies a lot. RequestInterceptor starts a span and the TraceFeignClient will always close it no matter what's happening.
fixes#202
with this change if a span hasnt set any Hystrix related spans then we're setting the tags even if the span gets continued (which is the case when you're using Javanica
fixes#352
with this fix if someone is not using Feign he gets the default traced Feign.Builder. Thanks to this no more exceptions should be seen in terms of closing the wrong span.
fixes#350
Makes use of property place holders to set the patterns attribute of the
@GlobalChannelInterceptor annotation used for the
TraceChannelInterceptor. As supported by the annotation, only simple
patterns are supported.
Added the Spring configuration metadata for spring.sleuth.integration
properties.
Fixes gh-323
with this change the missing methods in ExecutorService are wrapped with LocalComponentTraceCallable. We are wrapping only those callables that have not already been wrapped. Kudos to @PranayPS for finding the issue and proposing a solution.
Fixes#333
* Fix headers in messaging
with this change the span related headers are changed to be compatible with messaging specs. The change is backwards compatible so we accept the old ones as input, and as output we're producing both new and old headers.
fixes#332
* Re-added missing server side span
with this change
- HandlerInterceptor is responsible for wrapping requests in spans
- added Sring Data REST instrumentation
- added Zuul instrumentation
- it will not wrap error controller related requests with spans
- tests have been changed to ensure that ALWAYS there is at least one span on the server side (that way it will show up in Zipkin)
- "fallback" mechanism has been added that if a HandlerInterceptor hasn't been used then we are forcing creation of a Span at the server side
fixes#321
(cherry picked from commit 4f1ef52e6c)
with this change RibbonRequestCustomizers are created for
- Netflix HttpClient
- OkHttp client
- Apache HttpClient
those customizers know how to inject span into the given context. Also a wrapper over a RibbonCommandFactory bean gets created that injects http trace keys to the given span
fixes#313
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
Fixed integration tests to use ZipkinRule
Introduce assertj assertions (#315)
* Introduce assertJ assertions in some tests
* Fix code formatting to be inline with Spring rules
with this change the child span of the HTTP filter span gets changed into a span coming from the Controller aspect. The name of the span becomes the name of the method.
