The addNode command incorporates a WebSphere Application Server installation into a cell.
For more information about where to run this command, see the Using command line tools article. Depending on the size and location of the new node you incorporate into the cell, this command can take a few minutes to complete. You must have Administrator privileges to use the addNode function.
The node agent server is automatically started as part of the addNode command unless you specify the -noagent option. If you recycle the system that hosts an application server node, and did not set up the node agent to act as an operating system daemon, you must issue a startNode command to start the node agent before starting any application servers.
The command syntax is as follows:
addNode dmgr_host [dmgr_port] [-conntype type] [-includeapps] [-startingport portnumber] [-portprops qualified_filename] [-nodeagentshortname name] [-nodegroupname name] [-includebuses] [-registerservice] [-serviceusername name] [-servicepassword password] [-coregroupname name] [-noagent] [-statusport 1231] [-quiet] [-nowait] [-logfile filename] [-replacelog] [-trace] [-username uid] [-password pwd] [-localusername localuid] [-localpassword localpwd] [-help]
The dmgr_host argument is required. All of the other arguments are optional. The default port number is 8879 for the default SOAP port of the deployment manager. SOAP is the default Java Management Extensions (JMX) connector type for the command. If you have multiple WebSphere Application Server installations or multiple profiles, the SOAP port may be different than 8879. Examine the deployment manager SystemOut.log to see the current ports in use.
The following options are available for the addNode command:
The applications will be mapped to the server that you federated using the addNode command. When the addNode command operation completes, the applications will run on that server when the server is started. Since these applications are part of the network deployment cell, you can map them to other servers and clusters in the cell using the administrative console. See the Mapping modules to servers article for more information.
You should not use the -includeapps option if your node to be federated includes WebSphere Application Server supplied applications, such as the samples. If you do, the second node to be federated that includes these applications will be rejected because the applications already exist in the cell and application merge is not supported.
If you use the -includeapps option on a node that includes a large number of applications, the timeout for the administrative connector needs to be extended to account for the additional time required to transfer all of the applications to the deployment manager during addNode and to remotely install them into the cell. The -includeapps option is not a recommended approach unless only a few unique applications exist on the node.
By default, during application installation, application binaries are extracted in the app_server_root/installedApps/cellName directory. After the addNode command, the cell name of the configuration on the node that you added changes from the base cell name to the deployment manager cell name. The application binaries are located where they were before the addNode command ran, for example, app_server_root/installedApps/old_cellName.
${app_server_root}/${CELL}where the variable ${CELL}, specifies the current cell name, then when the addNode command runs, the binaries are moved to the following directory:
${app_server_root}/currentCellName
Federating the node to a cell using the addNode command does not merge any cell level configuration, including virtual host information. If the virtual host and aliases for the new cell do not match WebSphere Application Server, you cannot access the applications running on the servers. You have to manually add all the virtual host and host aliases to the new cell, using the administrative console running on the deployment manager.
ADMU0111E: Program exiting with error: java.lang.OutOfMemoryError
This error can occur when large applications are processed, or when there is a large number of applications in the Base Application Server.
To recover from this error and successfully federate the Base Application Server, you must:
SET JVM_EXTRA_CMD_ARGS="-Djava.security.properties=$WAS_HOME/java/jre/lib/security/ java.security -Xms256m -Xmx1024m"
JVM_EXTRA_CMD_ARGS="-Djava.security.properties=$WAS_HOME/java/jre/lib/security/ java.security -Xms256m -Xmx1024m"
In order to avoid potential port conflicts, see Port number settings in WebSphere Application Server versions for more information on default port settings.
If multiple node agents exist on the same physical server, you can define the base port number for each by using the -startingport parameter prior to federation, or by modifying the ports in the node agent section of serverindex.xml.
SOAP_CONNECTOR_ADDRESS=3000 BOOTSTRAP_ADDRESS=3001
addNode testhost 8879 (adds an application server to the deployment manager) addNode deploymgr 8879 -trace (produces the addNode.log file) addNode host25 8879 -nowait (does not wait for a node agent process)where 8879 is the default port.