Summary: Configuration options in the container schema, including security, port, directory services, JNDI, Jini Lookup, JMS, and logging.


Overview

A container instance can be created using a container schema file to be used as a template configuration file for the container creation. You can use one of the pre-configured schema names when running the space.

The container schema file is now replaced if the <container name>-config.xml file has been used in previous releases.

GigaSpaces includes a default container configuration file (default-container-schema.xml) file that is suitable for most scenarios.
If no <container-name>-config.xml exists in the disk, a container schema will be used.
In general, if a specific space is launched then the same schema name is used for the space is used also for the container schema.
For example:
SpaceFinder.find("/./mySpace");

Creates a single space named mySpace as part of a container named mySpace_container, using the default schema files (default-space-schema.xml and default-container-schema.xml files). Adding the property ?schema=XXX :
SpaceFinder.find("/./mySpace?schema=XXX ");

will override the default and cause the space/container to use the specified XXX schema xml files.
For details about the GigaSpaces logging system using java.util.logging, refer to the GigaSpaces Logging section.

Schema Name

The container schema xml file includes the container schema name using the following tag:

<com>
  <j_spaces>
       <core>
              <container>
                <name>default</name>
              </container>
       </core>
  </j_spaces>
</com>

Security

The space container schema provides basic security capabilities that control whether users have FULL-CONTROL or READ-ONLY access:

Access control Description
READ-ONLY Blocks all users from performing destructive operations: creating a space, shutting down a container, destroying a space, restarting a space.
FULL-CONTROL All users may perform all types of operations on the container.

<com>
  <j_spaces>
       <core>
              <container>
                    <!-- Security Mode: FULL_CONTROL / READ_ONLY -->
                    <security>FULL_CONTROL</security>
                    <admin-password>yPoDwIychjk=</admin-password>
                    <admin-name>gsadmin</admin-name>
              </container>
       </core>
  </j_spaces>
</com>

Element XPath Property Description Default value
<security> com.j_spaces.core.container.security Optional values: FULL_CONTROL, READ_ONLY FULL_CONTROL
<admin-password> com.j_spaces.core.container.admin-password The admnistrator password gsadmin
<admin-name> com.j_spaces.core.container.admin-name The administrator user name gsadmin

For details on how to modify the container administrator user name and password please refer to the Space Container administrator CLI .

Connection Port

The container can be accessed from remote applications. This allows remote application to control the container, get information about its spaces, restart spaces, remove spaces or create new spaces remotely.

<com>
  <j_spaces>
       <core>
              <container>
                    <!-- The port used by the container to export its stub -->
                    <connection>
                     <tcp-port>0</tcp-port>
                    </connection>
              </container>
       </core>
  </j_spaces>
</com>

The <tcp-port> value used to control the port to be used to access the container directly. A 0 value means that an arbitrary free port will be used.

Shutdown Hook

<com>
  <j_spaces>
       <core>
              <container>
                    <!-- The container shutdown in response to a user interrupt,
                    or a system-wide event such as user logoff or system shutdown. Default value: true  -->
<shutdown_hook>${com.gs.shutdown_hook}</shutdown_hook>
              </container>
       </core>
  </j_spaces>
</com>

The <shutdown_hook> is a Boolean value. Setting this value to true will invoke container shutdown procedure when the user closes the container processes using CTRL + C , system shut down or similar OS event.

Directory Services

The container manages the directory services registration. These are used to publish the container and the spaces it manage into directory services to be accessible by remote applications. The space container support registration into JNDI and the Jini Lookup service.

The <directory_services> element determines where space instances are registered. It may have one of three values:

  • The JNDI service
  • The Jini lookup Service
  • Both of the above (the default setting)
    If both are enabled, then the container and its contained space proxies are registered to both.

JNDI

The following instruct the container to register into the JNDI directory service:

<com>
  <j_spaces>
       <core>
              <container>
                    <directory_services>
                           <!-- jndi is based on rmiregistry -->
                           <!-- default lookup service is based on reggie -->
                           <jndi>
                            <!-- true if enabled, false otherwise -->
                                  <enabled>true</enabled>
                                  <!-- Default value: localhost:10098 -->
                                  <url>${com.gs.jndi.url}</url>
                           </jndi>
                    </directory_services>
              </container>
       </core>
  </j_spaces>
</com>

The <url> tag should include the URL to register into. The default value set using the com.gs.jndi.url is localhost:10098. When starting a space using the following format:
SpaceFinder.find("/./mySpace");

The space starts RMI registry embedded and registers into it. This allows remote application to access it via the following URL:
SpaceFinder.find("rmi://hostname/./mySpace");

Or:
SpaceFinder.find("rmi://hostname:10098/./mySpace");

Jini Lookup

The Jini Lookup service allows application to search for running services using multicast (as well as unicast) protocols. It includes several advanced options that you can't find as part of the RMI registry. See more about the Jini lookup service at the Jini Services section.

<com>
  <j_spaces>
       <core>
              <container>
                    <directory_services>
                           <jini_lus>
                                  <enabled>true</enabled>
                                  <!-- If true, will start an embedded LUS and join/register the space into a LUS. Default value: true -->
                                          <start-embedded-lus>${com.gs.start-embedded-lus}</start-embedded-lus>
                                  <!--
                                  Comma separated list of groups for lookup service
                                         Special groups:
                                         all  = discover all groups
                                         none = don't register to any group

                                         For example: myGroup,group1,group2,group3
                                  -->
                                  <groups>${com.gs.jini_lus.groups}</groups>
                                  <!--
                                     Use this option in case multicast discovery is not working properly
                                     in any case multicast discovery will not be disabled.
                               -->
                                  <unicast_discovery>
                                         <!-- Default value: false -->

