The GigaSpaces Agent (GSA) acts as a process manager that can spawn and manage Service Grid processes (Operating System level processes) such as The GigaSpaces Manager, The GigaSpaces Container, and Lookup Service.
Usually, a single GSA is run per machine (on a lookup group or lookup locator level, see more in the Lookup Service). The GSA allows to spawn a GigaSpaces Manager, GigaSpaces Container, Lookup Service, and custom processes. Once spawned, the GSA assigns a unique id for it and manages its lifecycle. The GSA will restart the process if it exits, or if a specific console output has been encountered (for example, OutOfMemoryError).
The GSA exposes the ability to start, restart, and kill a process either using the Administration and Monitoring API or the GigaSpaces UI.
Although The GigaSpaces Manager, The GigaSpaces Container, and The Lookup Service can be started on their own using their respective scripts, it is preferable that they will be started using the GSA thus allowing to easily monitor and manage them.
The GSA manages Operating System processes. There are two types of process management, local and global.
Local processes simply start the process type (for example, a GigaSpaces Container) without taking into account any other process types running by different GSAs.
Global processes take into account the number of process types (GigaSpaces Manager for example) that are currently running by other GSAs (within the same lookup groups or lookup locators). It will automatically try and run at least X number of processes across all the different GSAs (with a maximum of 1 process type per GSA). If a GSA running a process type that is managed globally fails, another GSA will identify the failure and start it in order to maintain at least X number of global process types.
In order to start the GSA, the <GSHOME>/bin/gs-agent.(sh/bat) can be used. The GSA, by default, will start 2 local GigaSpaces Containers, and manage 2 global GigaSpaces Managers and 2 global Lookup Services.
GSA parameters include controlling how many local process the GSA will spawn on startup (per process type), and the number of globally managed process the GSA will maintain (in cooperation with other GSAs) (per process type).
By default, the GSA is started with 2 local GigaSpaces Containers, and manage 2 global GigaSpaces Manager and 2 global Lookup Service. This is the equivalent of starting the GSA with the following parameters:
In order to, for example, start 3 local GSCs, 2 global GSMs, and no global LUS, the following command can be used:
In general, the gsa.[process type] followed by a number controls the number of local processes of the specific process type that will be spawned by the GSA. The gsa.global.[process type] following by a number controls the number of globally managed processes of the specific process type.
GSA manages different process types. Each process type is defined within the <GSHOME>\config\gsa directory in an xml file that identifies the process type by its name.
The following are the process types that come out of the box:
Here is an example of the gsc xml configuration file:
The GSA can either spawn a script based process, or a pure JVM (with its arguments) process. The GSC for example, allows for both types of process spawning.
When starting a Lookup Service and other services in unicast mode (not multicast), it means that specific machines will be the ones that will run the Lookup Service. This means that on the machines running the LUS, the following command will be used (assuming other defaults are used for GSM and GSC):
And machines that will not run the LUS, the following command should be used: