You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Ivan Bessonov (Jira)" <ji...@apache.org> on 2023/02/21 09:29:00 UTC

[jira] [Created] (IGNITE-18853) Introduce thread types to thread pools

Ivan Bessonov created IGNITE-18853:
--------------------------------------

             Summary: 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


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)