KV annotations are just "annotations", and the "start" and "stop"
annotations in zipkin are "acquire" and "release" (since, in
particular the latter can in principle happen more than once
and not necessarily the last thing that happens to a span).
TODO: decide if TraceContextHolder is really holding a Span
or a TraceContext (or TraceScope). Maybe think of a better
name for TraceScope.
Span name is properly optional in Zipkin, but it makes the logs
in Sleuth a lot easier to read. Process ID is optional because it
is a Sleuth feature, but it seems useful.
This reverts commit b4d71727bf.
This might not be the ultimate solution but it should give us
something to look at and collect some data. It doesn't solve the
sampling problem, or the headers copying problem.
See gh-14
There was an ordering error in the conditions as well, causing the
wrong async customizers to be registered. Another issue was the
servlet async processing (request atribute not cached in all branches)
resulting in multiple spans per request.
The client recv/send events have no meaning in a messaging
context, so we don't need to send them. Also added a new
protected method as the inverse of populatePropergatedContext.
Rebased on master and fixed conflicts.
See gh-15
An @Async method should start a new trace. Still not finished that bit
because if the user also customizes the async post processor there will
be a clash.
Biggest change here is better support for async web requests.
Each async request goes through the TraceFilter multiple times so you
have to re-attach to the span in the request if there is one.
Directly using the collector gives us more control of the annotations.
The main improvement/change here is that we need to send the span
name and parent details downstream as well as the span id. It's not
logically required by the trace model, but zipkin needs it, so it
can set annotations on the parent span (server recv/send).
