InfoCenter Home >
6: Administer applications >
6.6: Tools and resources quick reference >
6.6.46: Administering WebSphere administrative servers (overview)

6.6.46: Administering WebSphere administrative servers (overview)

The administrative server manages configurations and states of application servers, applications, and other resources in the WebSphere administrative domain. It keeps its administrative data in a database that you define during product installation.

Configuring the administrative server and database

There are a couple of ways to configure the administrative server, and provide information about its administrative database.

Administrative configuration file

The administrative server obtains its own configuration from the properties in the administrative configuration file. Some values are set during product installation, while others are primarily for modification later.

New properties added for 4.0.x and later

Three new properties have been added to WebSphere Application Server, including:

  • com.ibm.ejs.sm.adminServer.asyncTaskThreadPoolSize=<integer_value>
  • com.ibm.ejs.sm.adminService.verboseLogging=1
  • com.ibm.ejs.adminService.waitForTimeOut=<number_of_seconds>

The com.ibm.ejs.sm.adminServer.asyncTaskThreadPoolSize=<integer_value> property allows you to control the number of threads in the Asyncronous Task Engine thread pool. The default value is 5. One aspect of tuning this thread pool size is that it affects the number of application servers that can be started at one time. You should be conservative in setting this property because it uses a lot of memory.

The com.ibm.ejs.sm.adminService.verboseLogging=1 property causes the administrative service to produce additional entries in the Windows Application Event log when the value is set to non-zero.

The com.ibm.ejs.adminService.waitForTimeOut=<number_of_seconds> property sets the number of seconds that the administrative service waits for the administrative server to tell it that all application servers have completed their startup. The default value is zero, which means that the administrative services do not time out. The former default timeout value for the administrative service is 8 minutes. This is only true on Windows platforms.

Using SQL Server as the administrative repository

To use SQL Server as the WebSphere Application Server administrative repository, ensure that you have the WebSphere Application Server database in your SQL Server. To create the Enterprise Manager in SQL server, complete the following steps:

  1. Go to the Enterprise Manager in SQL server and create a user EJSADMIN for the WebSphere Application Server database with password EJSADMIN and database administrator privileges.
  2. Create a user EJB on this database with password EJB and administrative privileges. The default server in WebSphere Application Server uses these users.
Adding Java command line arguments for the administrative server

The admin.config file contains many administrative server properties you can set. In addition, you might want to pass the administrative server some generic Java command line arguments.

In the admin.config file, add the properties and their values as arguments on the com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs property. Add them using standard Java command line syntax:

-D property_name=property_value

For example, this setting passes performance-related Java parameters to the Java process constituting the administrative server:

com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs=-ms32m -mx128m

The admin.config file contains both default properties that apply to most configurations and non-default properties.

You should be conservative when setting this value. In testing on a desktop workstation, memory depletion or Java virtual machine crashes were observed when the thread pool size was set to 10.

Creating the database tables and default configuration

In most cases (see below for special cases), the administrative database tables are created, and populated with a default configuration, when you install WebSphere Application Server. During product installation, you must provide information regarding the administrative database you would like the installation's administrative server to use.

Settings in the administrative configuration file record the database information, and determine whether the database tables are created and (or) populated with the default configuration.

Special cases requiring additional steps after product installation

In some cases, the database tables are not created automatically during product installation, or the tables are not populated with the default configuration. If you need to, trigger the actions manually by setting properties in the administrative configuration file and starting the administrative server again.

  Users of WebSphere Application Server Advanced Edition Version 4.0 on Solaris and AIX operating systems with an Oracle database as the administrative database should note the following. In those cases, the default server is not created when you start the administrative server for the first time after installing the product. To create the default server and other default resources, set:

install.initial.config=true
in the administrative configuration file and start the administrative again.

  If you use an Oracle database user ID other than EJSADMIN, the default value assigned during the WebSphere Application Server installation, you must edit the administrative configuration file.

Ensure that the user ID and schema lines reflect your actual database user ID and password:

