For ZipkinSpanReporter we're not applying the adjusting of a span to an adjusted span. In other words each subsequent adjuster is ignoring the results of the previous adjusting
fixes gh-816
Under load, the previous version of zipkin-reporter's AsyncReporter
caused a lot of overhead. This version fixes that by ensuring encoding
is deferred and not done inside a lock.
without this change any exception that is not caught by a filter, get caught and logged by server's internals (e.g. Tomcat's Valve). To make the Valve log the exception together with the tracing information we would have to allow the tracing context remain in the thread after TraceFilter gets executed. That is problematic cause we're polluting the ThreadLocal and would have to assume that some component will eventually clear the context.
with this change we're trying to solve the issue from a different angle. Whenever an uncaught exception is thrown, we are already catching it in the `catch(...) {}` clause. It's enough to just log it at the error level and that way, regardless of the underlying server implementation (Tomcat, Undertow) we will log the uncaught exception and rethrow it.
fixes#714
This does two things: ensures samples don't use Zipkin v1 in any way,
and misaligns the version numbers of zipkin v1 and zipkin v2 apis.
This is an attempt to walk around the gradle plugin issue, which only
exists when someone is using both versions of zipkin.
See https://github.com/spring-projects/spring-boot/issues/10778
This deprecates span transports in favor of `spring-cloud-sleuth-zipkin2`
which:
* Supports RabbitMQ and Kafka automatically when adding spring-rabbit or spring-kafka deps
* Supports any io.zipkin.reporter2:zipkin-reporter sender, including Amazon X-Ray
* Defaults to zipkin v2 format, but can be configured to use zipkin v1 format as needed
This lowers the amount of maintenance on the project, as discussed in various issues
See #727
See #711
