Propagate distributed tracing information across Thread pool bulkhead

Using using Spring Cloud Sleuth distributed tracing, one needs to take care to handover trace information across threads.

The way Sleuth does this is generally by wrapping beans in the application context with tracing ones. Specifically in the case TraceableExecutorService.

Currently in resilience4j-spring-boot2 I see no way in ThreadPoolBulkheadConfiguration to provide an ExexcutorService factory or decorator

Resilience4j version: 1.1.0

Java version: 11

Problem description:

Spring Cloud Sleuth propagates tracing by default using ThreadLocal. When handing over tasks to a thread pool care must be taken to create a new Span based on the current Span such that this action is recorded in the trace.

The usual approach to this is to [decorate the Runnable or Callable] with a tracing aware option that grabs the current context on construction and wraps execution in a scoped Span.

The Resilience4j Spring Boot 2 integration using @Bulkhead wraps method calls in an aspect, which submits the execution to an ExecutorService in FixedThreadPoolBulkhead. This is bootstrapped through ThreadPoolBulkheadConfiguration. As the ExecutorService is created in the bulkhead’s construction there is no way to wrap the ExecutorService in a trace aware one. There is also no mechanism to supply a custom Callable wrapper to BulkheadAspect#proceedInThreadPoolBulkhead.

This precludes the use of a thread pool based bulkhead in a Spring Sleuth environment.

[markward-schubert]

Thanks for the feedback @RobWin !

My main problem is, that I do not have a clue how to properly implement a SpringSleuthTraceContextPropagator 😃, so how to do the concrete implementation. I hoped you guys might have done this already for some future integration with spring-cloud.

[bmorris591]

Thanks for the response - I saw that discussion.

But I think my feature request is very different - this is about customisations of objects created as part of the Spring Boot integrations in an idiomatic way.

That thread is solely about passing thread local.

This request is not to change the Resilience4j API (although subtle changes may be required - like IoC with the thread pool) but to change the Spring Boot starter to have the ability to modify the created objects.

Happy to have the solution discussed in the other thread - but that only answers part of the question. This enhancement to the Spring Boot integration would still be needed to allow access to the enhancement discussed in the other issue.