Overview

GigaSpaces internal architecture is based on the concept of a working group. A working group consists of a pool of worker threads and a thread-safe request queue. The worker threads listen to requests on the queue, and each request is handled by one thread.

The thread pool itself is dynamic in the following ways:

• Threads can be created dynamically when the system load increases. This increases the level of concurrency.
• Threads can be destroyed dynamically when the system load decreases. This frees expensive system resources.
• Moreover, a minimum and maximum number of threads can be determined for the thread pool on a working group basis. This allows the system to be tuned to application-specific requirements.

Here are the different GigaSpaces components using a thread pool:

The GigaSpaces engine handles the following requests:

• Remote connection requests – LRMI uses a working group to handle incoming remote connections. A dedicated working group is assigned to handle this processing. LRMI is used both at the space side and at the client side when receiving notifications.

  For details on how to control the LRMI working group, refer to the Communication Protocol section.

• Time based requests – take and read with a timeout, notification sequence generation. A dedicated working group is assigned to handle this processing. Write, take, and read without a timeout are processed immediately using the user's thread.
• Notifications requests – dispatching events to registered clients. A dedicated working group is assigned to handle this processing.
• Replication requests – synchronous replication performed in parallel. Each client space operation is replicated to the replica space using a dedicated thread taken from a thread pool. A dedicated working group is assigned to handle this processing.

  For details on how to control the replication working group, refer to the Replication Schema section.

• Database access requests – the JDBC SA uses a database connection pool when accessing the database.

  For details on how to control the databases connection pool, refer to the <init_sa_connections> and the <max_sa_connections> elements in the Persistent Space Schema section.

The GigaSpaces Service Grid handles the following requests:

• GSC SLAThresholdTaskPool – a thread pool for processing SLAThresholdEvents.
• GSM ProvisionMonitorEventPool – a thread pool for sending ProvisionMonitorEvent notifications. Used as part of the ProvisionMonitor.
• GSM ProvisionPool – a thread pool for provision processing.
• GSM ProvisionFailurePool – a thread pool for provision failure notifications.

All of the Service Grid thread pools are configurable using Jini configuration and overrides.

The GigaSpaces client includes the following working groups, handling the following requests:

• Parallel operations requests – used at the client side when performing read from multiple partitions in broadcast mode. Minimum size – 4 , maximum size – 64. A dedicated working group is assigned to handle this processing.
• Local Cache command events processing requests – used at the client side when processing incoming remote events (The command objects). A dedicated working group is assigned to handle this processing. Minimum size – 4 , maximum size – 64.

Controlling Time-Based Requests Working Group

The min_threads/max_threads control a thread pool that handles the take/read with timeout and the notify event sequence generator used later at the client side when enabling FIFO-based notifications.

<space-config>
   <engine>
      <min_threads>4</min_threads>
      <max_threads>64</max_threads>
      <!--if true, give engine threads higher priority-->
      <threads_higher_priority>false</threads_higher_priority>
    </engine>
</space-config>

min_threads=1/max_threads=1 does not mean there is one thread handling read/take/write operations. These are handled by the caller thread. Therefore, there is no difference in performance when having a multi-threaded client.

Controlling Notifications Requests Working Group

The notify_min_threads/notify_max_threads control a thread pool that handles the event dispatching.

<space-config>
   <engine>
      <notify_min_threads>4</notify_min_threads>
      <notify_max_threads>64</notify_max_threads>
    </engine>
</space-config>