Thread Pools Tuning

GridGain creates and maintains a variety of Thread pools that are used for different purposes depending on the API being used. In this article, we list some of the more common internal pools and show how you can create a custom one.

System Pool

The system pool handles all the cache related operations except for SQL and some other types of queries that go to the queries pool. Also, this pool is responsible for processing compute tasks' cancellation operations.

The default pool size is max(8, total number of cores). Use IgniteConfiguration.setSystemThreadPoolSize(…) or a similar API from your programming language to change the pool size.

Queries Pool

The queries pool takes care of all SQL, Scan, and SPI queries being sent and executed across the cluster.

The default pool size is max(8, total number of cores). Use IgniteConfiguration.setQueryThreadPoolSize(…) or a similar API from your programming language to change the pool size.

Public Pool

Public pool is the work-horse of the Compute Grid. All computations are received and processed by this pool.

The default pool size is max(8, total number of cores). Use IgniteConfiguration.setPublicThreadPoolSize(…) or a similar API from your programming language to change the pool size.

Service Pool

Service Grid calls go to the services' thread pool. Having dedicated pools for Ignite Service and Compute Grid components allows us to avoid threads starvation and deadlocks when a service implementation wants to call a computation or vice versa.

The default pool size is max(8, total number of cores). Use IgniteConfiguration.setServiceThreadPoolSize(…) or a similar API from your programming language to change the pool size.

Striped Pool

The striped pool helps accelerate basic cache operations and transactions by spreading operations execution across multiple stripes that don’t contend with each other for resources.

The default pool size is max(8, total number of cores). Use IgniteConfiguration.setStripedPoolSize(…) or a similar API from your programming language to change the pool size.

Data Streamer Pool

The data streamer pool processes all messages and requests coming from IgniteDataStreamer and a variety of streaming adapters that use IgniteDataStreamer internally.

The default pool size is max(8, total number of cores). Use IgniteConfiguration.setDataStreamerThreadPoolSize(…) or a similar API from your programming language to change the pool size.

Creating Custom Thread Pool

It is possible to configure a custom thread pool for Ignite/GridGain compute tasks. This is useful if you want to execute one compute task from another synchronously avoiding deadlocks. To guarantee this, you need to make sure that a nested task is executed in a thread pool separate from the parent’s tasks thread pool.

A custom pool is defined in IgniteConfiguration and must have a unique name:

IgniteConfiguration cfg = ...;

cfg.setExecutorConfiguration(new ExecutorConfiguration("myPool").setSize(16));

<bean id="grid.cfg" class="org.apache.ignite.configuration.IgniteConfiguration">
  ...
  <property name="executorConfiguration">
    <list>
      <bean class="org.apache.ignite.configuration.ExecutorConfiguration">
        <property name="name" value="myPool"/>
        <property name="size" value="16"/>
      </bean>
    </list>
  </property>
  ...
</bean>

Now, let’s assume that an compute task below has to be executed by a Thread from the myPool defined above:

public class InnerRunnable implements IgniteRunnable {
    @Override public void run() {
        System.out.println("Hello from inner runnable!");
    }
}

To do that, you need to use IgniteCompute.withExecutor(), which will execute the task immediately from an implementation of the parent task, as shown below:

public class OuterRunnable implements IgniteRunnable {
    @IgniteInstanceResource
    private Ignite ignite;

    @Override public void run() {
        // Synchronously execute InnerRunnable in custom executor.
        ignite.compute().withExecutor("myPool").run(new InnerRunnable());
    }
}

The parent task’s execution might be triggered the following way and, in this scenario, it will be executed by the public pool:

ignite.compute().run(new OuterRunnable());