You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 4
Next »
ID | IEP-70 |
Author | |
Sponsor | |
Created | |
Status | DRAFT |
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
key |
summary |
type |
created |
updated |
due |
assignee |
reporter |
priority |
status |
resolution |
JQL and issue key arguments for this macro require at least one Jira application link to be configured
|