[
https://issues.apache.org/jira/browse/IGNITE-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-18853:
---------------------------------------
Labels: ignite-3 storage-threading threading (was: ignite-3
storage-threading)
> Introduce thread types to thread pools
> --------------------------------------
>
> Key: IGNITE-18853
> URL: https://issues.apache.org/jira/browse/IGNITE-18853
> Project: Ignite
> Issue Type: Improvement
> Reporter: Ivan Bessonov
> Priority: Major
> Labels: ignite-3, storage-threading, threading
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
