Starting and Stopping WebLogic Servers


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| Download Documentation \| Contact \| Glossary

\| WebLogic Server Doc Home \| Administration Guide \| Previous Topic \| Next Topic \| Contents \| Index \| View as PDF

The following sections describe procedures for starting and stopping Administration Servers and Managed Servers:

WebLogic Administration Server and WebLogic Managed Servers

A WebLogic Server domain may consist of one or more WebLogic Servers. WebLogic Server can be started as either an Administration Server or as a Managed Server. One (and no more than one) of the WebLogic Servers in a domain must be the Administration Server for the domain. Additional WebLogic Servers in the domain are managed servers. Whether a WebLogic Server is an Administration Server or a Managed Server depends on the command-line options used when starting the server.

The default role for a WebLogic Server is the Administration Server. Therefore, if there is only one WebLogic Server in a domain, that server is the Administration Server. In a multi-server domain, a WebLogic Server becomes a Managed Server only if it is instructed to obtain its configuration from a running Administration Server when started.

The Administration Server controls access to the configuration for a WebLogic Server domain and provides other management services such as monitoring and log message browsing. The Administration Server serves up the Administration Console which provides user access to the management services offered by the Administration Server.

When a WebLogic Managed Server is started, it obtains its configuration from the Administration Server. For this reason, booting a multi-server WebLogic Server domain is a two-step procedure: First you start the Administration Server, and then you start the Managed Servers.

Note: The Administration Server and all Managed Servers in a domain must be the same WebLogic Server version. The Administration Server must be either at the same service-pack level or at a later service-pack level than the Managed Servers. For example, if the Managed Servers are at release 6.1 SP1, then the Administration Server can be either release 6.1 SP1 or SP2. However, if the Managed Servers are at SP2, then the Administration Server must be at SP2. Each server must have a unique name — even if the servers are in different domains.

Startup Messages

When a WebLogic Server is starting, the normal logging subsystem is not yet available for logging. Accordingly, any errors encountered during startup are logged to stdout. If you start a Managed Server remotely from the Administration Console, using the Node Manager, these messages are also displayed in the right pane of the Administration Console.

Failover Considerations for the Administration Server

Because the Administration Server contains the configuration repository (config.xml), security files, and application files for your domain, you should keep an archived copy of these files in case a failure of the Administration Server causes them to become unavailable. Common methods of archiving include periodic back-ups, fault tolerant disks, and manually copying files whenever they are changed. Remember that any configuration changes you make to Weblogic Server, either by using the Administration Console, the weblogic.admin command, or the JMX API are persisted in the config.xml file.

To provide for quick failover in case of an Administration Server crash or other failure, you may wish to create another instance of the Administration Server on a different machine that will be ready to use if it the original Administartion Server fails.

As long as you have back ups of your configuration, security, and application files, you can safely restart the Administration Server on another machine without interrupting the functioning of the Managed Servers. For instructions, see Restarting the Administration Server when Managed Servers are Running.

Starting the WebLogic Administration Server

There are several ways in which the WebLogic Administration Server can be started:

From the command line
The command to start the WebLogic Server can be either typed in a command shell manually or it can be placed in a script to avoid retyping the command each time the server is started. For information on the sample scripts provided see Starting the WebLogic Managed Servers Using Scripts.
From the Start Menu (Windows only)
A WebLogic Server installed as a Windows service will start automatically when the computer is rebooted.

Note: When starting WebLogic Server, JDK 1.3 may throw an OutOfMemory error if you are trying to load a large number of classes. This error occurs even though there appears to be plenty of memory available. If you encounter a java.lang.OutOfMemory error exception when you start WebLogic Server, increase the value of the following JMS option:

java -XX:MaxPermSize=<value>

where <value> is some number in kilobytes.

For JDK1.3.0, the JVM default value for MaxPermSize is max value of 32m (where m stands for megabytes). For JDK1.3.1, the default value for MaxPermSize is 64m.

Use of Passwords When Starting the WebLogic Server

During installation you are asked to specify a password that will be required when the server is started. If you use start scripts to start an Administration Server or a Managed Server, you can include the password as a command-line argument (See Starting the WebLogic Administration Server from the Command Line.) If you start the server using a script without the password specified as a command-line argument, you will be prompted to enter the password. You can avoid being prompted if the password is specified as a command-line argument, but then the password will be stored in clear text in the script file.

Starting the WebLogic Administration Server from the Start Menu

If you installed WebLogic Server on Windows with the BEA Installation program, you can use the WebLogic Server shortcut on the Windows Start menu to start the WebLogic Administration Server. Select:

Start—>Programs—>BEA WebLogic E-Business Platform—>Weblogic Server Version—>Start Default Server

where version is the WebLogic Server software version number.

Invoking the WebLogic Server from the Start menu executes the start script startWeblogic.cmd (which is located in install_dir/config/domain_name where domain_name is the name of the domain and install_dir is the directory where you installed the WebLogic Server software). You will be prompted to enter the password.

Starting and Stopping the WebLogic Server as a Windows Service

When installed as a Windows service, the WebLogic Server starts automatically when you boot the Windows computer. The WebLogic Server is started by executing a start script such as startWeblogic.cmd. A WebLogic Server started using startWebLogic.cmd is started as an Administration Server. See Starting the WebLogic Administration Server from the Command Line.

To run the WebLogic Server as a Windows service, you must have installed it as such. For information on installing and removing the WebLogic Server as a Windows service, see Setting Up a WebLogic Server Instance as a Windows Service.

You can also stop and start the WebLogic Server easily from the Service Control Panel.

Select Start—>Settings—>Control Panel.
Double-click the Services Control Panel to open it.
In the Services Control Panel, scroll to the end to find WebLogic Server. If WebLogic is Started, you will have the option to Stop it when you select it, by clicking the Stop button to the right. If WebLogic is Stopped, the Start button will be available.

You can make the Windows service Automatic, Manual, or Disabled by clicking the Startup button and selecting a mode.

