TraceFilter no longer is a OncePerRequestFilter
TraceFilter processes the request that is executed upon ERROR dispatch (the logs will be present there)
Altered the logic in TraceFilter that an already processed request will not be detached (which resulted in an exception)
Added some debugging to instrumentation
Added assertion over a list of spans
Bumped up SC-Netflix to 1.1.2.BUILD-SNAPSHOT
Added Zuul integration tests
Added Http keys injection to Zuul client call
until now if traceid was set and span id wasn't we were generating a new span id. That approach was wrong since
1) there shouldn't be such a situation in the first place (you have to have neither or both headers set)
2) if there is one we should assume that the span is the root one
so ATM in case of missing span id we are placing the trace id value there.
with this change trace filter is not closing all spans. It's closing only spans when the response is successful. If the response status is 4xx,5xx then an exception controller should start processing the response. At the end of the day an aspect will close the span once the controller has finished processing.
fixes#278
After this change a custom FeignContext is created that before returning instance or instances of beans will wrap, if necessary, that bean into a tracing representation. That way all the custom Feign configurations will have wrapped beans and tracing will get propagated.
Fixes#286
With RxJava 1.1.4, `RxJavaPlugins.reset()` method has been made public (though `experimental`). With this update, we no longer require to manually wrapp and expose the `reset()` method of RxJavaPlugins. This PR is in conjunction with [Spring-Cloud-Netflix PR] (https://github.com/spring-cloud/spring-cloud-netflix/pull/1007) since RxJava version is maintained as a part of that dependency. Merge this PR only after the Spring-Cloud-Netflix PR is merged to avoid compile errors.
Removes wiremock as a test dependency in core (which created more
issues than you might expect because Tomcat and Jetty don't treay
HTTP headers in the same way apparently).
Also moves the spring-messaging dependency to where it is needed
in sleuth stream.
when an exception was thrown by Feign it was not caught by our Feign customizations and wasn't properly closed. By adding a custom implementation we're closing span whenever an exception is thrown.
Fixes#257
The problem resulted in wrong span durations. The issue was such that for the case where span from request has a parent that needs to be reported we didn't stop that parent. That means that it has value of 'end' equal to 0. In that situation the duration of Span was calculated as a difference between current time and the start time. We should never report spans that have not been stopped - otherwise that stopping will take place a lot of time later.
fixes#247