startOgServer script (ORB)

[Version 8.6 and later] (Deprecated) The startOgServer script starts container and catalog servers that use the Object Request Broker (ORB) transport mechanism. You can use a variety of parameters when you start your servers to enable trace, specify port numbers, and so on.

Purpose

You can use the startOgServer script to start servers.

Deprecated: The startOgServer and stopOgServer commands start servers that use the Object Request Broker (ORB) transport mechanism. The ORB is deprecated, but you can continue using these scripts if you were using the ORB in a previous release. The IBM eXtremeIO (XIO) transport mechanism replaces the ORB. Use the startXsServer and stopXsServer scripts to start and stop servers that use the XIO transport.

Location

The startOgServer script is in the bin directory of the root directory, for example:

cd wxs_install_root/bin

Note: If you have Java™ classes stored in a specific directory, or you are using a loader or agent, instead of altering the startOgServer script, you can launch the server with arguments as follows:

-jvmArgs -cp C:\ . . .
\DirectoryPOJOs\POJOs.jar

Usage for catalog servers

To start a catalog server:

startOgServer.bat <server> [options]

startOgServer.sh <server>[options]

To start a default configured catalog server, use the following commands:

startOgServer.bat catalogServer

startOgServer.sh catalogServer

Options for starting catalog servers

The following parameters are all optional.

Parameters for starting a catalog server:

-catalogServiceEndPoints <serverName:hostName:clientPort:peerPort>

Specifies a list of catalog servers to link together into a catalog service domain. Each attribute is defined as follows:

serverName: Specifies the name of the catalog server.
hostName: Specifies the host name for the computer where the server is launched.
clientPort: Specifies the port that is used for peer catalog service communication.
peerPort: This value is the same as the haManagerPort. Specifies the port that is used for peer catalog service communication.

The following example starts the cs1 catalog server, which is in the same catalog service domain as the cs2 and cs3 servers:

startOgServer.bat|sh cs1 -catalogServiceEndPoints 
cs1:MyServer1.company.com:6601:6602,cs2:MyServer2.company.com:6601:6602,cs3:MyServer3.company.com:6601:6602

If you start additional catalog servers, they must include the same servers in the -catalogServiceEndPoints argument. The order of the list can be different, but the servers contained in the list must be the same for each catalog server. Do not put any spaces in the list.

-clusterSecurityFile <cluster security xml file>

Specifies the objectGridSecurity.xml file on the hard disk, which describes the security properties that are common to all servers (including catalog servers and container servers). One of the property example is the authenticator configuration which represents the user registry and authentication mechanism.

Example:/opt/xs/ogsecurity.xml

Important: If you are using Windows, the directory path does not support backslashes. If you have used backslashes, you must escape any backslash ( \ ) characters in the path. For example, if you want to use the path C:\opt\ibm, enter C:\\opt\\ibm in the properties file. Windows directories with spaces are not supported.

-clusterSecurityUrl <cluster security xml URL>

Specifies the objectGridSecurity.xml file as a URL to the file on the hard disk or on the network, which describes the security properties that are common to all servers (including catalog servers and container servers). One of the property example is the authenticator configuration which represents the user registry and authentication mechanism.

Example:file:///opt/xs/ogsecurity.xml

-domain <domain name>

Specifies the name of the catalog service domain for this catalog server. The catalog service domain creates a group of highly available catalog servers. Each catalog server for a single domain should specify the same value for the -domain parameter.

-haManagerPort <port>

Specifies the port that is used by the high availability (HA) manager for heartbeat communication between peer container servers. The HAManagerPort port is only used for peer-to-peer communication between container servers that are in same domain. If the HAManagerPort property is not defined, then an ephemeral port is used. In WebSphere® Application Server, this setting is inherited by the high availability manager port configuration.

-heartbeat 0|1|-1

Specifies how often a server failover is detected. An aggressive heartbeat interval can be useful when the processes and network are stable. If the network or processes are not optimally configured, heartbeats might be missed, which can result in a false failure detection. The heartbeat frequency level is a trade-off between use of resources and failure discovery time. The more frequent a heartbeat occurs, then more resources are used. However, failures are discovered more quickly. This property applies to the catalog service only.

Table 1. Valid heartbeat values. Values from `-1` for aggressive heartbeat to `1` for relaxed heartbeat specify how often a server failover is detected.
Value	Action	Description
-1	Aggressive	Specifies an aggressive heartbeat level. With this value, failures are detected more quickly, but more processor and network resources are used. This level is more sensitive to missing heartbeats when the server is busy. Failovers are typically detected within 5 seconds.
-10	Semi-aggressive	Failovers are typically detected within 15 seconds.
0	Typical (default)	Specifies a heartbeat level at a typical rate. With this value, failover detection occurs at a reasonable rate without overusing resources. Failovers are typically detected within 30 seconds.
10	Semi-relaxed	Failovers are typically detected within 90 seconds.
1	Relaxed	Specifies a relaxed heartbeat level. With this value, a decreased heartbeat frequency increases the time to detect failures, but also decreases processor and network use. Failovers are typically detected within 180 seconds.

-JMXConnectorPort <port>

