This is an automated email from the ASF dual-hosted git repository.
apolovtsev pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/ignite-3.git
The following commit(s) were added to refs/heads/main by this push:
new e9f51a3343 IGNITE-21273 Document newly-added thread pools in README
files (#3055)
e9f51a3343 is described below
commit e9f51a33432b674ede3cc229dfdbe46fa93a8d31
Author: Roman Puchkovskiy <[email protected]>
AuthorDate: Thu Jan 18 17:43:57 2024 +0400
IGNITE-21273 Document newly-added thread pools in README files (#3055)
---
modules/network/README.md | 18 +++++++++++++++++-
modules/runner/README.md | 2 +-
modules/runner/threading.md | 6 ++++++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/modules/network/README.md b/modules/network/README.md
index d189153aaa..f769eec632 100644
--- a/modules/network/README.md
+++ b/modules/network/README.md
@@ -1,7 +1,17 @@
This module provides implementations for the Network API module.
## Brief overview
-Ignite uses ScaleCube to form a network cluster and exchange messages.
+Ignite uses ScaleCube to form a network cluster. Ignite uses channels opened
via Netty to exchange messages between
+nodes. ScaleCube also sends its messages over this transport.
+
+## Channel types
+A couple of nodes might have a channel per each channel type. Each of these
channels is only used to exchange messages
+using the given channel type. There a few standard channel types:
+
+ * Default (used by default when channel type is not specified), id=0
+ * Scalecube (used by all ScaleCube messages), id=1
+ * Deploy (used to send deployment artifacts that might be quite heavy), id=2
+ * Files (used to exchange files), id=3
## Message serialization
Ignite uses direct marshalling to serialize and deserialize messages.
@@ -38,6 +48,12 @@ Message handling can also be offloaded to another thread:
Note that in this case the network message would be considered **handled**
before it is processed
by another thread.
+The default `MessagingService` implementation handles incoming messages in the
inbound thread pool, threads are named
+`{consistentId}-MessagingService-inbound-X-Y` (one per channel type), where X
stands per channel ID. Deserialization of the
+incoming messages happens in these threads as well.
+
+It also uses an outbound thread `{consistentId}-MessagingService-outbound-X`
for sending messages (message serialization also happens in this thread).
+
ScaleCube uses `sc-cluster-X` (where X is an address of the node, e.g.
`localhost-3344`) scheduler for the failure
detector, gossip protocol, metadata store and the membership protocol.
diff --git a/modules/runner/README.md b/modules/runner/README.md
index 150807788a..aa80851923 100644
--- a/modules/runner/README.md
+++ b/modules/runner/README.md
@@ -2,7 +2,7 @@
This document describes user-level and component-level cluster lifecycles and
their mutual interaction.
## Node lifecycle
-A node maintains its' local state in the local persistent key-value storage
named vault. The data stored in the vault is
+A node maintains its local state in the local persistent key-value storage
named vault. The data stored in the vault is
semantically divided in the following categories:
* User-level local configuration properties (such as memory limits, network
timeouts, etc). User-level configuration
properties can be written both at runtime (not all properties will be applied
at runtime, however, - some of them will
diff --git a/modules/runner/threading.md b/modules/runner/threading.md
new file mode 100644
index 0000000000..32af18a311
--- /dev/null
+++ b/modules/runner/threading.md
@@ -0,0 +1,6 @@
+## Threading
+
+The following global thread pools are defined:
+
+* `{consistentId}-partition-operations-X` executes operations that are part of
transactions (including those that make I/O
+ or potentially block on locks). All operations related to the same partition
get executed on the same thread in this pool.
