Motivation

Cache and Compute async operations invoke the future listeners on Ignite thread pools, such as Public pool and Striped pool:

IgniteFuture fut = cache.putAsync(1, 1);
fut.listen(f -> {
    // Executes on Striped pool and causes a deadlock
    cache.replace(1, 2);
});

Users are supposed to be aware of this and handle it manually, however:

• This behavior is unexpected
• Users should carefully read the docs to know about this
• Handling this manually is verbose and error-prone

The problem is more pronounced in Ignite.NET:

• async/await exists for a long time and most code bases are async
• async/await sugar somewhat makes this less obvious
• custom thread pools are less common

await cache.PutAsync(1, 1);
// Now we are on a Striped pool!

// CPU-heavy method blocks the stripe and cache ops are stalled
RunSomething();

Description

• Add IgniteConfiguration#asyncContinuationExecutor (of type Executor).
• Use ForkJoinPool#commonPool by default (when null / not set).
• Use this executor for all Cache and Compute async continuations

NOTE: This IEP is NOT related to scan query filters, cache entry processors, etc, which also run on Striped pool.

Risks and Assumptions

• Some users may already have custom code to deal with the problem.
• Some users run simple continuations that work fine on the striped/public pool.

Those users can force the old behavior with `IgniteConfiguration.setAsyncContinuationExecutor(Runnable::run)`.

Discussion Links

// Links to discussions on the devlist, if applicable.

Reference Links

PoC: https://github.com/apache/ignite/pull/8870

Tickets