Defines the Secure Sockets Layer (SSL) port to which the Java Management Extensions (JMX) service binds. Only required if an SSL transport protocol is needed for JMX data.

-JMXServicePort <port>

Required only for WebSphere eXtreme Scale in a stand-alone environment. Specifies the port number on which the MBean server listens for communication with Java Management Extensions (JMX).

Default: 1099 for catalog servers

-jvmArgs <JVM arguments>

Specifies a set of JVM arguments. Every option after the -jvmArgs option is used to start the server Java virtual machine (JVM). When the -jvmArgs parameter is used, ensure that it is the last optional script argument specified.

Example:-jvmArgs -Xms256M -Xmx1G

-listenerHost <host name>

Specifies the host name to which the Object Request Broker (ORB) or eXtremeIO (XIO) transport protocol binds for communication. The value must be a fully qualified domain name or IP address. If your configuration involves multiple network cards, set the listener host and port to the IP address for which to bind. By setting the listener and host port, it allows the transport mechanism in the JVM know which IP address to use. If you do not specify which IP address to use, symptoms such as connection timeouts, unusual API failures, and clients that seem to hang can occur.

Default: localhost

-listenerPort <port>

Specifies the port number to which the ORB or the XIO transport protocol binds for communication. The port number that is defined for listenerPort is used for bidirectional communication between a client and a container server that are in the same domain. It is also used for communication between a catalog server and a container server that are in the same domain. This port is also used for intra-domain replication between primary and replica shards, and inter-domain replication between primary shards.Default: 2809

-quorum true|false

Enables quorum for the catalog service. Quorum is used to ensure that most of the catalog service domain is available before partitions are moved to the available container servers. To enable quorum, set the value to true or enabled. The default value is disabled. This property applies to the catalog service only. For more information, see Catalog server quorums.

-script <script file>

Specifies the location of a custom script for commands you specify to start catalog servers or containers and then parameterize or edit as you require.

-serverProps <server properties file>

Specifies the server property file that contains the server-specific security properties. The file name specified for this property is just in plain file path format, such as c:/tmp/og/catalogserver.props.

-traceSpec <trace specification>

Enables trace and the trace specification string for the container server. Trace is disabled by default. This property applies to both the container server and the catalog service. Examples:

ObjectGrid=all=enabled
ObjectGrid*=all=enabled

-traceFile <trace file>

Specifies a file name to write trace information. This property applies to both the container server and the catalog service.

-timeout <seconds>

Specifies a number of seconds before the server start times out.

-transport <transport type>

Specifies the type of transport to use for all the servers in the catalog service domain. You can set the value to XIO or ORB.

The startOgServer script sets the transport type to ORB by default.

If you have both the -transport parameter and the transport server property defined on a catalog server, the value of the -transport parameter is used.

Usage for container servers

startOgServer.bat <server> -objectgridFile <xml file> 
-deploymentPolicyFile <xml file> [options]

startOgServer.bat <server> -objectgridUrl <xml URL> 
-deploymentPolicyUrl <xml URL> [options]

startOgServer.sh <server> -objectgridFile <xml file> 
-deploymentPolicyFile <xml file> [options]

 startOgServer.sh <server> -objectgridUrl <xml URL> 
-deploymentPolicyUrl <xml URL> [options]

Options for container servers

-catalogServiceEndPoints <hostName:port,hostName:port>

Specifies the Object Request Broker (ORB) host and port on the catalog service.

Default: localhost:2809

-deploymentPolicyFile <deployment policy xml file>

Specifies the path to the deployment policy file on the hard disk. The deployment policy is used to set up partitioning and replication. The deployment policy can also be used to influence placement behavior.

Example: ../xml/SimpleDP.xml

-deploymentPolicyUrl <deployment policy url>

Specifies the URL for the deployment policy file on the hard disk or on the network. The deployment policy is used to set up partitioning and replication. The deployment policy can also be used to influence placement behavior.

Example: file://xml/SimpleDP.xml

-JMXConnectorPort <port>

Defines the Secure Sockets Layer (SSL) port to which the Java Management Extensions (JMX) service binds. Only required if an SSL transport protocol is needed for JMX data.

-JMXServicePort <port>

Required only for WebSphere eXtreme Scale in a stand-alone environment. Specifies the port number on which the MBean server listens for communication with Java Management Extensions (JMX).

Default: 1099

-jvmArgs <JVM arguments>

Example:-jvmArgs -Xms256M -Xmx1G

-listenerHost <host name>

Default: localhost

-listenerPort <port>

-objectgridFile <ObjectGrid descriptor xml file>

Specifies the path to the ObjectGrid descriptor file. The ObjectGrid XML file specifies which eXtreme Scale servers the container hosts.

-objectgridUrl <ObjectGrid descriptor url>

Specifies a URL for the ObjectGrid descriptor file. The ObjectGrid XML file specifies which eXtreme Scale servers the container hosts.

-script <script file>

Specifies the location of a custom script for commands you specify to start catalog servers or containers and then parameterize or edit as you require.

-serverProps <server properties file>

Specifies the path to the server property file.

Example:../security/server.props