Summary: A registry of services (GSM, GSC, Space Instances, Processing Unit Instances) that can be lookup up using it.

Overview

The Lookup Service (LUS) provides a leased based registry holding Service Grid level services advertised on it. Some of the services exposed on the LUS are GigaSpaces Agent, GigaSpaces Manager, GigaSpaces Container, Space Instances (actual instances of a Space that form a topology), and Processing Unit Instances (actual instances of a deployed Processing Unit).

A Lookup Service creates a virtualized isolated environment by utilizing lookup groups (when using multicast) or lookup locators (when using unicast). When starting the LUS and other runtime components GigaSpaces Agent, GigaSpaces Manager and GigaSpaces Container, the lookup groups / lookup locators can be set in order to form an isolated environment.

In a multicast enabled environment, the lookup groups can be set using either the LOOKUPGROUPS environment variable (when using scripts), or by setting -Dcom.gs.jini_lus.groups system property.

In a unicast environment (where multicast is disabled), the lookup locators can be set using either LOOKUPLOCATORS environment variable (when using scripts), or by setting -Dcom.gs.jini_lus.locators system property. In a unicast environment, the LUS are started on specific machines (usually two LUS instances), and the lookup locators simply point to the two hosts the LUS instances are running on.

When a GigaSpaces Container is started with a specific lookup groups / lookup locators, any Processing Unit instance running within it (and Space instances as well) will inherit the configuration and join the virtualized LUS environment.

Starting the LUS

The preferable way to start a LUS is using the GigaSpaces Agent. A LUS can be started on its own using the [GSHOME]/bin/startJiniLUS.(bat/sh) script. Also note that by default, when using the [GSHOME]/bin/gsm.(bat/sh) script, a LUS is started embedded with the GSM.

Configuring the LUS

Configuring the LUS (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 LUS JVM parameters can be easily passed using LUS_JAVA_OPTIONS that will be appended to EXT_JAVA_OPTIONS. If LUS_JAVA_OPTIONS is not defined, the system will behave as in 7.1.0. Both EXT_JAVA_OPTIONS and LUS_JAVA_OPTIONS can be added within the LUS script, or in a wrapper script.

Linux
#Wrapper Script
export LUS_JAVA_OPTIONS=-Xmx1024m

#call startJiniLUS.sh
. ./startJiniLUS.sh

Windows
@rem Wrapper Script
@set LUS_JAVA_OPTIONS=-Xmx1024m

@rem call startJiniLUS.bat
call startJiniLUS.bat

LUS 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.

GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence