Sun Java System Web Server 6.1 SP11 Administrator's Guide

Chapter 8 Configuring Server Preferences

This chapter describes how to configure server preferences for your Sun Java System Web Server.

This chapter contains the following sections:

Starting and Stopping the Server

Once the server is installed, it runs constantly, listening for and accepting HTTP requests.

The status of the server appears in the Server On/Off page. You can start and stop the server using one of the following methods:

After you shut down the server, it might take a few seconds for the server to complete its shut-down process and for its status to change to “Off.”

If your machine crashes or is taken offline, the server stops and some of the requests being serviced can be lost.

Note –

If you have a security module installed on your server, enter the appropriate passwords before starting or stopping the server.

Note –

On a UNIX platform, some Sun Java System Web Server installations may require access to a large amount of memory and/or file descriptors than allowed by default. If you are unable to start the server, check the resource limits imposed by your operating system using the ulimit command. The operating system’s ulimit man page should provide more information.

Setting the Termination Timeout

When the server is turned off, it cannot accept new connections. It then waits for all outstanding connections to complete. The time the server waits before timing out is configurable in the magnus.conf file, which can be found in server_root/https-server_name/config/. By default it is set to 30 seconds. To change the value, add the following line to magnus.conf:

TerminateTimeout seconds

where seconds represents the number of seconds the server waits before timing out.

The advantages to configuring this value is that the server will wait longer for connections to complete. However, because servers often have connections open from nonresponsive clients, increasing the termination timeout may increase the time it takes for the server to shut down.

Restarting the Server (UNIX/Linux)

To restart the server use one of the following methods:

Because the installation scripts cannot edit the /etc/rc.local and /etc/inittab files, you must edit these files with a text editor. If you do not know how to edit these files, consult your system administrator or system documentation.

Typically, you cannot start an SSL-enabled server with either of these files because the server requires a password before starting. Although you can start an SSL-enabled server automatically if you keep the password in plain text in a file, this practice is not recommended.

Caution – Caution –

Leaving the SSL-enabled server’s password in plain text in the server’s start script is a large security risk. Anyone who can access the file has access to the SSL-enabled server’s password. Consider the security risks before storing the SSL-enabled server’s password in plain text.

The server’s start script, key pair file, and the key password should all be owned by root (or, if a non-root user installed the server, that user account), with only the owner having read and write access to these files.

Starting SSL-enabled Servers Automatically

If security risks are not a concern for you,

ProcedureTo start your SSL-enabled server automatically

  1. Using a text editor open the start file located in the server_root/https-server_id.

  2. Locate the -start line in the script and insert the following:

    echo "password"|

    where password is the SSL password you have chosen.

    For example, if the SSL password is netscape, the edited line might look like this:


    echo "netscape"|./$PRODUCT_BIN -d $PRODUCT_SUBDIR/config $@

Restarting the Server with the Inittab (UNIX/Linux)

To restart the server using inittab, include the following text on one line in the /etc/inittab file:

http:23:respawn:server_root/type-identifier/start -start -i

where server_root is the directory where you installed the server, and type-identifier is the server’s directory.

The -i option prevents the server from putting itself in a background process.

Remove this line before you stop the server.

Restarting With the System RC Scripts (UNIX/Linux)

If you use the /etc/rc.local, or your system’s equivalent, place the following line in the /etc/rc.local:


Replace the server_root with the name of the directory in which you installed the server.

Restarting the Server Manually (UNIX/Linux)

To restart the server from the command line, log in as root if the server runs on ports with numbers lower than 1024; Alternatively, log in as root or with the server’s user account. At the command-line prompt, type the following line and press Enter:


where server_root is the directory where you installed the server.

You can use the optional parameter -i at the end of the line. The -i option runs the server in inittab mode, so that if the server process is ever killed or crashed, the inittab will restart the server. This option also prevents the server from putting itself in a background process.

Note –

If the server is already running, the start command fails. You must stop the server first, then use the start command. If the server fail to start, you should kill the process before trying to restart it.

Stopping the Server Manually (UNIX/Linux)

If you used the etc/inittab file to restart the server you must remove the line starting the server from /etc/inittab and type kill -1 1 before you try to stop the server. Otherwise, the server restarts automatically after it is stopped.

To stop the server manually, log in as root or use the server’s user account (if that is how you started the server), and then type the following at the command line:


Restarting the Server (Windows)

Restart the server using the Services Control Panel in one of the following ways:

ProcedureTo restart the server

  1. From the Control Panel double-click the Services icon.

  2. Scroll through the list of services and select the service for your server.

  3. Select Automatic to start the server each time the computer starts or reboots.

  4. Click OK.

    Note –

    You can also use the Services dialog box to change the Server's account. For more information about changing the Server's account, see Changing the User Account (UNIX/Linux).

    By default, the web server prompts the administrator for the key database password before starting up. If you want to be able to restart an unattended web server, you need to save the password in a password.conf file. Only do this if your system is adequately protected so that this file and the key databases are not compromised.

