Deploying your processing unit to the service grid is the preferred way to run your it in your production environment. The service grid provides the following main benefits to the processing unit deployed onto it:
Automatic distribution and provisioning of the processing unit instances: When deploying to the service grid the GigaSpaces Manager identifies the relevant GigaSpaces Containers and takes care of distributing the processing unit binaries to them. So you do not need to manually install the processing unit anywhere on the cluster
SLA enforcement: The GigaSpaces Manager is also responsible for enforcing your processing unit's SLA. At deployment time, it will create the specified number of processing unit instances and provision them to the running containers while enforcing all the deployment requirements, such as memory and CPU utilization, or specific deployment zones. At runtime, it will monitor the processing unit instances, and if one of them fails or becomes unavailable it will re-instantiate automatically on another container.
The Deployment Process
Once built according to the processing unit directory structure, the processing unit can be deployed via the various deployment tools available in GigaSpaces XAP (UI, CLI, Ant, Maven or the Admin API).
After you package the processing unit and deploy it via one of the deployment tools, the deployment tool uploads it to all the running GSMs, where it is extracted and provisioned to the GSCs.
To Jar or Not to Jar The recommended way to deploy the processing unit is by packaging it into a .jar or a .zip archive and specifying the location of the packaged file to the deployment tool in use.
However, GigaSpaces XAP also supports the deployment of exploded processing units. The deployment tool will package the processing unit directories into a jar file automatically). Another option to deploy a processing unit is by placing the exploded processing unit under the deploy directory of each of the GSMs and issuing a deploy command with the processing unit name (the name of the directory under the deploy directory).
Distribution of Processing Unit Binaries to the Running GSCs
By default, when a processing unit instance is provisioned to run on a certain GSC, the GSC downloads the processing unit archive from the GSM into the <GigaSpaces Root>/work/deployed-processing-units directory (The location of this directory can be overridden via the com.gs.work system property).
Downloading the processing unit archive to the GSC is the recommended option, but it can be disabled. In order to disable it, the pu.downloaddeployment property should be set to false. This will not download the entire archive to the GSC, but will force the GSC to load the processing unit classes one at a time from the GSM via a URLClassLoader.
Deploying the Processing Unit Using the Various Deployment Tools
GigaSpaces provides several options to deploy a processing unit onto the Service Grid. Below you can find a simple deployment example with the various deployment tools for deploying a processing unit archive called myPU.jar located in the usr/gigaspaces directory:
Deploying via code is done using the GigaSpaces Admin API. The following example shows how to deploy the myPU.jar processing unit using one of the available GSMs. For more details please consult the documentation and javadoc of the Admin API.
Admin admin = new AdminFactory().addGroup("mygroup").createAdmin();
File puArchive = new File("/opt/gigaspaces/myPU.jar");
ProcessingUnit myPU = admin.getGridServiceManagers().deploy(new ProcessingUnitDeployment(puArchive));
Deploying with Ant is based on the org.openspaces.pu.container.servicegrid.deploy.Deploy class (in fact, all of the deployment tools use this class although it is not exposed directly to the end user).
In the below example we create an Ant macro using this class and use it to deploy our processing unit. The deploy class is executable via its main() method, and can accept various parameters to control the deployment process. These parameters are identical to these of the deploy CLI command, for a complete list of the available parameters please consult the deploy CLI reference documentation..
Deploying via the CLI is based on the deploy command. This command accepts various parameters to control the deployment process. These parameters are documented in full in the deploy CLI reference documentation..
Open the GigaSpaces UI by launching {{<gigaspaces root>/bin/gs-ui.sh(bat)
Click the "Deploy Application" button at the top left of the window
In the deployment wizard, click ... to select your processing unit archive, and then click Deploy
Upgrade a PU with an Embedded Space Without any Downtime
To enable business continuity in a better manner, having system upgrade without any downtime, here is a very simple procedure you should follow when you would like to perform a hot deploy, upgrading a PU that includes both a business logic and a collocated embedded space:
1. Upload the PU new classes (i.e. polling container SpaceDataEvent implementation or relevant listener class and any other dependency classes) to the PU deploy folder on all the GSM machines.
2. Restart the PU instance running the backup space. This will force the PU instance to reload a new version of the business logic classes from the GSM.
3. Wait for the backup PU to fully recover its data from the primary.
4. Restart the Primary PU instance this will turn the existing backup instance to become a primary instance. The previous primary will turn into a backup and load the new business logic classes.
5. If you would like - you can restart the new primary to force it to become a backup instance again. The new primary will also use the new version of the business logic classes.
You can script the above procedure via the Administration and Monitoring API, allowing you to perform system upgrade without downtime.
at the top left of the window