Use the addNode command to add a stand-alone
node into a cell.
The
addNode command does the
following:
Tips for using the
addNode command:
- If you add a node to a cell, the cell name of the node you are
federating must be different from the name of the cell to which the
node is federated. Otherwise, you receive the ADMU0027E message, and
the addNode command does not add the node to the
cell.
- Verify that the deployment manager and nodes are updated to the
same revision level within the WebSphere Application Server. For example,
a deployment manager at level 6.0.1 will be unable to federate with
nodes at 6.0.2.
- Do not put WebSphere Application Server .jar files
on the generic CLASSPATH variable (default class
path) for the overall system.
If the WebSphere Application Server, Network Deployment product cannot
resolve the host name of the server, problems can occur with such
situations as adding or administering nodes, or the node agent contacting
the application server. To resolve the host name, the product opens
a port, or queries for an IP address. The product then waits for the
operating system to return the correct information. The operating
system might go to multiple places to find the IP address, but the
product does not care about the order in which the operating system
does this, if the correct information is returned. If the host name
of the server cannot be resolved, refer to your network administration
documentation to resolve the problem. The following additional information
might help you ensure that the host name is resolved.
- By default, applications that are installed on the node will not
copy to the cell. If you install an application after using the addNode command,
the application will install on the cell. By specifying the -includeapps option,
you force the addNode command to copy applications
from the node to the cell. Applications with duplicate names will
not copy to the cell.
- Cell-level documents are not merged. Any changes that you make
to the stand-alone cell-level documents before using the addNode command
must be repeated on the new cell. For example, virtual hosts.
- If you receive an OutOfMemory exception while using the addNode command,
you may need to increase the heap size of the deployment manager.
To increase the heap size of the deployment manager, adjust the Maximum
heap size parameter. For example, in the administrative
console, go to and increase
the Maximum heap size value.
![[HP-UX]](../images/hpux.gif)
Avoid trouble: On HP-UX or Solaris operating
systems, a
java.lang.OutOfMemoryError: PermGen space
problem might occur during large and complex tasks. For example, you
might encounter this problem when you run commands such as
addNode on
nodes with large applications. When the demands for resources exceed
the default storage size, the task can fail with a
java.lang.OutOfMemoryError:
PermGen space error. To resolve this problem, increase the
minimum size of the permanent region. Set the
-XX:PermSize Java virtual machine (JVM) option
to a value such as
128MB, which is sufficient for
many situations in which this problem occurs:
XX:PermSize=128m
gotcha
- In some instances it may take longer than anticipated for the
deployment manager to respond to the addNode command.
The default timeout value, which determines how long the client will
wait for a server response, is appropriate in the majority of cases.
However, you may require more time for the server to respond under
heavier processing conditions. For example, if you include the -includeapps option
and have a large number of applications, or the applications are very
large, the default value of 180 seconds may be insufficient. To change
the default timeout value, open the file app_server_root/profiles/profile_name/properties/soap.client.props in
any ASCII text editor and find the following line (shown here with
default value of 180 seconds):
com.ibm.SOAP.requestTimeout=180
If
you need to change the default you can edit this line to set the timeout
to a value more appropriate for your situation. Note: Setting the
default timeout value to 0 seconds disables the timeout
check.
If the timeout value is set too high you will have
to wait a long time to determine if the addNode command
will successfully complete its request to the deployment manager.
If the value is set too short the deployment manager will not have
sufficient time to complete the request before the addNode command
concludes that the deployment manager is not responding and will respond
with an error. Other factors that may affect server timeouts include
the processing load or excessive paging on the deployment manager
and network latency. Some of these conditions may be transient.
- If you receive an addNode error message regarding
bad clock syncs, make sure that the computer with the node to be federated
is in time sync with the deployment manager computer to which the
node is to be federated.
- If you use the addNode command from a node
that was federated to an existing deployment manager, the deployment
manager will be corrupt. You will not be able to start the second
deployment manager after you stop it. This happens because the addNode
command creates a dmgrProfile/config/cells/dmgrCell/dmgrCell directory
in the master configuration. This is an incomplete node configuration
directory.
You will come into contact with the issue if you have
a federated node and run the addNode command again
for a different deployment manager. This causes the deployment manager
to be corrupted and you will not be able to start the deployment manager
afterwards because of the incomplete node directory.
Perform
one of the following solutions to resolve this issue:
- If the deployment manager is running, you can use the cleanupNode command
on deployment manager where the incomplete node resides.
- Manually delete the directory that was created on the deployment
manager configuration during an addNode command
operation that was incomplete. For example: app_server_root/profiles/dmgrProfile/config/cells/dmgrCell/nodeName.