Zero socket opener (ZSO) management extensions

How ZSO extensions work

The ZSO extension works in a similar way to the inetd daemon on other operating systems. It opens a listening socket and, when a client connects to that listening port, the WebSphere sMash application associated with that port is started to accept the connection.

The ZSO extension 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 for a ZSO process is much smaller than the memory requirements for running Java runtime. The advantages of using the ZSO extension 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.

When 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. When the Java runtime is started, it continues to run and responds to all connections, bypassing the ZSO process.

To take advantage of the ZSO extension, 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. This can be done by either setting the idle timeout or Setting a maximum request configuration parameter. The default values for these parameters are based on whether the application is in development or production mode.

Setting the mode of the application

WebSphere sMash applications use a different set of default values for recycling a JVM behind a ZSO, depending on the mode of the application. The purpose of the mode setting is to allow applications still being developed to recycle the JVMs much more often than what might be appropriate in a production environment. This helps you to determine how the application behaves 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 is either production, development or user defined.

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

/config/runtime/mode = "development"

Setting the 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 example shows the default values, in seconds since last completed request, depending on whether the application is in development, production or user defined mode.

# development mode
/config/zso/recycle/idleTimeout = 60

# production or user defined mode
/config/zso/recycle/idleTimeout = 300

If the application is in an unknown mode, the default value is used. Using a value of -1 disables the idleTimeout recycle timer, if you only want a maxRequests recycle.

Setting a maximum request configuration parameter

The maximum requests parameter allows the Java runtime to be stopped whenever the total number of requests processed by the application has been reached. When 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 example shows the default values, depending on whether the application is in development, production or user defined mode.

# development mode
/config/zso/recycle/maxRequests = 300

# production or user defined mode
/config/zso/recycle/maxRequests = 100000

If the application is in an unknown mode, the default value is used. Using a value of -1 disables the maxRequests recycle counter, if you only want an idleTimeout.

Disabling recycling

You can disable all automatic recycling for your application. To disable all recycling, add the following line to the configuration for your application:

/config/zso/recycle/enable = false 

How parallel recycling works

Parallel recycling allows the ZSO to detect when an instance of the JVM is about to recycle. After detecting the recycle notification, the ZSO starts another instance of the application JVM prior to stopping the original instance. When using parallel recycling, there is a slight decrease in performance to gain resource utilization.

If parallel recycling is disabled, there is a potential pause in request processing when the Java runtime recycles. The pause lasts from the time the Java runtime readies itself for recycling to the time the ZSO starts a new Java runtime in place of the old Java runtime.

If parallel recycling is enabled, there is no pause in request processing when a Java runtime recycles because the ZSO detects that the Java runtime is going to recycle prior to the actual event. After detecting the pending recycle, the ZSO starts a new Java runtime prior to the exit of the original Java runtime process. The cost of enabling parallel recycling is that for a short period of time there are two Java runtimes running concurrently, thus using more memory.

Parallel recycling does have some limitations to consider. It can not be used in applications that hold state or use libraries that hold state not managed WebSphere sMash. An example of a popular library that does not work with parallel recycling is Embedded Derby. (Network Server Derby works, but Embedded Derby does not.)

Enabling Parallel Recycling

To enable parallel recycling add the following line to the configuration for the application:

/config/zso/recycle/inParallel=true

Enabling immediate start

By default, the ZSO conserves resources by not starting the Java runtime until there is an incoming request. But, under some circumstances, you might not want that default behavior, for example, if your application includes a daemon that must be running as soon as the user starts the application. Under these conditions, you would want the Java runtime to be started at the same time as the ZSO.

You can achieve this by enabling the immediate start function. When immediate start is enabled, the ZSO does not wait for an incoming request before starting the Java runtime. Instead, it starts it immediately, and restarts 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 the immediate start function, add the following line to the configuration for your application:

/config/zso/immediateStart = true

Starting, stopping, and restarting the application

You can start the ZSO process by issuing the following command from the root of your application:

zero start

The ZSO process starts 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