ID | IEP-70 |
Author | |
Sponsor | |
Created |
|
Status | DRAFT |
Cache async operations invoke future listeners on Striped pool threads, which can cause deadlocks and/or reduce cache performance.
IgniteFuture fut = cache.putAsync(1, 1); fut.listen(f -> { // Executes on Striped pool and deadlocks. cache.replace(1, 2); });
Users are supposed to be aware of this and handle it manually, however:
The problem is more pronounced in Ignite.NET:
await cache.PutAsync(1, 1); // Now we are on a Striped pool thread! // CPU-heavy method blocks the stripe and cache ops are stalled. RunSomething();
A similar problem exists for Compute. Async operation continuations are executed on the Public pool, which can lead to starvation there when all threads are taken up by continuation logic.
This fixes the issue in Java, .NET and C++, because thick integrations use direct JNI callbacks for Futures.
NOTE: This IEP is NOT related to scan query filters, cache entry processors, etc, which also run on Striped pool.
Those users can force the old behavior with `IgniteConfiguration.setAsyncContinuationExecutor(Runnable::run)`.
IEP thread: http://apache-ignite-developers.2346864.n4.nabble.com/IEP-70-Async-Continuation-Executor-td51775.html
Original discussions:
PoC: https://github.com/apache/ignite/pull/8870