Summary: Manages Processing Unit deployments and GigaSpaces Containers
OverviewThe Grid Service Manager (GSM), is a special infrastructure service, responsible for managing The Grid Service Containers. The GSM accepts user deployment and undeployment requests of Processing Units, and provisions them to the Service Grid Cloud accordingly. The GSM monitors SLA breach events throughout the life-cycle of the application, and is responsible for taking corrective actions, once SLAs are breached.
Processing Unit MonitoringGSMs monitor the Processing Unit instances running within each GSC. For each Processing Unit instance, a fault detection mechanism is maintained - pinging periodically. Starting the GSMThe preferable way to start a GSM is using The Grid Service Agent. A GSM can be started on its own using the [GSHOME]/bin/gsm.(bat/sh) script (starts a GSM with embedded Lookup Service), or using the [GSHOME]/bin/gsm_nolus.(bat/sh) script (starts a GSM without embedded Lookup Service). Configuring the GSMConfiguring the GSM (and possibly system level settings for other services, such as the communication layer) can be done using system properties. JVM parameters (system properties, heap settings etc.) that are shared between all components are best set using the EXT_JAVA_OPTIONS environment variable. However, starting from 7.1.1, specific GSC JVM parameters can be easily passed using GSM_JAVA_OPTIONS that will be appended to EXT_JAVA_OPTIONS. If GSM_JAVA_OPTIONS is not defined, the system will behave as in 7.1.0. Both EXT_JAVA_OPTIONS and GSM_JAVA_OPTIONS can be added within the GSM script, or in a wrapper script.
Linux
#Wrapper Script export GSM_JAVA_OPTIONS=-Xmx1024m #call gsm.sh . ./gsm.sh Windows @rem Wrapper Script @set GSM_JAVA_OPTIONS=-Xmx1024m @rem call gsm.bat call gsm.bat
|
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |