Feature Request: Supporting rxjava observables with Rxjava Schedulers

[shivangshah]

So far, the tracer's context is lost when using DeferredResult+Observable+Schedulers. It'd be nice to have this supported out of the box with spring-sleuth. Looking at the example here: http://blog.mabn.pl/2014/11/rxjava-logback-and-mdc-threadlocal.html, a RxJavaSchedulersHook can be created (and registered as an RxJava Plugin) and sleuth related variables can be copied over to the newly created thread.

[marcingrzejszczak]

Pull requests are more then welcome :)

[shivangshah]

@marcingrzejszczak I will give it a go. Would you be able to point me in the direction of which threadlocal variables specific to sleuth need to be copied over?

[marcingrzejszczak]

Sure!

There are the SpanInjector and SpanExtractor interfaces that will help you with that. Let's take a look at https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/instrument/web/client/HttpRequestInjector.java .

One passing tracing information FROM Sleuth to SOMETHING we're using a SpanInjector. It means that we will leave Sleuth and get outside the process most likely (but no necessarily). In that example you can see that from a Span we're putting information to a HttpRequest. You can see which information is important for us. All the header names are there in the Span class as static constants.

If you want to get information from SOMETHING and build a Span then you're using the SpanExtractor. Example for messaging - https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/instrument/messaging/MessagingSpanExtractor.java . As you can see from a carrier (Message / HttpRequest etc.) that has the tracing information we will build a Span - by means of a Span.builder().

Don't hesitate to ping me here or on Gitter in case of any further questions https://gitter.im/spring-cloud/spring-cloud-sleuth?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge

[shivangshah]

@marcingrzejszczak 👆

[shivangshah]

@marcingrzejszczak I have pushed the code changes to my own fork (for now, no PR yet). You can find the code here: shivangshah@b5bf395
Let me know what you think. The unit testcases look ok (I think), but I wonder if there needs to any integration test cases? I didn't see any for HystrixConcurrencyStrategy.

[marcingrzejszczak]

I'll take a look at that tomorrow - the integration tests are everywhere else cause by default the SeltuhHystrixConcurrencyStrategy gets registered in each context in every integration test