without this change when batch process finishes the async reporter doesn't have time to properly shutdown and send out spans to Zipkin.
with this change we're registering a shutdown hook. AsyncReporter has no option to send out spans in a blocking way, so what we need to do to flush it, then wait for the configured time for the spans to be drained from the queue and then give a chance to send the spans out over the wire.
fixes gh-2035
without this change whenever a traced executor is created (either via a proxy or directly) we create a new instance of that traced wrapper. The problem with that is such that we create a lot of objects (e.g. each getExecutor() would return a new instance of the traced version). There are projects such as Micrometer that create WeakReferences to those objects. That means that if we don't cache the traced instance then we will lose the WeakReference upon the first GC.
with this change we're introducing new static wrapper methods that cache the traced instance for a given delegate. That means that not only will we create fewer objects but also we will honour the WeakReference mechanisms.
fixes gh-2020
without this change whenever a traced executor is created (either via a proxy or directly) we create a new instance of that traced wrapper. The problem with that is such that we create a lot of objects (e.g. each getExecutor() would return a new instance of the traced version). There are projects such as Micrometer that create WeakReferences to those objects. That means that if we don't cache the traced instance then we will lose the WeakReference upon the first GC.
with this change we're introducing new static wrapper methods that cache the traced instance for a given delegate. That means that not only will we create fewer objects but also we will honour the WeakReference mechanisms.
fixes gh-2020
* Add auto-configuration for spring kafka
* Add auto-configuration for spring kafka
* Make spring-kafka instrumentation autoconfig conditional on missing brave
Co-authored-by: flavium31 <w7og3bljlmmn742puqw2zwzu7ycuwmflr2nb4swrwzivccx6arpq>
This can be fixed by recording the wall time and the duration (using monotonic time) and calculating the end time using the duration (also converting them to the right units) but I think it does not worth the effort.
* First draft of instrumenting Spring Security
* Create events based on Authentication not SecurityContext
* Simplifying security config
* Checkstyle reformat
* Create DocumentedSpan and EventValue for Spring Security instrumentation
* Adding spring-security-bom to ensure the right dependencies are used.
* TracingSecurityContextChangedListenerTests
* Adding integration tests
* Deleting spring-cloud-sleuth-sample-security
* Checkstyle, license, javadoc
* Inlining SleuthSecuritySpan methods
* Deleting javadoc links from DocumentedSpan
* Updating auto-generated docs
