addNode command best practices
Use the addNode command to add a standalone node into a cell. The addNode command does the following:
- Copies the base WAS cell configuration to a new cell structure. This new cell structure matches the structure of deployment manager.
- Creates a new node agent definition for the node that the cell incorporates.
- Sends commands to the deployment manager to add the documents from the new node to the cell repository.
- Performs the first configuration synchronization for the new node, and verifies that this node is synchronized with the cell.
- Launches the node agent process for the new node.
- Updates...
- setupCmdLine.sh
- wsadmin.properties
...to point to the new cell.
- After federating the node, the addNode command backs up...
app_server_root/config/cells/plugin-cfg.xml...to...
app_server_root/config/backup/base/cellsThe addNode command regenerates a new plugin-cfg.xml file at the Deployment Manger and the nodeSync operation copies the files to the node level.
For information about port numbers, see port number settings in WAS versions.
Tips for using the addNode command:
- Verify that the deployment manager and nodes are updated to the same revision level within the WAS. For example, a deployment manager at level 6.0.1 will be unable to federate with nodes at 6.0.2.
- Do not put WAS .jar files on the generic CLASSPATH variable (default class path) for the overall system.
Some AIX or Linux systems create an association between the host name of the machine and the loopback address -- 127.0.0.1 (Red Hat installations do this by default). In addition, the file...
/etc/nsswitch.conf...is set up to use...
/etc/hosts...before trying to look up the server using a name server. This setup can cause failures when trying to add or administer nodes when the deployment manager or appserver is running on the Red Hat system or an operating system such as AIX or Linux with the same setup.
If your deployment manager or your appserver run on the Red Hat system, or an operating system such as AIX or Linux with the same setup, perform the following operations to ensure that you can successfully add and administer nodes:
- Remove the 127.0.0.1 mapping to the local host in the /etc/hosts path.
- Edit the /etc/nsswitch.conf file so that the hosts line reads:
hosts: dns files
- 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 standalone 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 using the console. In the console, go to...
System Administration | Deployment Manager | Java and Process Management | Process Definition | Java Virtual Machine | Maximum Heap Size
- 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...
$WAS_HOME/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 change the default you can edit this line to set the timeout to a value more appropriate for your situation (setting the above value to 0 will disable the timeout check altogether). 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 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 directory...
dmgrProfile/config/cells/dmgrCell/nodeName...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:
washome/profiles/dmgrProfile/config/cells/dmgrCell/]nodeName
Related tasks
Manage nodes
Related Reference
addNode command
removeNode command
Port number settings in WAS versions
Reference topic