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
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.
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
without this change it could be nonclear where Tracer comes from and how you can use it.
With this change hopefully it get properly explained
fixes#402
without this change it could be nonclear where Tracer comes from and how you can use it.
With this change hopefully it get properly explained
fixes#402
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)
* Use StreamListener for coercing messages from JSON `Span`
Rely on the `contentType` header of the transported message to
tell Spring Cloud Stream how to coerce the message to `Span`.
* Use StreamListener for coercing messages from JSON `Span`
Rely on the `contentType` header of the transported message to
tell Spring Cloud Stream how to coerce the message to `Span`.
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
Sleuth doesn't create I64 binary annotations, but others might. This
version of zipkin fixes an encoding bug when someone logs a binary
annotation of type I64.
when the stream env post processor is executed headers are added endlessly - there is no check for the presence of the tracing headers.
with this change a check is added so the tracing headers are added only once.
fixes#387
when the stream env post processor is executed headers are added endlessly - there is no check for the presence of the tracing headers.
with this change a check is added so the tracing headers are added only once.
fixes#387
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