Starting the WebLogic Administration Server from the Command Line

The WebLogic Server is a Java class file, and like any Java application, you can start it with the java command. The arguments needed to start the WebLogic Server from the command line can be quite lengthy and typing it out whenever you need to start the server can be tedious. To make sure that your startup commands are accurate, BEA Systems recommends that you incorporate the command into a script that you can use whenever you want to start a WebLogic Server.

The following arguments are required when starting the WebLogic Administration Server from the java command line:

Specify the minimum and maximum values for Java heap memory.
For example, you may want to start the server with a default allocation of 64 megabytes of Java heap memory to the WebLogic Server. To do so, you can start the server with the java -ms64m and -mx64m options.

For best performance it is recommended that the minimum and maximum values be the same so that the JVM does not resize the heap.

The values assigned to these parameters can dramatically affect the performance of your WebLogic Server and are provided here only as general defaults. In a production environment you should carefully consider the correct memory heap size to use for your applications and environment.
Set the java -classpath option.
The minimum content for this option is described under Setting the Classpath Option.
Specify the name of the server.
The domain configuration specifies configuration by server name. To specify the name of the server on the command line, use the following argument:
```
-Dweblogic.Name=servername
```
The default value is myserver.
Specify the listen address of the server.
If you want to run Managed Servers on other machines in the same domain (or run the Administration Server and a Managed Server on a multi-homed machine) or start Managed Servers remotely using the Node Manager, you need to set the listen address of the Administration Server. To set the listen address, include the following argument:
```
-Dweblogic.ListenAddress=host
```
where host is the DNS name or IP address of the Administration Server.
Provide user password.
The default user is system and the required password is the password specified during installation. To enter the password, include the following argument:
```
-Dweblogic.management.password=password
```
Specify the WebLogic Server root directory if you do not want to use the current directory (that is, the directory from which you invoke the weblogic.Server command) as the server root directory. To specify a root directory, include the following argument:
```
-Dweblogic.RootDirectory=path
```
where path specifes the directory above the config\server-root directory.

For example, if a server's root directory is c:\myproject\config\Mydomain, then specify -Dweblogic.RootDirectory=c:\myproject. For more information, refer to A Server's Root Directory.
Specify the location of the bea.home directory:
```
-Dbea.home=root_install_dir
```
where root_install_dir is the root directory under which you installed the BEA WebLogic Server software.
If you want to start the server with Secure Socket Layer (SSL) protocol, you need to pass the server the private key password at startup so that the server can decrypt the SSL private key file. To pass the SSL private key password to the server on startup, include the following argument on the command line:
```
-Dweblogic.management.pkpassword=pkpassword
```
where pkpassword is the SLL private key password.

Note: When storing the password to the pkpassword.ini file, WebLogic Server encrypts the value using the encryption service associated with the domain. This means that you can use the password file only with the domain in which it was created.

Note: Secure a plain text copy of the private key password before you allow WebLogic Server to write the password to a file. You will not be able to retrieve the plain text password from pkpassword.ini after booting the server.
When using SSL, you can turn off host name verification. By default, the Host Name Verifier in WebLogic Server compares the SubjectDN of a digital certificate with the host name of the server that initiated the SSL connection. If the SubjectDN and the host name do not match, the SSL connection is dropped. Should you decide to turn off host name verification (for example, to use the demonstration digital certificates shipped with WebLogic Server) include the following argument on the command line:
```
-Dweblogic.security.SSL.ignoreHostnameVerification=true
```
Note that BEA does not recommend using the demonstration digital certificates or turning off host name verification in any type of production deployment.
To use a custom Host Name Verifier with WebLogic Server include the following argument on the command line:
```
-Dweblogic.security.SSL.HostnameVerififier=hostnameverifierimpl
mentation
```
where hostnameverifierimplmentation is the name of the class that implements the weblogic.security.SSL.HostnameVerifier interface.
SSL session caching is turned on by default. To modify the server-session caching default size and time-to-live, include the following arguments on the command line:
```
-Dweblogic.security.SSL.sessionCache.size=sessionCacheSize
-Dweblogic.security.SSL.sessionCache.ttl=sessionCacheTimeToLive
```
where sessionCacheSize is the size of the session cache and sessionCacheTimeToLive is the session cache time-to-live in seconds. The minimum, maximum, and default values for the two parameters are:

sessionCache.size: min 1, max 65537, default 211
sessionCache.ttl: min 1, max Integer.MAX_VALUE, default 90
You can specify the name of the domain configuration when starting the Administration Server by using the following argument on the command line:
```
-Dweblogic.Domain=domain_name
```
where domain_name is the name of the domain. This will also be the subdirectory which has the configuration file that will be used to boot the domain.

The configuration repository consists of the domains under the /config directory. The configuration repository may contain a variety of possible domain configurations. Each such domain is located under a separate subdirectory, with the subdirectory name being the name of that domain. When you specify domain_name you are thus specifying this subdirectory name. The subdirectory thus specified contains the XML configuration file (config.xml) and the security resources for that domain. The file config.xml specifies the configuration for that domain.

The domain configuration with which the Administration Server is started becomes the active domain. Only one domain can be active.
If you want to override the default WebLogic Server stream handler for HTTP and HTTPS protocols, create an implementation of java.net.URLStreamHandlerFactory and specify it on the command line like this:
-Dweblogic.net.http.URLStreamHandlerFactory=factory_class

The factory class must be specified on the command line because a factory can be set only once for each URL protocol per JVM instance. Your factory class must have a main() method which can perform any one-time initialization required, and then must call java.net.URL.setURLStreamHandlerFactory() with an instance of the class.

