Avoid port conflicts in coexisting
Version 6.x, Version 7.0, and Version 8.0 node agents.
If you create a Version 8.0 federated
node on the same system where another Version 8.0 federated node exists,
the addNode command increments the port assignments
of the second node agent process so that no conflict occurs. The Profile
Management tool also handles the port assignments successfully when
you federate a custom node during the creation of the custom profile.
Contrast
the Version 8.0 coexistence
scenario just described to the following cross-version scenario where
a Version 6.x or Version 7.0 federated node exists.
Assume that
you create a Version 8.0 federated
node on the same system where a Version 6.x or Version 7.0 federated
node exists. Neither the addNode command nor the
Profile Management tool has a record of the Version 6.x or Version
7.0 port assignments. Port assignments on the second, Version 8.0 node agent process
are not incremented. Conflicts occur.
The conflicts prevent
the second node from starting. If you start the Version 6.x or Version
7.0 node first, the Version 8.0 node
cannot start. If you start the Version 8.0 node first, the Version
6.x or Version 7.0 node cannot start.
Perform the following
procedure to create a Version 8.0 federated
node with nonconflicting ports.
- Create a Version 78.0 application server profile or
the custom profile.
Do not federate the node as you
create the profile. Select the check box on the Profile Management
tool panel that specifies that you will federate the node later.
- Check for ports in use to determine a starting port
number for the Version 8.0 node
agent process.
Use the netstat -a command
to check existing port assignments. Analyze the port assignments to
determine 12 sequential free ports.
This procedure assumes that
no port assignments exist between 3320 and 3380.
- Change directories to the bin directory
of the new profile.
Assume that you create an application
server profile named V70MngNode in the default installation root directory
on a Linux® system.
cd /opt/IBM/WebSphere/AppServer/profiles/V70MngdNode/bin
- Use the addNode command with the
-startingport parameter to federate the node into the deployment manager
cell and to assign ports from a beginning value.
Assume
that the deployment manager has the following characteristics:
- Host name is the domain name system address: nittany.ibm.raleigh.com
- JMX connector type: remote method invocation (RMI)
- RMI port assignment: 8879
- Security status: Enabled
- Applications to install: DefaultApplication and the samples
In a Linux environment, for example,
issue the following command:
./addNode.sh nittany.ibm.raleigh.com \
-conntype RMI 8879 \
-includeapps \
-user lions44 \
-password PSU
-startingport 3333
The \ character is a continuation
character for using more than one line to submit commands.
The -startingport parameter supplies the base port
number for all node agent ports and increments all of the port values
from the starting point. The nonconflicting port assignments let the
new node agent run when the Version 6.x or Version 7.0 node agent
process is already running.
This procedure results in the ability
to start your Version 6.x or Version 7.0 node at the same time as
your Version 8.0 node. The
node agents can run on the same server.
You can also assign
ports individually using the -portprops parameter. The parameter identifies
a flat file of key words and port number assignments that you must
create. The following example of a
portprops file
shows all key words and their default port assignments:
WC_defaulthost 9081
WC_adminhost 9062
WC_defaulthost_secure 9444
WC_adminhost_secure 9045
BOOTSTRAP_ADDRESS 2810
SOAP_CONNECTOR_ADDRESS 8881
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS 9901
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS 9201
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS 9102
ORB_LISTENER_ADDRESS 9900
CELL_DISCOVERY_ADDRESS 7272
DCS_UNICAST_ADDRESS 9354