<enabled>${com.gs.jini_lus.unicast_discovery.enabled}</enabled>
<lus_host>${java.rmi.server.hostname}</lus_host>
                                  </unicast_discovery>
                                  </jini_lus>
</directory_services>
              </container>
       </core>
  </j_spaces>
</com>

Tag Description Default value
<enabled> Boolean value.
Setting this value to true allows the container to register itself and the spaces it controls into the Jini Lookup Service.
Disabling this element causes the space not to be registered in a running Jini Lookup Service. As a result, clusters which use a failover policy like partitioned-sync2backup-cluster-schema.xsl, do not function. For more details, please refer to the Active Election and Avoiding Split-Brain Scenarios section.

true
<start-embedded-lus> Boolean value.
Setting this value to true instructs the container to start a Jini Lookup Service embedded within the container process. For details how to configure the Jini Lookup Service see the Jini Services section.
If you start a large cluster, make sure you disable this property in most of the spaces, since you should not have more than 2-3 instances of the Jini Lookup Service.

false - When deploying a space into a GSC.
true - When starting a space in a stand alone mode (i.e. gsInstance) or in a programmatic manner.
<groups> This tag used to list the Jini groups the container and its spaces will be registered with. To register into list of groups specify comma separated group names: myGroup,group1,group2,group3 Special groups: all = discover all groups, none = don't register to any group group.
Can be overridden using -Dcom.gs.jini_lus.groups
 
<unicast_discovery> This tag allows the container to discover the Jini Lookup Service using unicast.  
<unicast_discovery><enabled> Boolean value.
If the field is set to true, unicast discovery will locate the Lookup Service. This can be useful whenever there are problems with multicast discovery. Multicast discovery is enabled in any case.
false
<lus_host> Comma separated list of hosts to search the Jini Lookup Service. Example: host1:port1, host2:port2, host3:port3. Override using -Dcom.gs.jini_lus.locators localhost:4162

JMS Services

The Container JMS properties:

<com>
  <j_spaces>
       <core>
              <container>
<directory_services>
       <!-- JMS Services: if true, the JMS API supported by GS.
       The JMS Administrated Objects, such as ConnectionFactories, Destinations etc.
       must be bonded into a jndi registry. GS JMS is bonded by default in the internal
       jndi rmi registry. It is possible to use and external jndi registry, such as JBoss
       jndi reg implementation, in order to use it, the external jndi should be enabled.
       -->
        <jms_services>
         <!-- if true, we enable GS jms support -->
         <enabled>false</enabled>
         <!-- Binding jms admin objects in the GS internal rmiReg. -->
         <internal-jndi>
<internal-jndi-enabled>false</internal-jndi-enabled>
         </internal-jndi>
         <!-- Binding jms admin objects on an external jndi registry -->
         <ext-jndi>
              <ext-jndi-enabled>false</ext-jndi-enabled>
         </ext-jndi>
       </jms_services>
<directory_services>
              </container>
       </core>
  </j_spaces>
</com>

Embedded-Services

The container can start an HTTP server that is used for code download.

<!-- Specify the embedded services which the GigaSpaces container will start -->
<embedded-services>
<!-- Starts a Webster HTTP Server embedded in the container VM
Default value: true -->
<httpd>
					<enabled>${com.gs.embedded-services.httpd.enabled}</enabled>
					<!-- The additional root(s) to serve code from. This is a semi-colin delimited list of directories.
					For example dir1;dir2 Default value: null no additional roots. The system uses the predefined
					roots com.gs.hom/lib;com.gs.home/lib/jini -->
					<additional-roots></additional-roots>
					<!-- The host address the server socket HTTPD (Webster) is using is bound to.
					Relevant for multi NIC environment.
					Default value: resolved to localhost ip address. -->
					<explicit-binding-address>${java.rmi.server.hostname}</explicit-binding-address>
					<!-- The host port the server socket HTTPD (Webster) is using is bound to.
					Default value: port 9813 but if that is busy it generates an anonymous port-->
					<explicit-binding-port>${com.gs.embedded-services.httpd.port}</explicit-binding-port>
				</httpd>
</embedded-services>

To modify the default setting of the embedded httpd use the following:

  • -Dcom.gs.embedded-services.httpd.enabled=false - as a system property
  • com.j_spaces.core.container.embedded-services.httpd.enabled=false - as part of a properties file.

The container can also start an embedded Mahalo (Jini Transaction Manager). To do this, run <GigaSpaces Root>\bin\gsInstance.bat/sh and set the following option to true (it is false by default):

<embedded-services>
  <mahalo>
	<!-- If true, will start an embedded Mahalo Jini Transaction Manager. Default value: false -->
    <start-embedded-mahalo>${com.gs.start-embedded-mahalo}</start-embedded-mahalo>
  </mahalo>
</embedded-services>

Alternatively, you can enable this option in one of the following ways:

  • Set the following option in the gsInstance command line:
    -Dcom.gs.start-embedded-mahalo=true
    

  • Set the following XPath property in the <GigaSpaces Root>\config\gs.properties file:
    com.j_spaces.core.container.embedded-services.mahalo.start-embedded-mahalo=true
    

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