gsInstance - GigaSpaces CLI

  GigaSpaces 5.X

Documentation Home
Quick Start Guide
Release Notes

Previous release

  Search Here
Searching GigaSpaces Platform 5.X Documentation

                                               

Summary: how to start a light version of the GigaSpaces server, which loads a space container and one space, using the gsInstance script.

Overview

This section explains how to start a light version of the GigaSpaces server, which loads a container and one space, using the gsInstance script. An embedded reggie and embedded Webster as part of the spaceFinder call can be enabled if needed, inside the gsServer configuration. These can be disabled if needed. It does not start any additional services.

GigaSpaces supports space monitoring and management using JMX – The Java Management Extensions. For more details, refer to the JMX Management section.
When running gsIntance or gsServer, the Jini Lookup Service runs implicitly. When having many Jini Lookup Services running across the network, the spaces and clients might be overloaded since they publish themselves into the Lookup Service, or are trying to get updates about newly registered services.

A good practice is to have two Lookup Services running using the startJiniLUS command located in the <GigaSpaces Root>\bin directory, or the GSM command located in the <GigaSpaces Root>\ServiceGrid\bin folder. This ensures no single point of failure for the Lookup Service.

gsServer vs. gsInstance

The GigaSpaces Server is designed to run the core GigaSpaces Container and space(s) as part of the Jini 2 service starter. It differs from the GigaSpaces Instance – the gsInstance script uses code defined by GigaSpaces, while the gsServer uses code defined by Jini. Moreover, the GigaSpaces Server starts services which are defined in the Jini configuration, while the GigaSpaces Instance starts services which are defined in the GigaSpaces configuration.

For more details on the GigaSpaces Server, refer to the gsServer section.

Syntax & Arguments

The full gsInstance syntax (the arguments passed below are optional):

gsInstance "/./newSpace?schema=persistent" "../../classes" "-DmyOwnSysProp=value -DmyOwnSysProp2=value"

The gsInstance arguments are passed through the command line. These arguments are optional – if you do not want to pass any arguments, you don't have to specify anything in the command line, as seen below:

gsInstance

You can use three arguments. All arguments must be enclosed by quotes (" "). If used, the arguments must be entered in the following order (descending):

Argument Description
Argument 1 Defines a space URL. The value is set into the SPACE_URL variable. If no value is passed for this argument, the space URL defined in the gsInstance script is used.
Argument 2 Defines a path which will be appended to the beginning of the used classpath. The value you define is set into the APPEND_TO_CLASSPATH_ARG variable. If no value is passed, the classpath defined in the gsInstance script is used.
Argument 3 Defines additional command line arguments such as system properties. The value is set into the APPEND_ADDITIONAL_ARG variable.

If you are using the third and/or second argument only, you must use empty quote signs for the argument or arguments that come before the one you are using. For example:

gsInstance "" "" "-DmyOwnSysProp=value -DmyOwnSysProp2=value"

In the example above, only the third argument is used, so two pairs of empty quote signs are written before it. In this case, the default URL and classpath (defined in the gsInstance script) are used, and only the system properties are appended.

The Java command in the gsInstance script starts the JVM that hosts the space. For more details, refer to the Quick Start Guide - Using the Examples (GigaSpaces Environment) - The Server Side.

Wiki Content Tree


Your Feedback Needed!

We need your help to improve this wiki site. If you have any suggestions or corrections, write to us at techw@gigaspaces.com. Please provide a link to the wiki page you are referring to.

Labels

 
(None)