About this task
To start a container process, you need an ObjectGrid XML
file. The ObjectGrid XML file specifies which
eXtreme Scale servers the container
hosts. Ensure that your container is equipped to host each ObjectGrid
in the XML that you pass to it. All of the classes that these ObjectGrids
require must be in the classpath for the container. For more information
about the ObjectGrid XML file, see
objectGrid.xsd file.
- Start the container process from the command line.
- From the command line, navigate to the bin directory:
cd objectgridRoot/bin
- Run the following command:
startOgServer.sh c0 -objectGridFile ../xml/companyGrid.xml
-catalogServiceEndPoints MyServer1.company.com:2809
Important: 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 the -listenerHost and -listenerPort options
to specify the host and port for ORB binding or accepts the default
binding. When you are starting a container, use the -catalogServiceEndPoints option
to reference the values that are passed to the -listenerHost and -listenerPort options
on the catalog service. If -listenerHost and -listenerPort options
are not used when the catalog service is started, the ORB binds to
port 2809 on the localhost for the catalog service. Do not use the -catalogServiceEndPoints option
to reference the hosts and ports that were passed to the -catalogServiceEndPoints option
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 the ORB. For this example, assume that a single catalog
service is running on port 2809 on MyServer1.company.com
- Start the container 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 eXtreme Scale. The deployment policy
can also be used to influence placement behavior. Because the previous
example did not provide a deployment policy file, the example receives
all default values with regard to replication, partitioning, and placement.
So, the maps in the CompanyGrid are in one mapSet. The mapSet is not
partitioned or replicated. For more information about deployment policy
files, see Deployment policy descriptor XML file. The following example
uses the companyGridDpReplication.xml file to
start a container JVM, the c0 JVM:
- From the command line, navigate to the bin directory:
cd objectgridRoot/bin
- Run the following command:
startOgServer.sh c0 -objectGridFile ../xml/companyGrid.xml
-deploymentPolicyFile ../xml/companyGridDpReplication.xml
-catalogServiceEndPoints MyServer1.company.com:2809
Note: If you have Java classes stored in a specific directory,
instead of altering the StartOgServer script, you can launch the server
with arguments as follows: -jvmArgs -cp C:\ . . . \DirectoryPOJOs\POJOs.jar
. In the companyGridDpReplication.xml file,
a single map set contains all of the maps. This mapSet is divided
into 10 partitions. Each partition has one synchronous replica and
no asynchronous replicas. Any container that uses the companyGridDpReplication.xml deployment
policy paired with the companyGrid.xml ObjectGrid
XML file is also able to host CompanyGrid shards. Start another container
JVM, the c1 JVM:- From the command line, navigate to the bin directory:
cd objectgridRoot/bin
- Run the following command:
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
element. If the objectgridName attribute matches the objectgridName
attribute of a previously received objectgridDeployment element, the
latest objectgridDeployment element is ignored. The first objectgridDeployment
element received for a specific objectgridName attribute is used as
the master. For example, assume that the c2 JVM uses a deployment
policy that divides the mapSet into a different number of partitions: companyGridDpReplicationModified.xml
<?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>
Now, you can start a third JVM, the c2
JVM: - From the command line, navigate to the bin directory:
cd objectgridRoot/bin
- Run the following command:
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 the c0 JVM was started it specified that
10 partitions exist for this mapSet. Because it was the first container
to start and publish its deployment policy, its deployment policy
became the master. Therefore, any objectgridDeployment attribute value
that is equal to CompanyGrid in a subsequent
deployment policy is ignored.
- Start a container using a server properties file.
You can use a server properties file to set up trace and
configure security on a container. Run the following commands to start
container c3 with a server properties file:
- From the command line, navigate to the bin directory:
cd objectgridRoot/bin
- Run the following command:
startOgServer.sh c3 -objectGridFile ../xml/companyGrid.xml
-deploymentPolicyFile ../xml/companyGridDpReplicationModified.xml
-catalogServiceEndPoints MyServer1.company.com:2809
-serverProps ../serverProps/server.properties
An example server.properties file follows: server.properties
workingDirectory=
traceSpec=*=all=disabled
systemStreamToFileEnabled=true
enableMBeans=true
memoryThresholdPercentage=50
This is a basic server properties file that does not
have security enabled. For more information about the server.properties file,
see Server properties file.