Your factory must implement the createURLStreamHandler() method, which returns an instance of your custom java.net.URLStreamHandler implementation for arguments of "http" and "https". For other all other protocols, it should return null. See the Javadocs for java.net.URL for details about how the URLStreamHandlerFactory is located.
You can also specify values for WebLogic Server configuration attributes on the command line. These values become the runtime value for that attribute, and any value stored in the persistent configuration is ignored. The format for setting a runtime value for a WebLogic Server attribute on the command line is:
```
-Dweblogic.attribute=value
```
The auto-deployment feature, which is turned on by default, does polling of the \applications directory of the active domain to detect changes in deployed applications. This feature only works on the Administration Server, because the AppManager thread that polls the applications directory for changes is only created on Administration servers. This feature is not recommended for use in a production environment. If you want to ensure that the Administration Server is started with the auto-deployment feature disabled, include the following argument on the command line:
```
-Dweblogic.ProductionModeEnabled=true
```
When you run the JSP compiler on Windows systems, output files names are always created with lower case names. To prevent this behavior, and preserve the case used in class names, set the system property, include the following argument on the command line:
```
-Dweblogic.jsp.windows.caseSensitive=true
```
See "Running JSPC on Windows Systems" in Programming WebLogic JSP.

Setting the Classpath Option

The following must be included as values to the -classpath option on the java command line:

If you have installed a WebLogic Server service pack, include the following file:
/weblogic/lib/weblogic_sp.jar
Depending on which WebLogic Server release, service pack, or patch that you have installed, this file might not exist on your system. Regardless of whether the file currently exists on your system, we recommend that you include weblogic/lib/weblogic_sp.jar on your classpath to ensure compatibility with any updates. You must add this file to the classpath before you add weblogic.jar.
/weblogic/lib/weblogic.jar
WebLogic Server comes with a trial version of an all-Java database management system (DBMS) called Cloudscape. If you will be using this DBMS, then you will need to include the following in the classpath:
/weblogic/samples/eval/cloudscape/lib/cloudscape.jar
If you will be using WebLogic Enterprise Connectivity, you will need to include the following:
/weblogic/lib/poolorb.jar

where weblogic is the directory where you installed WebLogic Server.

A Server's Root Directory

All instances of WebLogic Server use a root directory to store runtime data and to provide the context for any relative pathnames in the server's configuration. For example, if you specify ./MyLogFile as the name and location of a server's log file, then the server creates a file named MyLogFile in its root directory.

In addition, an Administration Server uses its root directory as a repository for the domain's configuration data (such as config.xml) and security resources (such as fileRealm.properties). See Figure 2-1.

Figure 2-1 Root Directory for WebLogic Server Instances

A server's root directory must be below a directory named config. For example, the following directories are valid root directories:

c:\config\MyManagedRootDir
c:\config\MyDomain

But c:\MyManagedRootDir is not.

By convention, the root directory for an Administration Server is named after the domain. For example, if the domain is named myDomain, the root directory for the Administration Server is c:\config\myDomain.

Multiple instances of WebLogic Server can use the same root directory. However, if your server instances share a root directory, make sure that all relative filenames are unique. For example, if two servers share a directory and they both specify .\MyLogFile, then each server instance will overwrite the other's .\MyLogFile.

By default, the directory from which you start a WebLogic Server instance is the server's root directory. For example, if you run the weblogic.Server command from c:\config\MyDomain, then c:\config\MyDomain is the root directory.

If you want to start a server instance from a location other than the server's root directory, you can specify a different location by passing the following argument to the weblogic.Server startup command:

-Dweblogic.RootDirectory=path

where path specifes the directory above the config\server-root directory.

For example, if a server's root directory is c:\myproject\config\Mydomain, then specify -Dweblogic.RootDirectory=c:\myproject.

To make it easier to maintain your domain configurations and applications across upgrades of WebLogic Server software, it is recommended that the root directory not be the same as the installation directory for the WebLogic Server software.

Starting the Administration Server Using a Script

Sample scripts are provided with the WebLogic Server distribution that you can use to start WebLogic Servers. You will need to modify these scripts to fit your environment and applications. Separate sample scripts are provided for starting the Administration Server and the Managed Server. The scripts for starting the Administration Server are called startWebLogic.sh (UNIX) and startWeblogic.cmd (Windows). These scripts are located in the configuration subdirectory for your domain.

To use the supplied scripts:

Pay close attention to classpath settings and directory names.
Change the value of the variable JAVA_HOME to the location of your JDK.
UNIX users must change the permissions of the sample UNIX script to make the file executable. For example:
```
chmod +x startWebLogic.sh
```
If you are going to run a Managed Server in the same domain on another machine (or on a multi-homed machine with the Administration Server), or want to be able to start and kill Managed Servers using the Node Manager, you will need to edit the WebLogic Server startup command by adding the argument to set the listen address of the Administration Server:
```
-Dweblogic.ListenAddress=host
```
where host is the DNS name or IP address of the Administration Server.

Restarting the Administration Server when Managed Servers are Running

For a typical production system it is recommended that you not deploy applications containing your critical business logic on the Administration Server. In such a scenario, the role of the Administration Server is that of configuring and monitoring the Managed Servers. If the Administration Server should become unavailable in such a configuration, the applications running on the Managed Servers can continue to process client requests.

When the Administration Server is started, it makes a copy of the configuration file that was used to boot the active domain. This is saved in the file

install_dir/config/domain_name/config.xml.booted

where install_dir is the directory where you installed the WebLogic Server software and domain_name is the name of the domain. The Administration Server creates the config.xml.booted file only after it has successfully completed its startup sequence and is ready to process requests.

You should make a copy of this file so that you have a working configuration file that you can revert to if you need to back out of changes made to the active configuration from the Administration Console.

If the Administration Server goes down while Managed Servers continue to run, you do not need to restart the Managed Servers that are already running in order to recover management of the domain. The procedure for recovering management of an active domain depends upon whether you can restart the Administration Server on the same machine it was running on when the domain was started.

Restarting the Administration Server on the Same Machine

If you restart the WebLogic Administration Server while Managed Servers continue to run, the Administration Server can detect the presence of the running Managed Servers if you instruct the Administration Server to perform a discovery. To instruct the Administration Server to do a discovery of Managed Servers, enter the following argument on the command line when starting the Administration Server:

