addNode command

The addNode command incorporates a WebSphere Application Server installation into a cell. You must run this command from the install_root/bin directory of a WebSphere Application Server installation. Depending on the size and location of the new node you incorporate into the cell, this command can take a few minutes to complete.

The node agent server is automatically started as part of the addNode command. If you recycle the system that hosts an appserver node, and did not set up the node agent to act as an operating system daemon, issue a startNode command to start the node agent before stating any application servers.

Syntax

The command syntax is as follows:

addNode <deploymgr host> <deploymgr port> [options]

The <deploymgr host> argument is required. The default port number is 8879 for the default Simple Object Access Protocol (SOAP) port of the deployment manager. SOAP is the default Java Management Extensions (JMX) connector type for the command. If you install the deployment manager using coexistence ports, the default SOAP port is 8889.

Parameters

The following options are available for the addNode command:

-nowait

Tells the addNode command not to wait for successful initialization of the launched node agent process.

-quiet

Suppresses the progress information that the addNode command prints in normal mode.

-logfile <filename>

Specifies the location of the log file to which information gets written.

-replacelog

Replaces the log file instead of appending to the current log.

-trace

Generates trace information into a file for debugging purposes.

-replacelog

By default, the addNode command appends to the existing trace file. This option causes the addNode command to overwrite the trace file.

-noagent

Tells the addNode command not to launch the node agent process for the new node.

-username <name>

Specifies the user name for authentication if security is enabled. Acts the same as the -user option.

-user <name>

Specifies the user name for authentication if security is enabled. Acts the same as the -username option.

-password <password>

Specifies the password for authentication if security is enabled.

-conntype <type>

Specifies the JMX connector type to use for connecting to the deployment manager. Valid types are SOAP or RMI, which stands for Remote Method Invocation.

-includeapps

By default the addNode command does not carry over applications from the stand-alone servers on the new node to the cell. This option tells the addNode command to attempt to include applications from the new node. If the application already exists in the cell, a warning is printed and the application is not installed into the cell.

By default, during application installation, application binaries are extracted in the install_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, install_root/installedApps/old_cellName.

If the application was installed by explicitly specifying the location for binaries as the following example:

${INSTALL_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:

${INSTALL_ROOT}/currentCellName

You have to use the -includeApps option to migrate all the applications to the new cell. 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.

Note: When the -includeapps parameter is specified, an OutOfMemoryError might occur if the Java Virtual Machine heap size isn't large enough. When this error ocurs, the following error message is issued:

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:

  1. Issue the cleanupNode.sh command on your deployment manager server. See cleanupNode command for more information about this command.

  2. Increase the JVM heap size for the addNode script. When you issue the addNode.sh command, the JVM heap size is set to -Xms128m -Xmx512m. To increase these values, edit the JVM_EXTRA_CMD_ARGS variable in the config_root/bin/setupCmdLine.sh file of the Base Application Server being federated. For example, you might specify the following (all on one line):

    JVM_EXTRA_CMD_ARGS= -Djava.security.properties=$WAS_HOME/java/jre/lib/security/
         java.security -Xms256m -Xmx1024m  

  3. Reissue the addNode.sh command.

-startingport <portNumber>

Supports the specification of a port number to use as the base port number for all node agent and Java Messaging Service (JMS) server ports created during the addNode command. With this support you can control which ports are defined for these servers, rather than using the default port values. The starting port number is incremented to calculate the port number for every node agent port and JMS server port configured during the addNode command.

-help

Prints a usage statement.

-?

Prints a usage statement.

Usage scenario

The following examples demonstrate correct syntax:

addNode testhost 8879

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.Example output:

D:\WebSphere\AppServer\bin>addnode <dmgr_host>
ADMU0116I: Tool information is being logged in file
           D:\WebSphere\AppServer\logs\addNode.log
ADMU0001I: Begin federation of node <node_name> with deployment manager at
				 <dmgr_host>:8879.
ADMU0009I: Successfully connected to deployment manager server: <dmgr_host>:8879.
ADMU0505I: Servers found in configuration:
ADMU0506I: Server name: server1
ADMU2010I: Stopping all server processes for node <node_name>
ADMU0512I: Server server1 cannot be reached. It appears to be stopped.
ADMU0024I: Deleting the old backup directory.
ADMU0015I: Backing up the original cell repository.
ADMU0012I: Creating node agent configuration for node: <node_name>
ADMU0014I: Adding node <node_name> configuration to cell: <cell_name>
ADMU0016I: Synchronizing configuration between node and cell.
ADMU0018I: Launching node agent process for node: <node_name>
ADMU0020I: Reading configuration for node agent process: nodeagent
ADMU0022I: Node agent launched. Waiting for initialization status.
ADMU0030I: Node agent initialization completed successfully. Process ID is:
           2340
ADMU0523I: Creating queue manager for node <node_name> on server jmsserver
ADMU0525I: Details of queue manager creation can be seen in the file:
           createMQ.<node_name>_jmsserver.log
ADMU9990I:
ADMU0300I: Congratulations! Your node <node_name> has been successfully
           incorporated into the <cell_name> cell.
ADMU9990I:
ADMU0306I: Be aware:
ADMU0302I: Any cell-level documents from the stand-alone <node_name>
configuration have not been migrated to the new cell.
ADMU0307I: You might want to:
ADMU0303I: Update the configuration on the <cell_name> deployment manager
           with values from the old cell-level documents.
ADMU9990I:
ADMU0306I: Be aware:
ADMU0304I: Because the -includeapps option was not specified, applications installed on
           the stand-alone node were not installed on the new cell.
ADMU0307I: You might want to:
ADMU0305I: Install applications onto the <cell_name>  cell using the wsadmin
           $AdminApp command or the administrative console.
ADMU9990I:
ADMU0003I: Node <node_name> has been successfully federated.


Related tasks
Establishing multimachine environments
Federating multiple V5 installation instances
Related reference
Best practices for adding nodes using command line tools
removeNode command