Zero socket opener (ZSO) management extensions

Overview

The ZSO enables many applications to be available and ready for client connections, while at the same time releasing the resources for applications that are not currently in use. The runtime memory requirements of a ZSO process is orders of magnitude smaller than required by a running Java runtime. The advantages of using ZSO include:

• Allowing an application to be available for connections, without permanently using the resources required by the Java runtime.
• Starting the WebSphere sMash applications hosted by the Java runtime on demand when a connection is initiated by a client.
• Allowing tens or hundreds of WebSphere sMash applications to be available, while those applications not in use consume almost no resources.
• Enforcing the short lived runtime life-cycle of a WebSphere sMash application.

Setting the idle timeout or the maximum requests parameters

When the ZSO starts, it opens a socket listener and waits for an incoming connection. When a client connects, it starts the Java runtime to host the WebSphere sMash application. Once the Java runtime is started, it continues to run and responds to all connections, bypassing the ZSO process.

To take advantage of the ZSO, the WebSphere sMash application must be configured to shut down the Java runtime, to release resources and to allow control of the open socket back to the ZSO process. It is important to remember that, though the JVM is shutdown, the application is still running and available to service requests. This can be done by either setting an idle timeout or a maximum request configuration parameter. The default values use for these parameters will be based on whether the application is in development or production mode.

Setting the Mode of the application

WebSphere sMash applications will use a different set of default values for recycling a JVM behind a ZSO, depending on the Mode of the application. The purpose of Mode is to allow applications still being developed to have their JVMs recycled much more often that what might be appropriate in a production environment. This will assist the developer in understanding how their application will behave in the production environment when recycles do occur.

The Mode of the application is determined by the /config/runtime/mode parameter. The value of this parameter can either be "production" or "development". If the value is set to neither of these two values, then the default location of idle timeout and maximum request will be used.

For example, to change your application to use the development mode characteristics, add the following to your configuration:

/config/runtime/mode = "development"

Idle Timeout

The idle timeout allows the Java runtime of a WebSphere sMash application to be stopped whenever there is an idle period when the application is not servicing requests. For example, if the idle time is 60 seconds then the application shuts down if there are no incoming client connections after a period of 60 seconds.

The following are the default values, depending on whether the application is in development or production mode. If the application is in an unknown mode, the last value will be used. All parameters are in seconds since last completed request:

/config/zso/recycle/production/idleTimeout = 300
/config/zso/recycle/development/idleTimeout = 60
/config/zso/recycle/idleTimeout = 300

Using a value of -1 will disable the idleTimeout recycle timer, for instances where only a maxRequests recycle is desired.

Maximum Requests

The maximum requests parameter allows the Java runtime to be stopped whenever the total number of requests processed by the application has been reached. Once the maximum number of requests has been reached, the Java runtime stops and control passes back to the ZSO process.

When the maximum number has been reached, all current requests that have entered processing are allowed to complete and all new requests received are queued by the socket listener. If the server is currently being flooded with many requests, the Java runtime is halted. In this case, the ZSO process restarts the Java runtime because there are still requests to be processed.

The following are the default values, depending on whether the application is in development or production mode. If the application is in an unknown mode, the last value will be used:

/config/zso/recycle/production/maxRequests = 10000
/config/zso/recycle/development/maxRequests = 300
/config/zso/recycle/maxRequests = 10000

Using a value of -1 will disable the maxRequests recycle counter, for instances where only an idleTimeout is desired.

Disabling Recycle

If there is a need in your application to disable all automatic recycling, it is possible to do so. To disable all recycling, add the following to your application's configuration:

/config/zso/recycle/enable = false 

Enabling Immediate Start

By default, the ZSO allows conservation of resources by not starting the Java runtime until there is an incoming request. But, under some circumstances, that may not be the desired behavior. For example, if your application includes a daemon that must be running as soon as the user starts the application. Under these conditions, it is desirable for the Java runtime to be started at the same time as the ZSO.

It is possible to achieve this by enabling immediate start. When immediate start is enabled, the ZSO will not wait for an incoming request before starting the Java runtime. Instead, it start it immediately, and restart it immediately on any recycle. All of the connection queuing functionality of the ZSO is still used, meaning an application can recycle the application and not loose any requests. To enable immediate start, add the following to your application's configuration:

/config/zso/immediateStart = true

Starting, Stopping, and Restarting the Application

The ZSO process can be started with the following command from the root of your application:

zero start

The ZSO process is started in the background and the JVM starts when a request for the application is made.

To stop the application, stop the JVM and the ZSO process, use the stop command from the management CLI extensions:

zero stop

You might want to restart the JVM to clean its state. To restart the JVM, use the recycle command from the management CLI extensions:

zero recycle