without this change we had to treat every mean of injecting and extracting span information separately
with this change all means of communications are abstracted. That way you configure things once only.
part of #237
without this change when you disable Sleuth web client the context fails to load
with this change it's working fine. We've moved beans around + the async web client will be turned off automatically if the sync one is also disabled
fixes#433
Ensuring that disabling of modules work
without this change when you disable Sleuth web client the context fails to load
with this change it's working fine. We've moved beans around + the async web client will be turned off automatically if the sync one is also disabled
fixes#433
without this change there's no error colouring on Zipkin side
with this change we set error tags
- whenever there is an exception thrown on the server side (5xx)
- wheneber on the client side it's impossible to send a message
fixes#384
without this change there's no error colouring on Zipkin side
with this change we set error tags
- whenever there is an exception thrown on the server side (5xx)
- wheneber on the client side it's impossible to send a message
fixes#384
without this example it might be misleading for users how to work with callables and custom executors.
with this example we're showing both the case when you're using a custom executor (in this case you just have to register it as a bean and then use that bean in your callable); and also we show an example of how to reuse the taskScheduler one (it's enough to wrap it with LazyTraceExecutor).
fixes#423
without this example it might be misleading for users how to work with callables and custom executors.
with this example we're showing both the case when you're using a custom executor (in this case you just have to register it as a bean and then use that bean in your callable); and also we show an example of how to reuse the taskScheduler one (it's enough to wrap it with LazyTraceExecutor).
fixes#423
without this change any exception occurring while creating a span will be swallowed.
with this change we're propagating the exception so that it gets handled properly.
fixes#426
without this change any exception occurring while creating a span will be swallowed.
with this change we're propagating the exception so that it gets handled properly.
fixes#426
without this change if the users sends invalid headers then exceptions are thrown.
with this change extractors catch the exception, log it and then a new span is created. That of course will lead to an invalid trace graph cause a new trace will be created but at least business apps will not be broken due to an issue in instrumentation.
fixes#425
without this change if the users sends invalid headers then exceptions are thrown.
with this change extractors catch the exception, log it and then a new span is created. That of course will lead to an invalid trace graph cause a new trace will be created but at least business apps will not be broken due to an issue in instrumentation.
fixes#425
When wrapping a ThreadPoolTaskExecutor in a bean postprocessor
we should take care that the delegate gets the lifecycle callbacks
from the container. Otherwise when it is first used, the thread pool
will not have been initialized, resulting in an exception.
(Can't believe this ever actually worked)
Some components in Spring assume (perhaps wrongly) that a channel
interceptor will not convert a mutable message into an immutable
one, and they continue to modify the headers dowstream. We can
dosge the issue of whether this is right or wrong by keeping the
message headers mutable, just in case.
It would probably be better to refactor the SpanInjector so that
it works with something other than the MessageBuilder, but we can
defer doing that in favour of this smaller change that works.
Adds a test for mutability. Also tested with the
gs-messaging-stomp-websocket guide from spring.io.
Fixes gh-276
When wrapping a ThreadPoolTaskExecutor in a bean postprocessor
we should take care that the delegate gets the lifecycle callbacks
from the container. Otherwise when it is first used, the thread pool
will not have been initialized, resulting in an exception.
(Can't believe this ever actually worked)
Some components in Spring assume (perhaps wrongly) that a channel
interceptor will not convert a mutable message into an immutable
one, and they continue to modify the headers dowstream. We can
dosge the issue of whether this is right or wrong by keeping the
message headers mutable, just in case.
It would probably be better to refactor the SpanInjector so that
it works with something other than the MessageBuilder, but we can
defer doing that in favour of this smaller change that works.
Adds a test for mutability. Also tested with the
gs-messaging-stomp-websocket guide from spring.io.
Fixes gh-276
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
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.
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
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)
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
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