-Dweblogic.management.discover=true

The default value of this attribute is true. (If you omit this property, the Administration Servers still executes the discovery. Make sure, however, that this property is either not defined or not set to false in the command line you use to start WebLogic Server.) The configuration directory for the domain contains a file running-managed-servers.xml which is a list of the Managed Servers that the Administration Server knows about. When the Administration Server is instructed to perform discovery upon startup, it uses this list to check for the presence of running Managed Servers.

Restart of the Administration Server does not update the runtime configuration of the Managed Servers to take account of any changes made to attributes that can only be configured statically. WebLogic Servers must be restarted to take account of changes to static configuration attributes. Discovery of the Managed Servers does enable the Administration Server to monitor the Managed Servers or make runtime changes in attributes that can be configured dynamically.

Restarting the Administration Server on Another Machine

If a machine crash prevents you from restarting the Administration Server on the same machine, you can recover management of the running Managed Servers as follows:

Install the WebLogic Server software on the new administration machine (if this has not already been done).
Note: If you do not have Service Pack 2 of WebLogic Server 6.1 installed, the new administration machine must have the same host name as the machine that hosted the failed Administration Server.
Make your application files available to the new Administration Server by copying them from backups or by using a shared disk. Your application files should be available in the same relative location on the new file system as on the file system of the original Administration Server.
Make your configuration and security files available to the new administration machine by copying them from backups or by using a shared disk. These files are located in the /config/myDomain directory of the Administration Server, where myDomain is the name of the domain being managed by the Administration Server.
Restart the Administration Server on the new machine with the addition of the following argument on the command line:
```
-Dweblogic.management.discover=true
```
This argument will force the Administration Server to discover the presence of the Managed Servers that are running. (If you omit this property, the Administration Servers still executes the discovery. Make sure, however, that this property is either not defined or not set to false in the command line you use to start WebLogic Server.)

When the Administration Server starts, it communicates with the managed servers and informs them that the Administration Server is now running on a different IP address.

Server Startup Process

When you start a WebLogic Server, it takes the following actions:

Retrieves its configuration and bootstrap security data.
An Administration Server retrieves the configuration and security data from the domain's configuration files. A Managed Server contacts the Administration Server for its configuration and security data. If you set up SSL, a Managed Server uses its own set of certificate files, key files, and other SSL-related files and contacts the Administration Server for the remaining configuration and security data.
Starts its kernel-level services, which include logging and timer services.

Initializes subsystem-level services, which retrieve their configurations from MBeans. These services include the following:

Security Service
RMI Service
Cluster Service
IIOP Service
Naming Service
RMI Naming Service
File Service

JCA Container
JDBC Container
EJB Container
Web Container
Deployment Manager
JMS Provider
Remote Management
Transaction Service

Deploys modules in the appropriate container and in the order that you specify in the WebLogic Server Administration Console.
Loads and runs any startup classes that are configured.

Adding a WebLogic Managed Server to the Domain

Before you can run a WebLogic Server as a managed server, you must first create an entry for that server in the configuration for the domain. To do this, do the following:

Start the Administration Server for the domain.
Invoke the Administration Console by pointing your browser at http://hostname:port/console, where hostname is the name of the machine where the Administration Server is running and port is the listen port number that you have configured for the Administration Server (default is 7001).
Create an entry for the server machine (Machines—>Create a new machine) (if it is different than the Administration Server machine).
Create an entry for the new server (Servers—>Create a new server). Set the machine for this Managed Server to the machine you just created an entry for. Each server must have a unique name — even if the servers are in different domains.

For more information on configuring servers, see Configuring WebLogic Servers and Clusters.

Starting a WebLogic Managed Server

WebLogic Managed Servers can be started in either of the following ways:

Remotely from the Administration Console, using a Node Manager on the target machine where the Managed Server needs to be started.
Locally, by invoking the server on the java command line in a command shell.

This section discusses how to start the WebLogic Managed Server locally. For information on setting up and using the Node Manager to start Managed Servers remotely, see Node Manager.

Note: If you right click on the name of a server in the left pane of the Administration Console, one of the options is Start this server.... This option can only be used to start a Managed Server if you have a Node Manager running on the machine where the Managed Server is located. For more information, see Node Manager.

Once you have added WebLogic Managed Servers to your configuration (see Adding a WebLogic Managed Server to the Domain), you can start the Managed Servers from the java command line. The command to start the WebLogic Server can be either typed in a command shell manually or it can be placed in a script to avoid retyping the command each time the server is started. For information on the sample scripts provided see Starting the WebLogic Managed Servers Using Scripts.

The main way in which the startup parameters for a Managed Server differ from an Administration Server is that you need to provide an argument that identifies the location of the Administration Server from which the Managed Server requests its configuration. A WebLogic Server started without this parameter runs as an Administration Server.

When starting a WebLogic Managed Server, you need to specify the parameters that you would specify when starting an Administration Server (see Starting the WebLogic Administration Server from the Command Line) but with the addition of the following:

Specify the name of the server.
When a WebLogic Managed Server requests its configuration information from the Administration Server, it identifies itself to the Administration Server by server name. This enables the Administration Server to respond with the appropriate configuration for that WebLogic Server. For this reason, you must also set the server name when starting a managed server. This can be specified by adding the following argument to the command line when starting the WebLogic Managed Server:
```
-Dweblogic.Name=servername
```
Specify the host name and listen port of the WebLogic Administration Server
When starting a managed server, it is necessary to specify the host name and listen port of the Administration Server from which the managed server is to request its configuration. This can be specified by adding the following argument to the command line when starting the managed server:
```
-Dweblogic.management.server=host:port
```
or
```
-Dweblogic.management.server=http://host:port
```
where host is the name or IP address of the machine where the Administration Server is running and port is the Administration Server's listen port. By default the Administration Server's listen port is 7001.

