Container Schema

Added by Gilad David Maayan, last edited by Aleia Hutcherson on May 25, 2008  (view change)
  GigaSpaces 5.X

Documentation Home
Quick Start Guide
Release Notes

Previous release
  Search Here
Searching GigaSpaces Platform 5.X Documentation

                                               
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.

Schema Name

The container schema file includes the container scheme 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 the following operations: CreateSpace, DestroySpace, ShutDown, SetConfig, Restart
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 or 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

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
    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. 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. 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  = register to all group
                                         none = don't register to any group
                                         public = fallback group if the -Dcom.gs.jini_lus.groups is not set,
                                         otherwise using that value, e.g. -Dcom.gs.jini_lus.groups=myGroup
                                         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.
true
<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 = register to all groupnone = don't register to any grouppublic = fallback 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:4160, host2:4160, host3:4184 localhost:4160

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. This 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>
</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

When loading gsServer (loads GigaSpaces with ServiceStarter) we disable embedded LUS as well as the HTTPD. This is done via the config/services/gigaspaces.config file.

For details on logging, refer to the Logging for GigaSpaces 5.0 section, relevant if you are using GigaSpaces version 5.0.
For the GigaSpaces logging system using java.util.logging, supported in GigaSpaces version 5.1 and onwards, refer to the GigaSpaces Logging section.

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