[Feature] Add tracing support for ThreadPoolExecutor.invokeAll and invokeAny in the JDK thread pool plugin

[xuzhiguang]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Description

Add tracing support for ThreadPoolExecutor.invokeAll and ThreadPoolExecutor.invokeAny in the JDK thread pool plugin.

The plugin currently propagates tracing context for tasks submitted through ThreadPoolExecutor.execute and ThreadPoolExecutor.submit, but the following inherited batch task submission methods are not covered:

<T> List<Future<T>> invokeAll(
    Collection<? extends Callable<T>> tasks
)

<T> List<Future<T>> invokeAll(
    Collection<? extends Callable<T>> tasks,
    long timeout,
    TimeUnit unit
)

<T> T invokeAny(
    Collection<? extends Callable<T>> tasks
)

<T> T invokeAny(
    Collection<? extends Callable<T>> tasks,
    long timeout,
    TimeUnit unit
)

ThreadPoolExecutor inherits these methods from AbstractExecutorService.

Internally, invokeAll and invokeAny convert or wrap the original Callable tasks as RunnableFuture-based tasks before passing them to execute. The current execute interceptor skips RunnableFuture instances, while the original Callable tasks have not captured the active tracing context.

As a result, tasks executed through ThreadPoolExecutor.invokeAll or ThreadPoolExecutor.invokeAny do not continue the caller's trace and have no CrossThread reference to the parent trace segment.

Supporting these methods would make tracing context propagation consistent across the individual and batch task submission APIs of ThreadPoolExecutor.

Use case

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    2,
    2,
    0L,
    TimeUnit.MILLISECONDS,
    new LinkedBlockingQueue<Runnable>()
);

List<Callable<String>> tasks = Arrays.asList(
    () -> callDownstreamService("task-1"),
    () -> callDownstreamService("task-2")
);

List<Future<String>> results = executor.invokeAll(tasks);

String firstResult = executor.invokeAny(tasks);

When these methods are called within an active SkyWalking trace, every Callable that starts execution should continue the caller's tracing context. Downstream HTTP, database, or RPC operations should be connected to the same trace through CrossThread references.

Currently, work submitted through ThreadPoolExecutor.invokeAll and ThreadPoolExecutor.invokeAny may appear as disconnected traces or may be missing from the parent trace.

The expected behavior is:

1. Support both overloads of ThreadPoolExecutor.invokeAll.
2. Support both overloads of ThreadPoolExecutor.invokeAny.
3. Each Callable that starts execution continues the active tracing context.
4. Each worker-thread trace segment contains a CrossThread reference to the caller.
5. Existing timeout, cancellation, exception, and result-returning semantics remain unchanged.
6. Existing behavior for execute, submit, and already wrapped tasks remains unchanged.
7. Plugin scenario tests verify tracing context propagation for all four overloads.

I implemented a local prototype for ThreadPoolExecutor.invokeAll to validate the feasibility of this feature.

After adding tracing context propagation, the Callable tasks submitted through invokeAll are connected to the caller's trace through CrossThread references, as shown below:

Related issues

No response

Are you willing to submit a pull request to implement this on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct

[prashanth9968]

Hi! I am a Java developer and I would love to work on this feature. I have a good understanding of Java concurrency, ThreadPoolExecutor, and handling batches of Callable tasks. Since no one is currently assigned, could you please assign this issue to me? I will explore the JDK thread pool plugin structure and raise a pull request.

[wu-sheng]

@xuzhiguang Are you working on this?

[wu-sheng]

Your analysis is correct, and the direction is right. I verified it against the code:

• The plugin only intercepts execute and submit (ThreadPoolExecutorInstrumentation).
• invokeAll calls newTaskFor(task) → execute(FutureTask), and invokeAny goes through ExecutorCompletionService.submit → execute(QueueingFuture). Both are RunnableFutures.
• ThreadPoolExecuteMethodInterceptor skips RunnableFuture by design (it has to, because submit() itself routes through execute(ftask)), so the original Callables are never wrapped.

So the gap is exactly as you described. Please go ahead with the implementation on ThreadPoolExecutor in the jdk-threadpool-plugin — no need to touch AbstractExecutorService, inherited methods are matched fine by the existing instrumentation.

Two constraints to add to your expected-behavior list:

1. Do not mutate the caller's collection — build a new list. Callers commonly pass Arrays.asList(...) or Collections.unmodifiableList(...), and may reuse the collection across calls (as in your own example).
2. Preserve iteration order — invokeAll's contract requires the returned List<Future> to be in the same sequential order as the task collection's iterator.

Two suggestions:

• Keep the per-element already-wrapped guard you mention in item 6. enhanceClass() uses a hierarchy match, so a ThreadPoolExecutor subclass gets its own generated override and the interceptor can fire twice on the same call chain.
• Capture the ContextSnapshot once per call and share it across all wrappers, rather than once per task. ContextSnapshot clones the correlation/extension/profile contexts on construction, and continued() only reads from it — so sharing is safe and avoids N clones for a large batch.

For tests, please extend the existing jdk-threadpool-scenario rather than adding a new one, covering all four overloads.

@prashanth9968 Thanks for the interest — @xuzhiguang already has a working prototype for this one, so I'm leaving it with him. Please look through the other open feature/good first issue items.

[xuzhiguang]

@wu-sheng Thanks for the detailed review and guidance. Yes, I’m working on this.

Our internal implementation already covers both invokeAll overloads and has been deployed in production, with tracing context propagated to the submitted Callable tasks.

I’ll extend the implementation to cover both invokeAny overloads and incorporate your suggestions before submitting the pull request.