If you are using Secure Socket Layer (SSL) for communication with the Administration Server, the Administration Server must be specified as:
```
-Dweblogic.management.server=https://host:port
```
To use SSL protocol in communication between the Managed Servers and the Administration Server, you need to enable SSL on the Administration Server. For details on how to set this up, see Managing Security.

Note: Any WebLogic Server that is started without specifying the location of the Administration Server is started as an Administration Server.

Note: Because the Managed Server receives its configuration from the Administration Server, the Administration Server specified must be in the same domain as the Managed Server.

Informational Thread Dumps When Starting Clusters

If a Managed Server is configured as follows, it prints an informational thread dump to standard out during its startup cycle:

Is a member of a cluster
Prints messages of severity INFO and higher to standard out
(Specifed in the Administration Console on the Server > Logging > General tab.)
Logs remote exceptions
(Specified in the Administration Console on the Server > Logging > Debugging tab.)

The thread dump is similar to the following abbreviated example:

Starting Cluster Service ....

<Nov 9, 2001 4:23:19 PM CST> <Info> <Connector> <Initializing J2EE Connector Service> <Nov 9, 2001 4:23:20 PM CST> <Info> <Dispatcher> <Exception thrown by rmi server: 'weblogic.rmi.cluster.ReplicaAwareServerRef@9 - jvmid: '-5643957423891326779S:10.1.2.151:[7001,7001,7002,7002,7001,7002, -1]:***specific server***', oid: '9', implementation: 'weblogic.jndi.internal.RootNamingNode@28c19b'' javax.naming.NameNotFoundException: Unable to resolve weblogic.transaction.resources.Server01. Resolved: 'weblogic.transaction.resources' Unresolved:'Server01' ; remaining name '' at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException (BasicNamingNode.java:802) at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode .java:209) at weblogic.jndi.internal.ServerNamingNode.lookupHere(ServerNamingNo de.java:129) . . .

If the Administration Server prints messages of INFO severity to standard out and logs remote exceptions, it prints thread dumps while members of clusters are starting.

You can ignore these thread dumps; they do not indicate an error in your configuration.

Note: The log files do not contain this or other thread dumps.

Starting the WebLogic Managed Servers Using Scripts

Sample scripts are provided with the WebLogic Server distribution that you can use to start WebLogic Servers. You will need to modify these scripts to fit your environment and applications. Separate scripts are provided for starting the Administration Server and the Managed Server. The sample scripts to start Managed Servers are called startManagedWebLogic.sh (UNIX) and startManagedWebLogic.cmd (Windows). These scripts are located in the configuration subdirectory for your domain. These are templates that you will need to modify to create your own start scripts.

To use the supplied scripts:

Pay close attention to classpath settings and directory names.
Change the value of the variable JAVA_HOME to the location of your JDK.
UNIX users must change the permissions of the sample UNIX script to make the file executable. For example:
```
chmod +x startManagedWebLogic.sh
```

There are two ways to start the Managed Server using the script:

If you set the value of the environment variables SERVER_NAME and ADMIN_URL, you do not need to provide these as arguments when invoking the start script. SERVER_NAME should be set to the name of the WebLogic Managed Server that you wish to start. ADMIN_URL should be set to point to the host (host name or IP address) and port number where the Administration Server is listening for requests (default is 7001). For example:
```
set SERVER_NAME=bigguy
set ADMIN_URL=peach:7001
startManagedWebLogic
```
You can invoke the start script and pass the name of the Managed Server and the URL for Administration Server on the command line:
```
startManagedWebLogic server_name admin:url
```
where server_name is the name of the Managed Server you are starting and admin_url is either http://host:port or https://host:port where host is the host name (or IP address) of the Administration Server and port is the port number for the Administration Server.

Stopping WebLogic Servers from the Administration Console

If you right click on a server in the left pane of the Administration Console, you will see two options, Kill this server... and Stop this server.... If you select the Kill this server... option, the Administration Server sends a request to the Node Manager running on the machine where the Managed Server is running. The Node Manager then kills the target WebLogic Server process. The Kill this server... option cannot be used to shut down the Administration Server. The Kill this server... option assumes you have a Node Manager running on the machine where the target Managed Server is. For information on setting up and starting Node Manager, see Node Manager.

If you select the Stop this server... option, the Administration Server sends an administrative shutdown request to the selected server. The Node Manager is not used in that case. Unlike the Kill this server... option, the Stop this server... option can be used to shutdown the Administration Server.

Because the Stop this server... option uses the administrative capability of a Managed Server to initiate a shutdown, it can only be used if the server is alive and responding to administrative requests. The Kill this server... option would be typically used in situations where the target Managed Server is hung or not responding to administrative requests from the Administration Server.

Shutting Down a Server from the Command Line

You can also shut down a WebLogic Server from the command line with the following command:

java weblogic.Admin -url host:port SHUTDOWN -username adminname 
-password password

where:

host is the name or IP address of the machine where the WebLogic Server is running.
port is the WebLogic Server's listen port (default is 7001).
adminname designates a user that is a member of the Console Access Control List (ACL) (or a member of a group that is a member of the Console ACL) for the target WebLogic Server. Default member of the Console ACL is system.
password is the password for adminname.

Setting Up a WebLogic Server Instance as a Windows Service

If you want a WebLogic Server instance to start automatically when you boot a Windows host, you can set up the server as a Windows service.

For each server that you set up as a Windows service, WebLogic Server creates a key in the Windows Registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. The registry entry contains such information as the name of the server and other startup arguments. When you start the Windows host, it passes the information in the registry to the JVM.

Before you can set up a server instance to run as a Windows service, you must create the server in a domain.

The following tasks describe setting up and managing WebLogic Server Windows services:

Setting Up Windows Services: Main Steps

The following main steps assume that you created at least one WebLogic Server instance in the default domain that is installed with WebLogic Server:

