Amazon will throw out trace IDs that aren't associated with a recent
timestamp. This encodes the current epoch seconds into the first 32
of a 128-bit trace ID to support conversion to an Amazon Root ID.
This adds the ability to opt out of span sharing between the client and
server side of an RPC. This is important when reporting to systems that
do not share span IDs, such as Google Stackdriver and Amazon X-Ray.
Amazon will throw out trace IDs that aren't associated with a recent
timestamp. This encodes the current epoch seconds into the first 32
of a 128-bit trace ID to support conversion to an Amazon Root ID.
whenever:
- a span or trace id get generated when a request / message arrives
- child span is created
we set the field to false
whenever we find ids in the incoming request / message we set the field to true
fixes#696
without this change we created a "fallback span" in the case where a Spring component didn't handle the span. By handling it means that it got processed by anyway (a tag, log was added etc.). Why did we do that? That's because if no component was involved in creation of additional spans then in the Zipkin UI the service that had only the span that has the SR, SS logs wouldn't show up. In other words, if service A called service B and service B had only a single span, then service B wouldn't show up in the UI (there would be no blue bar). All the data would show up however in the client side of that span.
with this change we're removing this behaviour. That's because it introduces confusion for our users, that use non Spring related components. Also it seems that the Zipkin UI got fixed and this error no longer is present. If however it turns out that it's still there, it clearly seems that the place to fix this error should be Zipkin and not Sleuth.
fixes#708
