Standalone Mode

The standalone processing unit This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity. container allows you to run a processing unit in standalone mode, which means that the processing unit constructs its own dedicated classloader, and automatically includes it its classpath all of the jar files located under the processing unit's lib directory. It's implementation class is StandaloneProcessingUnitContainer.

The standalone processing unit container is built around Spring's ApplicationContext with several extensions relevant to GigaSpaces, such as ClusterInfo. It contains a main() method and can be started from an external script or programmatically by using the ProcessingUnitContainerProvider abstraction.

It should be used when you would like to run your processing unit in a non-managed environment (outside of the service grid) or from within your own code, and still benefit from the automatic classpath creation as with the managed mode.

Executable StandaloneProcessingUnitContainer

The StandaloneProcessingUnitContainer provides an executable main() method that allows it to be run directly. The main() method uses the StandaloneProcessingUnitContainerProvider and command-line conventions in order to create the StandaloneProcessingUnitContainer. A required parameter is the processing unit location, pointing to the file-system location of the processing unit directory. The following is a list of all the possible command-line parameters available:

The StandaloneProcessingUnitContainer class provides an executable main() method, allowing you to run it directly via a shell script for example. The main() method uses the StandaloneProcessingUnitContainerProvider class and program arguments in order to create the StandaloneProcessingUnitContainer. The following is a list of all the possible program arguments that can be specified to the StandaloneProcessingUnitContainer:

Option	Description
-config [configLocation]	Allows you to set/add a processing unit deployment descriptor location. Follows the Spring Resource Loader including ant style patterns. This parameter can be specified multiple times. The default is classpath*:/META-INF/spring/pu This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity..xml.
-cluster [cluster options]	Allows you to control the ClusterInfo injected into the container and the runtime topology of the processing unit. The following options are available (they are used automatically by any embedded space included in the processing unit): - schema - the cluster schema used by the processing unit. Possible values are sync-replicated, async-replicated and partitioned - total_members - Determines the total members in the emulated cluster. Format is numberOfInstances[,numberOfBackups], e.g. total_members 2,1 The number of backups per partition is zero or one. - id – Mandatory. Determines the id of the processing unit instance the this container will run. - backup_id – If you want the container to run a backup instance, use this parameter in conjunction with the id parameter. It will force the container to run the instance and will determines its backup ID.
-properties [property file location]	Allows you to inject properties to the processing unit at deployment time.
-properties embed://[property1 name]=[property1 value]; [property2 name]=[property2 value]	Allows you to directly inject properties to the processing unit at startup time.

Starting the Standalone Processing Unit Container via the pu-instance Shell Script

GigaSpaces comes with the pu-instance shell script, which uses the StandaloneProcessingUnitContainer in order to run a processing unit directly from the command line.

Here are some examples of using the pu-instance script in order to run a processing unit:

pu-instance.sh -cluster schema=partitioned total_members=2 id=1 data-processor.jar

pu-instance.bat -cluster schema=partitioned total_members=2 id=1 data-processor.jar

The above example starts a processing unit (which includes an embedded space) in a partitioned cluster schema, with two members and id=1. In order to run the full cluster, another pu-instance has to be started with id=2.

pu-instance.sh -cluster schema=partitioned total_members=1,1 id=1 backup_id=1
-properties runtime.properties data-processor.jar

pu-instance.bat -cluster schema=partitioned total_members=1,1 id=1 backup_id=1
-properties runtime.properties data-processor.jar

The above example starts a processing unit instance (with an embedded space) in a partitioned cluster schema, with one primary and one backup. It also uses an external properties file to inject property values at startup time.

Starting a StandaloneProcessingUnitContainer Programmatically

Here is an example of using a ProcessingUnitContainerProvider in order to create a standalone processing unit container programmatically with two partitions:

StandaloneProcessingUnitContainerProvider provider = new StandaloneProcessingUnitContainerProvider("/usr/gigaspaces/data-processor.jar");
// provide cluster information for the specific PU instance
ClusterInfo clusterInfo = new ClusterInfo();
clusterInfo.setSchema("partitioned");
clusterInfo.setNumberOfInstances(2);
clusterInfo.setNumberOfBackups(1);
clusterInfo.setInstanceId(1);
provider.setClusterInfo(clusterInfo);

// set the config location (override the default one - classpath:/META-INF/spring/pu.xml)
provider.addConfigLocation("classpath:/test/my-pu.xml");

// Build the Spring application context and "start" it
ProcessingUnitContainer container = provider.createContainer();

// ...

container.close();

The StandaloneProcessingUnitContainerProvider is constructed with a file-system path to the processing unit jar file. It constructs a new classloader and adds all the jar files in the processing unit's lib directory to it automatically.

Disabling Embedded Lookup Service

The StandaloneProcessingUnitContainer automatically starts an embedded Lookup service. If you intend to use a separate Lookup service you can disable the embedded Lookup service by passing the setting the com.j_spaces.core.container.directory_services.jini_lus.enabled system property to false. This property can also be set within the Space Where GigaSpaces data is stored. It is the logical cache that holds data objects in memory and might also hold them in layered in tiering. Data is hosted from multiple SoRs, consolidated as a unified data model. definition:

<os-core:embedded-space id="space" space-name="mySpace">
    <os-core:properties>
      <props>
        <prop key="com.j_spaces.core.container.directory_services.jini_lus.start-embedded-lus">false</prop>
      </props>
    </os-core:properties>
</os-core:embedded-space>