Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
Docs Required, Release Notes Required
Description
Like in Ignite 2.x, we need to have custom classes for threads, with custom properties.
Currently, I can only say that we use custom thread types in network, for event loops I guess. That's not enough, here's why.
Given the wide adoption of async code, developers struggle to understand, what thread executes the actual operation. For example, "thenCompose" or "whenComplete" closure is being executed in whatever thread that completes the future, and quite often it's not the thread that we want.
Also, we shouldn't use default fork-join pool, for example. We should force most operations to our own pools.
To make everything more clear, we have to mark threads with at least following categories:
- can perform storage reads
- can perform storage writes
- can perform network IO operations
- can be safely blocked
- etc.
Once we know for sure that the thread fits the operation, we can execute it. Ideally, that should be an assertion and not a runtime logic.
This will also help us finding existing bugs and bottlenecks.
Attachments
Issue Links
- is related to
-
IGNITE-21144 PartitionReplicaListener should return execution to partition thread pool after calls to PlacementDriver
- Resolved
- relates to
-
IGNITE-17824 Use named executor instead of default one in order to process replica Response
- Resolved
- split to
-
IGNITE-21438 Add thread assertions to MV partition and index storages
- Resolved
-
IGNITE-21439 Enable thread assertions in tests
- Resolved
-
IGNITE-21481 Annotate threads with allowed operations
- Resolved
-
IGNITE-21486 Pass node name to NamedThreadFactory where possible
- Resolved
-
IGNITE-21508 Move storage operations from critical threads
- Resolved
-
IGNITE-21517 Add thread assertions to TxStateStorage
- Resolved