Starting the catalog service process in a WebSphere Application Server environment

WebSphere® eXtreme Scale catalog servers can automatically start in a WebSphere Application Server or WebSphere Application Server Network Deployment environment. You can configure the catalog service to run in any process within the WebSphere cell. A single-server non-clustered catalog service is acceptable for development environments. For a production environment, you should use a catalog service grid with multiple catalog servers.

Before you begin
You must install WebSphere Application Server and WebSphere eXtreme Scale. See Installing and deploying WebSphere eXtreme Scale for more information.
About this task
The catalog service process can run in a WebSphere Application Server process.

For the base WebSphere Application Server, the catalog service runs in the application server process. By default, it is not enabled to start automatically.

For WebSphere Application Server Network Deployment, the catalog service runs in the deployment manager process automatically, but you can configure it to run in one or more node-agent or application-server processes.

Defining the catalog.services.cluster property

By defining the catalog.services.cluster cell, node or server custom property, you can customize your catalog service environment. The environment can consist of a single catalog server or a cluster (grid) of catalog servers. A single catalog server is recommended for a development environment, and a grid of catalog servers for a production environment. This key-value pair identifies which server process will be enabled.

Set the value of the custom property in the following form:

catalog.services.cluster   ::= hosted_endpoints
hosted_endpoints           ::= serverName ":" endpoints {"," hosted_endpoints}
endpoints                  ::= hostName ":" clientPort ":" peerPort ":" listenerPort
Each attribute for the custom property value is defined as follows:
serverName
Specifies the fully qualified name of the WebSphere process, such as the cellName, nodeName, and serverName of the server that hosts the catalog service. If the serverName is not the local process, clients and containers use this information to connect to the catalog service.

The following is an example for a remote catalog service cluster:

server1:host.local.domain:6601:6602:2809,server2:host.local.domain:6601:6602:2809
hostName
Specifies the name of the hosting server.
clientPort
Specifies the port that is used for peer catalog grid communication.
peerPort
Specifies the port that is used for peer catalog grid communication and can be anything you choose in a WebSphere Application Server environment.
listenerPort
The listenerPort must match the BOOTSTRAP_ADDRESS value that is defined in the WebSphere server configuration.

A process that matches the serverName property enables the catalog service on that server process.

Ensure that you do not collocate the catalog service with eXtreme Scale containers in a production environment. Include the catalog service in multiple node agent processes or an application server cluster that is not hosting an eXtreme Scale application.

Restriction: You cannot have servers in a WebSphere Application Server environment with the same name when the servers are using the ORB to communicate with each other. You can resolve this restriction by specifying the system property -Dcom.ibm.websphere.orb.uniqueServerName=true for the processes that have the same name. The following are examples: When servers with the name server1 on each node are used as a grid of catalog services, or where multiple node agents are used to form a grid of catalog services.

Examples:

  • For a non-clustered catalog service, define a single value on an example server1 as follows:

    cellA\node1\server1:<hostname>:<clientport>:<peerport>:<listenerport>

  • For a clustered catalog service as in the following example with 3 servers, define the property in a comma-delimited list:
    cellA\node1\server1:<hostname1>:<clientport>:<peerport>:<listenerport>,
    cellA\node2\server1:<hostname2>:<clientport>:<peerport>:<listenerport>,
    cellA\node3\server1:<hostname3>:<clientport>:<peerport>:<listenerport>

    In the previous example, server1 is defined on all 3 hosts: hostname1, hostname2, and hostname3. This property specifies the fully qualified name of the WebSphere process, such as the cellName, nodeName, and serverName of the server that hosts the catalog service. Also, clientport and peerport are non-conflicting ports and listenerport must match the BOOTSTRAP_ADDRESS for the servers.

With some exceptions, the catalog.services.cluster custom property is similar to the -catalogServiceEndPoints parameter that is used when starting a stand-alone catalog server with the addition of the -listenerPort parameter.

Remember: The format and requirements for the custom property file are similar, but depending on your WebSphere Application Server deployment (base or Network Deployment), you must choose a different menu path to set the parameters, as follows.