Your application server has its own threads. Hazelcast does not use these; it manages its own threads.
Hazelcast uses a pool of threads for I/O. A single thread does not perform all the I/O. Instead, multiple threads perform the I/O. On each cluster member, the I/O threading is split up in 3 types of I/O threads:
I/O thread for the accept requests
I/O threads to read data from other members/clients
I/O threads to write data to other members/clients
You can configure the number of I/O threads using the
hazelcast.io.thread.count system property.
Its default value is 3 per member. If 3 is used, in total there are 7 I/O threads:
1 accept I/O thread, 3 read I/O threads and 3 write I/O threads. Each I/O thread has
its own Selector instance and waits on the
Selector.select if there is nothing to do.
You can also specify counts for input and output threads separately.
hazelcast.io.output.thread.count properties for this purpose.
See the System Properties appendix for information about these properties and how to set them.
Hazelcast periodically scans utilization of each I/O thread and
can decide to migrate a connection to a new thread if
the existing thread is servicing a disproportionate number of I/O events.
You can customize the scanning interval by configuring the
hazelcast.io.balancer.interval.seconds system property;
its default interval is 20 seconds. You can disable the balancing process by setting this property to a negative value.
In case of the read I/O thread, when sufficient bytes for a packet have been received, the
Packet object is created. This
Packet object is
then sent to the system where it is de-multiplexed. If the
Packet header signals that it is an operation/response, the
Packet is handed
over to the operation service (see the Operation Threading section). If the
Packet is an event, it is handed
over to the event service (see the Event Threading section).
Hazelcast uses a shared event system to deal with components that rely on events, such as topic, collections, listeners and Near Cache.
Each cluster member has an array of event threads and each thread has its own work queue. When an event is produced, either locally or remotely, an event thread is selected (depending on if there is a message ordering) and the event is placed in the work queue for that event thread.
You can set the following properties to alter the system’s behavior:
hazelcast.event.thread.count: Number of event-threads in this array. Its default value is 5.
hazelcast.event.queue.capacity: Capacity of the work queue. Its default value is 1000000.
hazelcast.event.queue.timeout.millis: Timeout for placing an item on the work queue in milliseconds. Its default value is 250 milliseconds.
If you process a lot of events and have many cores, changing the value of
hazelcast.event.thread.count property to
a higher value is a good practice. This way, more events can be processed in parallel.
Multiple components share the same event queues. If there are 2 topics, say A and B, for certain messages they may share the same queue(s) and hence the same event thread. If there are a lot of pending messages produced by A, then B needs to wait. Also, when processing a message from A takes a lot of time and the event thread is used for that, B suffers from this. That is why it is better to offload processing to a dedicated thread (pool) so that systems are better isolated.
If the events are produced at a higher rate than they are consumed, the queue grows in size. To prevent overloading the system
and running into an
OutOfMemoryException, the queue is given a capacity of 1 million items. When the maximum capacity is reached, the items are
dropped. This means that the event system is a 'best effort' system. There is no guarantee that you are going to get an
event. Topic A might have a lot of pending messages and therefore B cannot receive messages because the queue
has no capacity and messages for B are dropped.
Executor threading is straight forward. When a task is received to be executed on Executor E, then E will have its
ThreadPoolExecutor instance and the work is placed in the work queue of this executor.
Thus, Executors are fully isolated, but still share the same underlying hardware - most importantly the CPUs.
You can configure the IExecutor using the
ExecutorConfig (programmatic configuration) or
<executor> (declarative configuration). See also the Configuring Executor Service section.
The following are the operation types:
operations that are aware of a certain partition, e.g.,
operations that are not partition aware, e.g.,
Each of these operation types has a different threading model explained in the following sections.
To execute partition-aware operations, an array of operation threads is created.
The default value of this array’s size is the number of cores and it has a minimum value of 2.
This value can be changed using the
Each operation thread has its own work queue and it consumes messages from this work queue. If a partition-aware operation needs to be scheduled, the right thread is found using the formula below.
threadIndex = partitionId % partition thread-count
threadIndex is determined, the operation is put in the work queue of that operation thread. This means the followings:
A single operation thread executes operations for multiple partitions; if there are 271 partitions and 10 partition threads, then roughly every operation thread executes operations for 27 partitions.
Each partition belongs to only 1 operation thread. All operations for a partition are always handled by exactly the same operation thread.
Concurrency control is not needed to deal with partition-aware operations because once a partition-aware operation is put in the work queue of a partition-aware operation thread, only 1 thread is able to touch that partition.
Because of this threading strategy, there are two forms of false sharing you need to be aware of:
False sharing of the partition - two completely independent data structures share the same partition. For example, if there is a map
employeesand a map
orders, the method
employees.get("peter")running on partition 25 may be blocked by the method
orders.get(1234)also running on partition 25. If independent data structures share the same partition, a slow operation on one data structure can slow down the other data structures.
False sharing of the partition-aware operation thread - each operation thread is responsible for executing operations on a number of partitions. For example, thread 1 could be responsible for partitions 0, 10, 20, etc. and thread-2 could be responsible for partitions 1, 11, 21, etc. If an operation for partition 1 takes a lot of time, it blocks the execution of an operation for partition 11 because both of them are mapped to the same operation thread.
You need to be careful with long running operations because you could starve operations of a thread.
As a general rule, the partition thread should be released as soon as possible because operations are not designed
as long running operations. That is why, for example, it is very dangerous to execute a long running operation
AtomicReference.alter() or an
IMap.executeOnKey(), because these operations block other operations to be executed.
Currently, there is no support for work stealing. Different partitions that map to the same thread may need to wait till one of the partitions is finished, even though there are other free partition-aware operation threads available.
Take a cluster with three members. Two members have 90 primary partitions and one member has 91 primary partitions. Let’s say you have one CPU and four cores per CPU. By default, four operation threads will be allocated to serve 90 or 91 partitions.
To execute operations that are not partition-aware, e.g.,
IExecutorService.executeOnMember(command, member), generic operation
threads are used. When the Hazelcast instance is started, an array of operation threads is created. The size of this array
has a default value of the number of cores divided by two with a minimum value of 2. It can be changed using the
A non-partition-aware operation thread does not execute an operation for a specific partition. Only partition-aware operation threads execute partition-aware operations.
Unlike the partition-aware operation threads, all the generic operation threads share the same work queue:
If a non-partition-aware operation needs to be executed, it is placed in that work queue and any generic operation thread can execute it. The big advantage is that you automatically have work balancing since any generic operation thread is allowed to pick up work from this queue.
The disadvantage is that this shared queue can be a point of contention. You may not see this contention in production since performance is dominated by I/O and the system does not run many non-partition-aware operations.
In some cases, the system needs to run operations with a higher priority, e.g., an important system operation. To support priority operations, Hazelcast has the following features:
For partition-aware operations: Each partition thread has its own work queue and it also has a priority work queue. The partition thread always checks the priority queue before it processes work from its normal work queue.
For non-partition-aware operations: Next to the
genericWorkQueue, there is also a
genericPriorityWorkQueue. When a priority operation needs to be run, it is put in the
genericPriorityWorkQueue. Like the partition-aware operation threads, a generic operation thread first checks the
Since a worker thread blocks on the normal work queue (either partition specific or generic), a priority operation may not be picked up because it is not put in the queue where it is blocking. Hazelcast always sends a 'kick the worker' operation that only triggers the worker to wake up and check the priority queue.
When an Operation is invoked, a
Future is returned. See the example code below.
GetOperation operation = new GetOperation( mapName, key );
Future future = operationService.invoke( operation );
The calling side blocks for a reply. In this case,
GetOperation is set in the work queue for the partition of
it eventually is executed. Upon execution, a response is returned and placed on the
genericWorkQueue where it is executed by a
"generic operation thread". This thread signals the
future and notifies the blocked thread that a response is available.
Hazelcast has a plan of exposing this
future to the outside world, and we will provide the ability to register a completion listener so you can perform asynchronous calls.
When a local partition-aware call is done, an operation is made and handed over to the work queue of the correct partition operation thread,
future is returned. When the calling thread calls
get on that
future, it acquires a lock and waits for the result
to become available. When a response is calculated, the
future is looked up and the waiting thread is notified.
In the future, this will be optimized to reduce the amount of expensive systems calls, such as
notify() and the expensive
interaction with the operation-queue. Probably, we will add support for a caller-runs mode, so that an operation is directly run on
the calling thread.