Overview

A GigaSpaces Container (GSC) is a container which hosts Processing Unit Instances (actual instances of a deployed Processing Unit). The GSC can be perceived as a node on the grid, which is controlled by The GigaSpaces Manager. The GSM provides commands of deployment and undeployment of the Processing Unit instances into the GSC. The GSC reports its status to the GSM.

Another aspect of a GSC is its ability to host Processing Units. The GSC classloading hierarchy makes sure that various Processing Units are isolated from one another within the same GSC.

It is common to start several GSCs on the same physical machine, depending on the machine CPU and memory resources.

The deployment of multiple GSCs on a single or multiple machines creates a virtual Service Grid. The fact is that GSCs are providing a layer of abstraction on top of the physical layer of machines. This concept enables deployment of clusters on various deployment topologies of enterprise data centers and public clouds.

Starting the GSC

The preferable way to start a GSC is using The GigaSpaces Agent. A GSC can be started on its own using the [GSHOME]/bin/gsc.(bat/sh) script.

Configuring the GSC

Configuring the GSC (and possibly system level settings for other services, such as the communication layer) can be done using system properties.

System properties are best set using the EXT_JAVA_OPTIONS environment variable. It can be added within the GSC script, or in a wrapper script.

GSC specific configuration used to be done using the services.config configuration file. In this version, the services.config no longer exists, and its settings can be set using system properties (follows the [component name].[property name] notation). If the services.config is still needed to be used, the installation comes with services.config.template file, which can be renamed back to services.config. By renaming it, it will be taken into account.