See the WebSphere eXtreme Scale Wiki for links to eXtreme Scale Version 7.0 documentation.
If you log in
with your developerWorks ID, you can leave comments and feedback for the development team.
The dynamic ObjectGrid environment is comprised of catalog service processes, ObjectGrid container processes, and ObjectGrid client processes. For an explanation on how to stop ObjectGrid processes, see Stopping ObjectGrid server processes.
Catalog Service Processes
Launching a catalog service is the first step in bringing your dynamic ObjectGrid environment online. See Starting a catalog service for more information about launching these processes.
ObjectGrid Container Processes
This section focuses on launching ObjectGrid containers. You need an ObjectGrid XML file in order to start a container process. The ObjectGrid XML file that you pass to the container is your way of telling a container which ObjectGrids it is allowed to host. Ensure that your container is equipped to host each ObjectGrid in the XML that you pass to it. All classes required by these ObjectGrids must be in the container's classpath.
To start a container, type the following commands from the command-line:
- cd objectgridRoot/bin
- startOgServer.sh c0 -objectGridFile ../xml/companyGrid.xml -catalogServiceEndpoints MyServer1.company.com:2809
 | Warning
On the container, the -catalogServiceEndpoints option is used to reference the Object Request Broker (ORB) host and port on the catalog service. The catalog service uses -listenerHost and -listenerPort to specify the host and port for ORB binding or accepts the default binding. When starting a container, use -catalogServiceEndpoints to reference the values passed to -listenerHost and -listenerPort on the catalog service. If -listenerHost and -listenerPort are not used when starting the catalog service, the ORB binds to port 2809 on the catalog service's localhost.
The -catalogServiceEndpoints option should NOT be used to reference the hosts and ports that were passed to the -catalogServiceEndpoints on the catalog service. On the catalog service, the -catalogServiceEndpoints option is used to specify ports necessary for static server configuration. |
This process is identified by c0, the first argument passed to the script. Use the companyGrid.xml to start the container. If your catalog server ORB is running on a different host than your container or it is using a non-default port, you must use the -catalogServiceEndpoints argument to connect to it. For this example, assume that a single catalog service is running on port 2809 on MyServer1.company.com.
Using a deployment policy
Although not required, a deployment policy is recommended during container start up. The deployment policy is used to set up partitioning and replication for your ObjectGrid. The deployment policy can also be used to influence placement behavior. Since the previous example did not provide a deployment policy file, it receives all default values with regard to replication, partitioning, and placement. So, the maps in the CompanyGrid will be in one mapSet. The mapSet will not be partitioned, nor will it be replicated. The following example uses the companyGridDpReplication.xml
to start a container.
- cd objectgridRoot/bin
- startOgServer.sh c0 -objectGridFile ../xml/companyGrid.xml -deploymentPolicyFile ../xml/companyGridDpReplication.xml -catalogServiceEndpoints MyServer1.company.com:2809
In the comapnyGridDpReplication.xml, a single map set contains all of the ObjectGrid's maps. This mapSet is divided into 10 partitions. Each partition has 1 synchronous replica and no asynchronous replicas.
Any container that uses the companyGridDpReplication.xml deployment policy paired with the companyGrid.xml ObjectGrid XML is also able to host CompanyGrid shards. Start another container JVM to host this ObjectGrid:
- cd objectgridRoot/bin
- startOgServer.sh c1 -objectGridFile ../xml/companyGrid.xml -deploymentPolicyFile ../xml/companyGridDpReplication.xml -catalogServiceEndpoints MyServer1.company.com:2809
Each deployment policy contains one or more objectgridDeployment elements. When a container is started, it publishes its deployment policy to the catalog service. The catalog service examines each objectgridDeployment. If the objectgridName matches the objectgridName of a previously received objectgridDeployment, the latest objectgridDeployment is ignored. The first objectgridDeployment received for a specific ObjectGrid is used as the master.
For example, assume that c2 uses a deployment policy that divides the mapSet into a different number of partitions:
<?xml version="1.0" encoding="UTF-8"?>
<deploymentPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/deploymentPolicy ../deploymentPolicy.xsd"
xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy">
<objectgridDeployment objectgridName="CompanyGrid">
<mapSet name="mapSet1" numberOfPartitions="5"
minSyncReplicas="1" maxSyncReplicas="1"
maxAsyncReplicas="0">
<map ref="Customer" />
<map ref="Item" />
<map ref="OrderLine" />
<map ref="Order" />
</mapSet>
</objectgridDeployment>
</deploymentPolicy>
- cd objectgridRoot/bin
- startOgServer.sh c2 -objectGridFile ../xml/companyGrid.xml -deploymentPolicyFile ../xml/companyGridDpReplicationModified.xml -catalogServiceEndpoints MyServer1.company.com:2809
The container on the c2 JVM is started with a deployment policy that specifies 5 partitions for mapSet1. However, the catalog service already holds the master copy of the objectgridDeployment for the CompanyGrid. When c0 was started it specified a 10 partitions for this mapSet. Since it was the first container to start and publish its deployment policy, its deployment policy became the master. Therefore, any difference within the CompanyGrid objectgridDeployment of a subsequent deployment policy is ignored.
Using a server properties file
A server properties file can be used to set up trace and configure security on a container. Issue the following commands to start container c3 with a server properties file.
- cd objectgridRoot/bin
- startOgServer.sh c3 -objectGridFile ../xml/companyGrid.xml -deploymentPolicyFile ../xml/companyGridDpReplicationModified.xml -catalogServiceEndpoints MyServer1.company.com:2809 -serverProps ../serverProps/server.properties
See the Server properties topic for additional information.
Enabling trace at startup
If a container fails to start, startup trace can be useful in debugging the problem. To enable trace during the startup of a server, add the -traceSpec and -traceFile parameters to the startup commands. The -traceSpec is the type of trace to enable and the -traceFile is path and name of the traceFile to create and use.
Issue the following commands to enable startup trace on c4:
- cd objectgridRoot/bin
- startOgServer.sh c4 -objectGridFile ../xml/companyGrid.xml -deploymentPolicyFile ../xml/companyGridDpReplicationModified.xml -catalogServiceEndpoints MyServer1.company.com:2809 -traceFile ../logs/c4Trace.log -traceSpec ObjectGrid=all=enabled
Once trace is obtained, look for errors related to port conflicts, missing classes, missing or incorrect XML files or any stack traces.
Suggested startup trace specifications are:
ObjectGrid=all=enabled
ObjectGrid*=all=enabled
For all of the trace specification options, see Trace options
Enabling security at startup
In order to start a secure container server, you have to set the securityEnabled to true in the server property file. You also need to set other security properties to handle the client authentication and server to server authentication. Refer to ObjectGrid security overview section for an overview of ObjectGrid security and navigate for more security details. For an example of how to start a secure container server, refer to J2SE security tutorial step 2 - client authentication example.
Command line parameters
For all of the command line options for starting and stopping servers, see Starting command line parameters.
© Copyright IBM Corporation 2007,2009. All Rights Reserved.