In the default Windows-service installation script, specify the name of the Windows Service, the name of the server instance, and the WebLogic Server password for starting the server instance. For more information, refer to Specifying the Name of the Server Instance and the Windows Service.
If you are installing a Managed Server as a Windows service, add a command option that specifies the location of the domain's Administration Server. For more information, refer to Specifying the Location of the Administration Server.
If you set up both an Administration Server and a Managed Server to run as Windows services on the same computer, make sure the Managed Server starts only after the Administration Server finishes its startup cycle. For more information, refer to Require Managed Servers to Start After the Administration Server.
If you want a server instance to shut down gracefully when you use the Windows Control Panel to stop the Windows service, include a command option that causes a server instance to shut down gracefully. For more information, refer to Enabling Graceful Shutdowns from the Windows Control Panel.
If you want to see the messages that a server instance prints to standard out and standard error (including stack traces and thread dumps), redirect standard out and standard error to a file. For more information, refer to Redirecting Standard Out and Standard Error to a File.
If you have created additional Java classes that you want the WebLogic Server instance to invoke, add them to the server's classpath. For more information, refer to Adding Classes to the Classpath.
Run the Windows service installation script. For more information, refer to Run the Installation Script.

Specifying the Name of the Server Instance and the Windows Service

To specify the name of the server instance that you want to run as a Windows service:

Make a backup copy of weblogic\config\mydomain\installNTService.cmd (where weblogic is the directory where WebLogic Server was installed and mydomain is the domain you created when you installed WebLogic Server).
Open installNTService.cmd in a text editor.
In the line that starts with set CMDLINE=, change the value of -Dweblogic.Name= to specify the name of the server that you want to start as a Windows service. For example, -Dweblogic.Name=myserver.
The last command in the script invokes the beasvc utility. In this command, do the following:
1. Change the value of -svcname to specify a unique name for the service. For example, use the name of the domain and server instance: -svcname:mydomain_myserver
2. At the end of the beasvc command, append -password:password where password is the password for the system user.
  When you install the Windows service, the beasvc utilty encrypts the password and stores the encrypted value in the Windows registry. After you finish installing this server as a Windows service, remove the password from the installNTService.cmd script.
  
  The modified beasvc command will resemble the following command:
  
  "D:\bea\wlserver6.1\bin\beasvc" -install-svcname:mydomain_myserver-javahome:"D:\bea\jdk131" -execdir:"D:\bea\wlserver6.1" -extrapath:"D:\bea\wlserver6.1\bin" -cmdline:%CMDLINE%-password:weblogic

Specifying the Location of the Administration Server

If you are installing a Managed Server as a Windows service, you must modify the installNTService.cmd script so that it specifies the location of the Administration Server. A Managed Server must contact the Administration Server to receive its configuration information.

To specify the location of the Administration Server:

Open installNTService.cmd in a text editor.
In the line that starts with set CMDLINE=, add the following argument after the -Dweblogic.Name argument:
-Dweblogic.management.server=http://host:port
where host is the name or IP address of the machine where the Administration Server is running and port is the Administration Server's listen port

If you are using Secure Socket Layer (SSL) for communication with the Administration Server, the Administration Server must be specified as:

-Dweblogic.management.server=https://host:port

Require Managed Servers to Start After the Administration Server

If you set up both an Administration Server and a Managed Server to run as Windows services on the same computer, you can specify that the Managed Server starts only after the Administration Server.

To require a Managed Server to start after the Administration Server Windows service:

Make a backup copy of weblogic\config\mydomain\installNTService.cmd (where weblogic is the directory where WebLogic Server was installed and mydomain is the domain you created when you installed WebLogic Server).
If you have already installed the Administration Server as a Windows Service, remove the service. For more information, refer to Removing WebLogic Server as a Windows Service.
Before you install (or reinstall) the Administration Server as a Windows Service, do the following:
1. In a text editor, open the weblogic\config\mydomain\installNTService.cmd script.
2. Add the following argument to the command that invokes the beasvc utility:
  -delay:delay_milliseconds
This specifies the number of milliseconds to wait before the Windows Service Control Manager (SCM) changes the service status from SERVER_START_PENDING to STARTED.

For example, if your Administration Server requires 2 minutes to complete its startup cycle and begin listening for requests, then specify -delay=120000. When you boot the Windows host computer, the Windows SCM reports a status of SERVER_START_PENDING for 2 minutes. Then it changes the status to STARTED.

The modified beasvc invocation for the Administration Server will resemble the following:

"D:\bea\wlserver6.1\bin\beasvc" -install -svcname:mydomain_myAdminServer -javahome:"D:\bea\jdk131"-delay:120000-execdir:"D:\bea\wlserver6.1" -extrapath:"D:\bea\wlserver6.1\bin" -cmdline:%CMDLINE%

For more information about beasvc, enter the following command at a command prompt: weblogic\server\bin\beasvc -help, where weblogic is the directory in which you installed WebLogic Server.
Install the Administration Server Windows service.
Before you install the Managed Server as a Windows service, do the following:
1. In a text editor, open the weblogic\config\mydomain\installNTService.cmd script.
2. Add the following argument to the command that invokes the beasvc utility:
  -depend:Administration-Server-service-name
  
  where Administration-Server-service-name is the name of the Administration Server Windows service. To verify the service name, look on the Windows Services Control Panel.
With this option, the Windows SCM will wait for the Administration Server Windows service to report a status of STARTED before it starts the Managed Server Windows service.

For example, the modified beasvc invocation for the Managed Server will resemble the following:

"D:\bea\wlserver6.1\bin\beasvc" -install -svcname:mydomain_myManagedServer -javahome:"D:\bea\jdk131"-depend:"mydomain_myAdminServer"-execdir:"D:\bea\wlserver6.1" -extrapath:"D:\bea\wlserver6.1\bin" -cmdline:%CMDLINE%

You can also add the -delay:delay_milliseconds option to a Managed Server Windows service if you want to configure when the Windows SCM reports a status of STARTED for the service.

