Local Ip determined from spring.commons InetUtils.
To enable local endpoint resolution via service discovery, DiscoveryClient must be present and 'spring.zipkin.service.locator.discovery' should be set to true.
FallbackHavingEndpointLocator was caching and recreating EndpointLocator in the same time - removed the caching part.
Fixes gh-403
without this tag it's impossible to discern from which server was the given span originated
with this change we're adding a tag in which we're passing the instance id value. The value can be taken either from Cloud Foundry or from a concatanation of some local properties like instance_id / application name / application port etc.
fixes#369
without this tag it's impossible to discern from which server was the given span originated
with this change we're adding a tag in which we're passing the instance id value. The value can be taken either from Cloud Foundry or from a concatanation of some local properties like instance_id / application name / application port etc.
fixes#369
without this only either service discovery service id / spring.application.name can be chosen as a service name for zipkin
with this change you can pass spring.zipkin.service.name property to change override that both for HTTP and Stream collectors
fixes#324
without this only either service discovery service id / spring.application.name can be chosen as a service name for zipkin
with this change you can pass spring.zipkin.service.name property to change override that both for HTTP and Stream collectors
fixes#324
without this change when queue size of spans is exceeded for Stream span propagation, an exception is thrown that terminates business logic processing
with this change we're not propagating the exception - we're incrementing the dropped spans counter
fixes#421
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`.
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
Added configurable PollerMetadata bean to be used with the Inbound
Channel Adapter in the StreamSpanReporter. Fixed delay and max messages
per poll are configurable via configuration properties. Implementors can
provide a bean of type PollerMetadata and name
StreamSpanReporter.POLLER to take full control of the poller.
Fixes: gh-338
Spring Cloud Stream changed the names of the headers config
that we need to propagate headers in kafka (and other binders
that do not support headers natively).
Fixes gh-284
