Hystrix is complex and the stacks get very deep. It turns out that
it is also rather stateful, so order of tests affects the outcomes.
Long story short: if you set the concurrency strategy it infects
other tests (like the TraecCommandTests), which then have to assert
slightly more carefully.
The TraceFilter should clean up its own spans. It should never
need to use the SpanContextHolder directly.
There was a test that needed it inserted instead.
The fact that a Span was active when a new one is created needs
to be recorded, but it doesn't seem to belong in the Span. However
the DefaultTracer can call other methods on the SpanContextHolder
and that's what this change does (with package private methods).
There are still some usages of the public methods in
SpanContextHolder which I'd like to stamp out as a separate issue.
Fixes gh-141
Also allows us to actually create a PercentageBasedSampler (I
don't think anyone tried it before) without resorting to
lazy beans and proxies.
Another freature added here is a default percentage sampler
if we know that spans need to be exported (zipkin or stream
is present).
Fixes gh-138
It also turns out that there's a bug in Spring MVC which makes an
empty header blow up in RequestHeaderMapMethodArgumentResolver
so we set the header to "true" instead of empty.
Fixes gh-136
Previously, if a trace id came into the filter from the caller and
the controller was async, the span context was not properly managed
resulting in warnings in logs.
Fixes gh-137
Now that the span data is stored in a header it is safe to remove
the slightly clunky propagation implentation that used a subclass.
Also removed the Stomp* features because they were diverging from
the mainstream integration support and no-one seems to understand
why they are needed. If the original author of #96 can explain
why they were needed we can ask for a new PR to re-instate a version
that works with the new model.
Changes following review
- Reusing CounterService to automatically profit from Dropwizard if present
- NoOp is the default impl for SpanReporterService
- SpanReporterService has configurable metric names (it's enough to change the
name to 'meter.a.b.c' to profit from Dropwizard's meters)
Fixes gh-99
It still feels brittle because it's up to the suthor of the
instrumentation. This patches all the places where we were still
using Long instead of Long.toHexString(..).
Fixes gh-125
User can now configure message headers to be added using
spring.sleuth.keys.message.headers.
Fixes gh-119
Also a bunch of cosmetic changes (imports etc).
Previously, sleuth logged more data than necessary. This led to issues
including spans approaching megabytes each. This pares down default keys
to a minimal set, but allows users to opt-into logging more by extending
`TraceFilter`.
- Changed Random instantiation to a shared Random
- Changed the name of the converter
- Changed generator into random
- Span id is now non-nullable.
- it gets generated in the http filter if it's not there
- it's generated in the spring-integration channels if it wasn't set
Recent versions of zipkin and brave operate with http instead of scribe.
This changes the implementation accordingly, as well adds a sampler to
the POST endpoint.
A notable impact is that we no longer require a collector process, as
the zipkin server's POST endpoint is a collector.