Using the Automatic Restart Utility (Windows)

The server is automatically restarted by a server-monitoring utility if the server crashes. On systems that have debugging tools installed, a dialog box with debugging information appears if the server crashes. To help debug server plug-in API programs (for example, NSAPI programs), disable the auto-start feature by setting a high timeout value. Also turn off the debugging dialog boxes by using the Registry Editor.

Changing the Time Interval (Windows)

To change the time interval for the server between startup and automatic restart, perform the following steps:

  1. Start the Registry Editor.

  2. Select your server’s key (in the left side of the Registry Editor window, located in HKEY_LOCAL_MACHINE\SOFTWARE\Netscape\Enterprise\6.0).

  3. Choose Add Value from the Edit menu. The Add Key dialog box appears.

  4. In Value Name, type MortalityTimeSecs.

  5. Select REG_DWORD from the Data Type drop-down list.

  6. Click OK. The DWORD Editor dialog box appears.

  7. Type the time interval (in seconds) between startup and automatic restart.

    The interval can be in binary, decimal, or hexadecimal format.

  8. Click the numerical format for the value you entered in the previous step (binary, decimal, or hexadecimal).

  9. Click OK.

    The MortalityTimeSecs value appears in hexadecimal format at the right side of the Registry Editor window.

Turning Off the Debugging Dialog Box (Windows)

If you installed an application (such as a compiler) that has modified system debugging settings and the server crashes, you might see a system-generated application error dialog box. The server will not restart until you click OK.

ProcedureTo turn off the debugging dialog box

  1. Start the Registry Editor.

  2. Select the AeDebug key, located in the left side of the Registry window in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion.

  3. Double-click the Auto value in the right side of the window.

    The String Editor dialog box appears.

  4. Change the string value to 1.

Tuning Your Server for Performance

You can tune the thread limit in one of two ways, through editing the magnus.conf file and through the Server Manager.

If you edit the magnus.conf file, RqThrottleMinPerSocket as the minimum value and RqThrottle is the maximum value.

The minimum limit is a goal for how many threads the server attempts to keep in the WaitingThreads state. This number is just a goal. The number of actual threads in this state may go slightly above or below this value. The default value is 48. The maximum threads represents a hard limit for the maximum number of active threads that can run simultaneously, which can become a bottleneck for performance. The default value is 128.

ProcedureTo tune your server for performance using Server Manager

  1. Go to the Preferences tab.

  2. Click the Performance Tuning link.

  3. Enter the value in the Maximum simultaneous requests field.

    For more information about the RqThrottleMinPerSocket and RqThrottle parameters, see the Sun Java System Web Server 6.1 SP11 Administrator’s Configuration File Reference.

    For detailed information about the performance implications of these settings and others, see the Sun Java System Web Server 6.1 SP11 Performance Tuning, Sizing, and Scaling Guide.

Editing the magnus.conf File

When the Sun Java System Web Server starts, it scans the magnus.conf file in the server_root/server_id/config directory to establish a set of global variable settings that define the server’s behavior and configuration. Sun Java System Web Server executes all the directives defined in magnus.conf. You can edit certain settings in the magnus.conf file using the Magus Editor in the Server Manager.

For a complete description of the magnus.conf file and information about editing the file using a text editor, see the Sun Java System Web Server 6.1 SP11 Administrator’s Configuration File Reference and the Sun Java System Web Server 6.1 SP11 NSAPI Programmer’s Guide.

ProcedureTo access the Magnus Editor

  1. Access the Server Manager and choose the Preferences tab.

  2. Click the Magnus Editor link.

  3. Select the settings to edit from the drop-down list and click Manage.

    The Server Manager displays the editor for the settings you specified.

  4. Make the desired changes to the settings and click OK.

    For more information about each Settings page, see the Magnus Editor page in the online help.

Adding and Editing Listen Sockets

Before the server can process a request, it must accept the request via a listen socket, then direct the request to the correct virtual server. When you install the Sun Java System Web Server, one listen socket, ls1, is created automatically. This listen socket uses the IP address and the port number you specified as your HTTP server port number during installation (the default is 80). You cannot delete the default listen socket.

You can edit your server’s listen socket settings using the Server Manager’s Listen Sockets Table.

ProcedureTo access the table

  1. Access the Server Manager and click the Preferences tab.

  2. Click the Edit Listen Sockets link.

  3. Make the required changes and click OK.

Choosing MIME Types

You can edit your Server's MIME files from the Mime Types page.