Enabling Graceful Shutdowns from the Windows Control Panel

By default, if you use the Windows Control Panel to stop a server instance, the Windows Service Control Manager (SCM) kills the server's Java Virtual Machine (JVM). If you kill the JVM, the server immediately stops all processing. Any session data is lost. If you kill the JVM for an Administration Server while the server is writing to the config.xml file, you can corrupt the config.xml file.

To enable graceful shutdowns from the Windows Control Panel:

In a text editor, open the weblogic\config\mydomain\installNTService.cmd script.
Add the following argument to the command that invokes the beasvc utility:
-stopclass:weblogic.Server

With this argument, when you stop a server Windows service from the Windows Control Panel, the Windows SCM invokes the stop() method of the server's ServerRuntime MBean. This management method gracefully shuts down a server.

For example, the modified beasvc invocation for the server instance will resemble the following:

"D:\bea\wlserver6.1\bin\beasvc" -install -svcname:mydomain_myserver -javahome:"D:\bea\jdk131"-stopclass:weblogic.Server-execdir:"D:\bea\wlserver6.1" -extrapath:"D:\bea\wlserver6.1\bin" -cmdline:%CMDLINE%

For more information about beasvc, enter the following command at a command prompt: weblogic\server\bin\beasvc -help, where weblogic is the directory in which you installed WebLogic Server.
Consider modifying the default timeout value that the Windows SCM specifies.
By default, when you use the Windows 2000 Control Panel to stop a Windows service, the Windows SCM waits 30 seconds for the service to stop before it kills the service and prints a timeout message to the System event log.

If you use -stopclass to gracefully shut down a server, 30 seconds might not be enough time for the server to gracefully end its processing.

To configure a timeout period on Windows 2000, create a REG_DWORD registry value named ServicesPipeTimeout under the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control

The key value must be in milliseconds.

This value is read from the registry during the startup of the Windows operating system and it affects all services that are installed.
Save your changes to the installNTService.cmd script.

Redirecting Standard Out and Standard Error to a File

By default, when you install a WebLogic Server instance as a Windows service, you cannot see the messages that the server or JVM print to standard out and standard error.

To view these messages for a server instance that is installed as a Windows service, you must redirect standard out and standard error to a file:

Open installNTService.cmd in a text editor.
In installNTService.cmd, the last command in the script invokes the beasvc utility. At the end of the beasvc command, append the following command option:
-log:"pathname "
where pathname is a fully qualified path and filename of the file that you want to store the server's standard out and standard error messages.

The modified beasvc command will resemble the following command:

"D:\bea\wlserver6.1\bin\beasvc" -install -svcname:mydomain_myserver -javahome:"D:\bea\jdk131" -execdir:"D:\bea\wlserver6.1" -extrapath:"D:\bea\wlserver6.1\bin" -cmdline:%CMDLINE% -password:weblogic-log:"d:\bea\wlserver6.1\config\mydomain\myserver-stdout.txt
By default, every 24 hours the Windows service archives messages to a file named pathname-yyyy_mm_dd-hh_mm_ss. New messages collect in the file that you specified in the previous step.
For information on changing the default behavior, see Changing the Default Rotation Criteria.

After you install the service and restart the Windows host, to view the messages that the server and JVM write to standard out or standard error, do one of the following:

Make a copy of the file that you specified and view the copy. The Windows file system cannot write to files that are currently opened.
To view the messages as they are being printed to the file, open a command prompt and use the DOS command tail -f stdout-filename.

Changing the Default Rotation Criteria

By default, every 24 hours the Windows service archives messages to a file named pathname-yyyy_mm_dd-hh_mm_ss. New messages collect in the file that you specified when you set up the service.

You can change the time interval or you can set up rotation to occur based on the size of the message file instead of a time interval.

To change the default criteria at which the Windows service rotates message files:

If the Windows service is running, shut it down.
Edit the file you specified in the -log: pathname argument. If a file does not exist, create one.
For example, if you issued the example command in step 2. in the previous section, create a file named d:\bea\wlserver6.1\config\mydomain\myserver-stdout.txt.
Do one of the following:
- If you want the Windows service to rotate the message file at a specific time interval regardless of file size, add the following statements at the top of the file, each statement on a separate line (make sure to press the Enter or Return key after typing the last line):
  # ROTATION_TYPE = TIME # TIME_START_DATE =date-in-required-format
  # TIME_INTERVAL_MINS = number-of-minutes
  where TIME_START_DATE specifies when the first rotation should take place. If the specified time has already passed, the first rotation occurs when the time interval specified in TIME_INTERVAL_MINS expires. You must use the following format to specify the start time: Month Day Year Hour:Minutes:Seconds
  where Month is the first 3 letters of a Gregorian-calendar month as written in English
  Day is the 2-digit day of the Gregorian-calendar month
  Year is the 4-digit year of the Gregorian calendar
  Hour:Minutes:Seconds expresses time in a 24-hour format
  
  and TIME_INTERVAL_MINS specifies how frequently (in minutes) the Windows service rotates the file.
  
  For example:
  # ROTATION_TYPE = TIME # TIME_START_DATE = Jul 17 2003 05:25:30 # TIME_INTERVAL_MINS = 1440
  
  When the time interval expires, the Windows service saves the file as pathname-yyyy_mm_dd-hh_mm_ss. It then creates a new file named pathname. This new file, which contains all of the headers that you specified originally, collects new standard out and standard error messages.
  
  If you specify # ROTATION_TYPE = TIME but do not include the other lines, the Windows service rotates the message file every 24 hours.
