Reactor decorator added too late

Hello,

We are trying to replace Spring Clould Sleuth by your opentracing solution. In general, it works mostly fine 👍 Thanks a lot for the great work!

However, we have encountered an edge case when Reactor schedulers might not be decorated with TracedScheduledExecutorService, even if the lambda is added by ReactorTracingAutoConfiguration.

To be able to easily explain the problem, I forked your repo and modified a bit the test: https://github.com/chengchen/java-spring-cloud/blob/0.2.5-CJI/instrument-starters/opentracing-spring-cloud-reactor-starter/src/test/java/io/opentracing/contrib/spring/cloud/reactor/ReactorTracingAutoConfigurationTest.java

With your current implementation, the Reactor schedulers won’t be decorated and thus a failing test. This is because Schedulers.parallel() is already initialized / cached in TestController before ReactorTracingAutoConfiguration adding the decorator. Unless you restart the parallel scheduler and discard the cached reference, this cached one will always be there without the ability to propagate tracing infos. This issue is partially related to how Reactor schedulers are designed… (and we can not control how / when users would call Schedulers.parallel())

I took a look at how it’s done in Sleuth, and try to do the similar way, it seems to work for our use cases: https://github.com/chengchen/java-spring-cloud/blob/0.2.5-CJI/instrument-starters/opentracing-spring-cloud-reactor-starter/src/main/java/io/opentracing/contrib/spring/cloud/reactor/ReactorTracingAutoConfiguration.java

But I am not sure how robust is this solution, and I would like to get some feedbacks from you guys before doing anything concrete. Besides, this solution requires changes on opentracing-reactor and opentracing-concurrent projects as well.

Many thanks!

Chengchen

[csabakos]

@chengchen The lazy operators were introduced as a fix for https://github.com/spring-cloud/spring-cloud-sleuth/issues/866 so I’m assuming that it’s not just dead code and there are some configurations out there in which the “not active bean factory” code path is useful. That said, I don’t know off the top of my head how to construct a test case that reproduces the issue.

I think we don’t have to handle that case for now, since it’s unclear how to exactly reproduce it. If it’s a real-world issue, somebody will file a ticket for it soon enough. 😃 For now, I suggest just logging an error and foregoing instrumentation for non-active bean factories.

[pavolloffay]

I am not very familiar with the reactor, therefore I would defer on @csabakos. I would also say if it follows sleuth approach it’s probably good.

The changes to all mentioned projects should be discussed there as they are reused across various instrumentations.