MIME (Multi-purpose Internet Mail Extension) types control the types of multimedia files your mail system supports. MIME types also specify the file extensions that belong to specific server file types. For example it helps to designate which files are CGI programs.

You don’t need to create a separate MIME types file for each virtual server. Instead, you create as many MIME types files as you need and associate these files with a virtual server. The mime.types file, exists by default on the server, and cannot be deleted. This file can be the absolute path.

ProcedureTo access the MIME Types page

  1. Access the Server Manager and click the Preferences tab.

  2. Click the MIME Types link.

  3. Make the desired changes and click OK.

    For more information, see the MIME Types page in the online help and Chapter 14, Using Virtual Servers.

Restricting Access

You can control access to the entire server or to parts of the server (that is, directories, files, file types) using the Server Manager’s Restrict Access page. When the server evaluates an incoming request, it determines access based on a hierarchy of rules called access-control entries (ACEs). It uses the matching entries to determine whether to allow or deny the request. Each ACE specifies whether or not the server should continue to the next ACE in the hierarchy. The collection of ACEs is called an access-control list (ACL). When a request is received by the server, the server looks in the vsclass file.obj.conf (where vsclass is the virtual server class name) for a reference to an ACL, which is then used to determine access. By default, the server has one ACL file that contains multiple ACLs.

You can configure access control globally for all servers through the Administration Server or for a resource within a specific server instance through the Server Manager. For more information about setting access control for a resource, see Setting Access Control.

Note –

Turn on distributed administration before you can restrict server access.

ProcedureTo restrict access to your Sun Java System Web Servers

  1. Access the Server Manager and choose the Preferences tab.

  2. Click the Restrict Access link.

    For more information, see Chapter 10, Controlling Access to Your Server. Also see Restrict Access page in the online help.

Restoring Configuration Settings

The Restore Configuration page allows you to view a backup copy of your configuration files and revert to the configuration data saved on a specific date.

Caution – Caution –

On Windows, use this page only to roll back changes to the configuration files. Do not roll back to backup versions created during installation these may not be complete.

For more information, see the Restore Configuration page in the online help.

Configuring the File Cache

The Sun Java System Web Server uses a file cache to serve static information faster. In the previous version of the server, there was also an accelerator cache which routed requests to the file cache. The accelerator cache is no longer used. The file cache contains information about files, and static file content. The file cache also caches information that is used to speed up processing of server-parsed HTML.

The file cache is turned on by default. The file cache settings are contained in the nsfc.conf file. You can use the Server Manager to change the file cache settings.

For more information, see the online Performance Tuning and Sizing Guide on

Adding and Using Thread Pools

You can use thread pools to allocate a specific number of threads to a specific service.

You can also use thread pools to runn thread-unsafe plugins. By defining a pool with the maximum number of threads set to 1, only one request is allowed into the specified service function.

When you add a thread pool, the specified information includes the minimum and maximum number of threads, the stack size, and the queue size.

For more information, see the online Performance Tuning and Sizing Guide on

The Native Thread Pool and Generic Thread Pools (Windows)

On Windows, you can use two types of thread pools: the native thread pool (NativePool) and additional generic thread pools.

To edit the native thread pool, access The Native Thread Pool Page (NT) in the Server Manager.

You can create any number of generic thread pools . To create generic thread pools, access The Generic Thread Pools Page (NT) in the Server Manager.

Thread Pools (UNIX/Linux)

Since threads on UNIX/Linux are always OS-scheduled (as opposed to user-scheduled) UNIX/Linux users do not need to use the NativePool, and do not have a Server Manager page for editing its settings. However, UNIX/Linux users can still create thread pools. To create thread pools, access The Thread Pools Page (UNIX/Linux) in the Server Manager.

Editing Thread Pools

Once you have added a thread pool, you can change the values of the thread pool settings (minimum threads, maximum threads and so on) through the Server Manager.

You can also edit the thread pool settings in vsclass.obj.conf, where vsclass is the virtual server class name.

A thread pool appears in the vsclass.obj.conf as follows:

Init fn="thread-pool-init" name=name_of_the_pool MaxThreads=n MinThreads=n QueueSize=n StackSize=n

Use the parameters to change the pool MinThreads, MaxThreads, QueueSize, and StackSize.

Windows users can edit the native pool settings using the Server Manager.

Using Thread Pools

After you set up a thread pool, you use it by designating it as the thread pool for a specific service.

To configure a thread pool, go to the Server Manager Preferences tab and select Thread Pool. Once a thread pool is configured, it is available to be used for the specific designated service.

You can also designate a thread pool by using the pool parameter of the load-modules function in vsclass.obj.conf, where vsclass is the virtual server class name.


In addition, you can use the pool parameter on any NSAPI function so that only that NSAPI function runs on the specified pool.