com.ibm.ejs.sm.adminServer.dbuser=your_user_name
com.ibm.ejs.sm.adminServer.dbSchema=your_schema_name

Then start the administrative server.

  If you use Sybase Version 12.5 as your database, you must change the default value assigned during the WebSphere Application Server installation in two places, the administrative configuration file and the applicable setupCmdLine (.bat or .sh) script file.

Edit the product_installation/bin/admin.config file to point to the Sybase 12.5 driver instead of the Sybase 12.0 driver. Change the setting from:

 com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs=<sybase_home>/jConnect-5_2/classes/jconn2.jar
To:
com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs=<sybase_home>/jConnect-5_5/classes/jconn2.jar

Edit the DBDRIVER_JARS property in the product_installation/bin/setupcmdline command shell. Change the setting from:

DBDRIVER_JARS=<sybase_home>/jConnect-5_2/classes/jconn2.jar
To:
DBDRIVER_JARS=<sybase_home>/jConnect-5_5/classes/jconn2.jar

Then start the administrative server.

Establishing centralized administration

Multiple administrative servers can be configured to use the same administrative database, allowing configuration data to be kept in a centralized place for administration of WebSphere Application Server across multiple machines (known as administrative nodes). In a successful multiple node configuration, the administrative console tree view will show each of the administrative nodes and its contents.

Configuring the 2nd through Nth machine in a cluster

Do not create the database tables or populate them with the default configuration.

When you are setting up a cluster of administrative nodes, only the WebSphere application server product installation needs to install the default configuration:

  1. On the first machine, ensure that the database tables have been created, and populated with the configurations for the default resources. In the administrative configuration file, this means:
    install.initial.config=true
    com.ibm.ejs.adminServer.createTables=true
    
  2. On all subsequent machines sharing the same administrative database, ensure the database tables are not created and the default resources are not installed a second time.
    install.initial.config=false
    com.ibm.ejs.adminServer.createTables=false
    

If you have already installed the second (or later) machine, with install.initial.config set to true, then the problem should work itself out after all machines in the cluster have been shut down and started again. Until then, you might notice these problems:

  • Absence of the WebSphere Administrative Domain resource in the tree view of the administrative console, or other peculiarities in the administrative topology
  • Administrative server on the second or later machine will throw exceptions when you first start it
Configuring a remote DB2 database as the administrative database

  If the administrative server is going to store its administrative data in a remote DB2 database, you need to catalog the remote database. See your database documentation for instructions.

Setting the dbserverName and dbportNumber for the data source (flags in the administrative configuration file) is not working in the case of a remote DB2 database. For example, if you have the application server and the DB2 client is installed on one machine, and are trying to connect the client to the DB2 server on another machine.

This problem could be overcome in a subsequent WebSphere Application Server fix. Be sure to consult the release notes for each fix to see whether the problem is fixed.

What to do if you must drop the administrative database tables

If you must drop the tables in the administrative database for some reason, then reset the pertinent settings in the administrative configuration file to create the tables again.

You will always need to set:

com.ibm.ejs.adminServer.createTables=true

If the machine is the first machine in a cluster of machines sharing an administrative database, then populate it with the default configuration:

install.initial.config=true

When you start the administrative server again, the settings will be applied.

Miscellaneous topics

The remainder of this article discusses miscellaneous topics pertaining to the administrative server and database.

Backup copies of admin.config

Note, commented out lines in admin.config will be removed completely when the administrative server starts.

It is recommended you periodically save a backup copy of admin.config. For example, you might delete lines that you want to restore later.

Configuring the nanny process

On UNIX-based systems, the nanny process tries to start an administrative server when the administrative server fails. The nanny settings are available in the admin.config file for the administrative server that the nanny is tending.

Go to previous article: Manually updating the Domino Web server configuration file Go to next article: Administrative server configuration file properties

 

 
Go to previous article: Manually updating the Domino Web server configuration file Go to next article: Administrative server configuration file properties