- If you want the Windows service to rotate the message file after the file grows beyond a specified size, add the following statements at the top of the file, each statement on its own line (make sure to press the Enter or Return key after typing the last line):
  # ROTATION_TYPE = SIZE # SIZE_KB =file-size-in-kilobytes
  # SIZE_TRIGGER_INTERVAL_MINS = polling-interval
  
  where SIZE_KB specifies the minimal file size (in kilobytes) that triggers the Windows service to move messages to a separate file.
  
  and SIZE_TRIGGER_INTERVAL_MINS specifies (in minutes) how frequently the Windows service checks the file size. If you do not include this header, the Windows service checks the file size every 5 minutes.
  
  For example:
  # ROTATION_TYPE = SIZE # SIZE_KB = 1024 # SIZE_TRIGGER_INTERVAL_MINS = 3
  
  When the Windows service checks the file size, if the file is larger than the size you specify, it saves the file as pathname-yyyy_mm_dd-hh_mm_ss. It then creates a new file named pathname. This new file, which contains all of the headers that you specified originally, collects new standard out and standard error messages.
  
  If you specify # ROTATION_TYPE = SIZE but do not include the other lines, the Windows Service checks the size of the message file every 5 minutes. If the file is larger than 1 megabytes, it rotates the file.

Printing Thread Dumps to Standard Out

To cause the WebLogic Server instance to print a thread dump to standard out, do either of the following:

Use the weblogic.Admin THREAD_DUMP command. For more information, refer to THREAD_DUMP.
Open a command prompt and enter the following command:
weblogic\bin\beasvc -dump -svcname:service-name
where weblogic is the directory in which you installed WebLogic Server and
service-name is the Windows service that is running a server instance.

For example:
D:\bea\wlserver6.1\bin\beasvc -dump -svcname:mydomain_myserver

Adding Classes to the Classpath

The classpath is a declaration of the location of Java classes that a JVM can invoke. When you install a server instance as a Windows service, the installNTService.cmd script specifies all classes required to run a server instance. If you want to extend WebLogic Server by adding your own Java classes, you must add them to the classpath.

To add classes to the classpath:

Make a backup copy of weblogic\config\mydomain\installNTService.cmd (where weblogic is the directory where WebLogic Server was installed and mydomain is the domain you created when you installed WebLogic Server).
Open installNTService.cmd in a text editor.
In the line that starts with set CLASSPATH statement, add your Java classes.
For example if you archived your class in a file named c:\myJar, the modified statement will be as follows:
set CLASSPATH=.;D:\bea\wlserver6.1\lib\weblogic_sp.jar;D:\bea\wlserver6.1\lib\weblogic.jar;c:\myJar

Note: Win32 systems have a 2K limitation on the length of the command line. If the classpath setting for the Windows service startup is very long, the 2K limitation could be exceeded.

To work around this limitation:
1. Place the value of the set CLASSPATH command in a separate text file and save the text file in the weblogic\server\bin directory.
2. In the weblogic\config\mydomain\installNTService.cmd script, find the set CMDLINE command.
3. Within the set CMDLINE command, replace the -classpath \"%CLASSPATH%\" option with the following option:
  -classpath @filenamewhere filename is the name of the file that contains the classpath values.
  
  For example:
  
  set CMDLINE="-ms64m -mx64m -classpath @myClasspath.txt-Dweblogic.Domain=mydomain -Dweblogic.Name=myserver -Djava.security.policy==\"D:\bea\wlserver6.1/lib/weblogic.policy\" -Dbea.home=\"D:\bea\" weblogic.Server"
Save your changes to the installNTService.cmd script.

Run the Installation Script

Open a command prompt and change to weblogic\config\mydomain.
Enter installNTService.cmd.
The command prompt runs the script as a batch file.

If the script runs successfully, it creates a Windows service named
DOMAIN_NAME_SERVER_NAME and prints a line to standard out that is similar to the following:
mydomain_myserver installed.

By default, standard out is the command prompt in which you run the server-specific batch file.
Remove your password from the installNTService.cmd script. Leaving this password on the filesystem in an unencrypted format opens a security vulnerability.

Removing WebLogic Server as a Windows Service

To remove the WebLogic Server as a Windows service, do the following:

Navigate to the weblogic\config\mydomain directory (where weblogic is the directory where WebLogic Server was installed and mydomain is the subdirectory with your domain's configuration).
Open the script uninstallNTService.cmd in a text editor.
Change the value of -svcname: to specify the name of the service that you want to remove.
Save and execute uninstallNTService.cmd.

Changing Passwords for a Server Installed as a Windows Service

If you install the Default Server as a Windows service, the system password that you entered during installation of the WebLogic Server software is used when creating the service. If this password is later changed, you must do the following:

Uninstall the WebLogic Server as a Windows service using the uninstallNTService.cmd script (located in the directory install_dir/config/domain_name where install_dir is the directory where you installed the product).

The installNTservice.cmd script contains the following command:

rem *** Install the service
"C:\bea\wlserver6.1\bin\beasvc" -install -svcname:myserver 
-javahome:"C:\bea\jdk130" -execdir:"C:\bea\wlserver6.1" 
-extrapath:"C\bea\wlserver6.0\bin" -cmdline: 
%CMDLINE%

You must append the following to the command:

-password:"your_password"

where your_password is the new password.

Execute the modified installNTservice.cmd script. This will create a new service with the updated password.

Registering Startup and Shutdown Classes

WebLogic Server provides a mechanism for performing tasks whenever a WebLogic Server starts up or gracefully shuts down. A startup class is a Java program that is automatically loaded and executed when a WebLogic Server is started or restarted. For more information about when a server loads and runs startup classes, refer to Server Startup Process.

Shutdown classes work the same way as startup classes. A shutdown class is automatically loaded and executed when the WebLogic Server is shut down either from the Administration Console or using the weblogic.admin shutdown command.

In order for your WebLogic Servers to use startup or shutdown classes, it is necessary to register these classes, which you can do from the Administration Console.

You can register a startup or shutdown class by doing the following:

Access the Startup & Shutdown table from the domain tree (in the left pane) in the Administration Console. This table provides options for creating entries for shutdown or startup classes in the domain configuration.
Provide the class name and necessary arguments, if any, on the Configuration tab page for the startup or shutdown class you are adding.

See the Administration Console Online Help for more information on: