Services Pool (GWS Only)

Requests for Web services are processed by the GWS proxy and are managed using the DVM pool. The examples will assist you in configuring the pool element of your Web service.

Why do we need Services Pool for GWS?

The main reason is due to the way the Dynamic Virtual Machines (DVM) is unable to support more than one application at a time, see Reliability inherent in the architecture. The GWS proxy needs to launch new DVM (fglrun process) for each request on the Web server. If traffic to a Web server was to become very high with, for example, hundreds of requests at any period, this could potentially result in slow response time or even overloading of the server.

To avoid unnecessary use of resources, therefore, and to respond as fast as possible to client requests, the GWS proxy manages DVM processes in a pool. From the pool it can release inactive DVMs or launch new ones when required; up to the maximum number of DVM processes specified for the application. These parameters are defined in the POOL element of the Application Server configuration file.

Important: When sticky mode is used, the POOL is disregarded. For instance, the MAX_AVAILABLE setting, limiting the number of DVMs available to the GWS, is no longer taken into account. Therefore, it is recommended to handle the stopping of the sticky Web service in your application code with a dedicated method to be called by the user agent when it needs to close the session.

Releasing DVMs not Actively Processing Requests

Genero Web Service DVMs are not shutdown immediately after they stop processing requests. Instead DVM shutdown is optimized by the gwsproxy from request statistics and frequency of use that best determine the use of resources at runtime. The gwsproxy calculates this based on a combination of the following factors:

Time to Start a New DVM: The gwsproxy waits at least the time it takes to start a new DVM before deciding if a DVM can be shutdown.
Three Times the Last Request Execution Time: If their is only one request, a DVM shutdown takes place after waiting three times the request execution time from when the last request took place.
Three Times the Average Request Frequency: If there is more than one request, a DVM is shutdown after waiting three times the average request frequency. For example, the GWS proxy calculates the elapsed time since it received the last new incoming request. If this is three times greater than the average frequency of new requests it has been receiving, it stops one inactive DVM.

The time to shutdown a DVM will therefore vary depending on how great the Web service's request load has been for the previous period but eventually DVMs are released to reach the value specified by MIN_AVAILABLE because the gwsproxy calculation is also bound by a minimum (one second) and a maximum (ten minutes) limit.

Minimum (one second): If time to shutdown is less than one second, the gwsproxy waits a full one second before shutting down the DVM.
Maximum (ten minutes): If time to shutdown is more than ten minutes, the gwsproxy waits no longer than ten minutes before shutting down a DVM.

Understand DVM_AVAILABLE

The Web service invalidation feature will mark an service's configuration as bad if the gwsproxy cannot start a DVM within the time set by DVM_AVAILABLE. Once the service's configuration is marked as bad, that service will not be accessible until the issue has been addressed by an administrator. If DVM_AVAILABLE is being reached due to activity on the system that is not related to the Web service (a nighttime backup, for example), you will need to make adjustments to keep your service's configuration from being marked as bad. This could include

Increasing the time allowed to start the DVM by increasing DVM_AVAILABLE.
Removing KEEP_ALIVE (or setting it to a large value) to ensure that the gwsproxy does not shut down, allowing the MIN_AVAILABLE DVMs to remain active.
Setting up an automated job to fix the invalid configuration issues behind-the-scenes.

See Web service invalidation for details on correcting a configuration identified as bad.

Example 1: One GWSProxy Starts three DVMs

Assume the following values have been specified for a Web service application:

<POOL>
  <START>3</START>
  <MIN_AVAILABLE>2</MIN_AVAILABLE>
  <MAX_AVAILABLE>5</MAX_AVAILABLE>
</POOL>

When the Genero Application Server first starts, the START element defines how many DVMs to start for a particular Web service. There is one GWSProxy in charge of the pool of DVMs for the Web service. For our example, this means that one GWSProxy will launch three DVMs.

The figure shows one GWSProxy launching three DVMs.

Example 2: GWSProxy Releases Inactive DVMs

While the START element defines the number of DVMs to start initially, DVMs that are not actively processing requests can be released based on GAS statistics. For example, the GWS proxy calculates the elapsed time since it received the last new incoming request. If this is three times greater than the average frequency of new requests it has been receiving, it stops one inactive DVM. See Releasing DVMs not Actively Processing Requests.

Continuing with our example, if all of the DVMs are not actively processing requests, then one DVM will eventually be released, bringing the total number of DVMs to the MIN_AVAILABLE amount of two.

The figure shows one GWSProxy launching / managing two DVMs, the limit being set by MIN_AVAILABLE configuration parameter.

Example 3: GWSProxy Launches new DVMs when Required up to MAX_AVAILABLE

As requests come in, the GWS proxy determines whether there is a need to start up new DVMs. For the number of pending requests in the queue, the GWS proxy computes the average request execution time against the time to start a DVM. If dispatching all pending requests over the active DVMs takes less time than starting a new DVM, no new DVM will be started. In other words, a new DVM will only be started if it will help to decrease the waiting time of all pending requests. At most, MAX_AVAILABLE DVMs can be started.

Continuing with our example, up to five DVMs can be launched to handle requests.

The figure shows one GWSProxy launching / managing six DVMs, the limit being set by MAX_AVAILABLE configuration parameter.

Example 4: GWSProxy Managing a Connection Queue

What happens when there are MAX_AVAILABLE DVMs actively processing requests, and a new request comes in? The new request is placed in a connection queue, waiting for a DVM to become available. The new requests could (in theory) be waiting indefinitely, except:

There is the option of a timeout in the Web server to handle infinite wait.
Any Web service client can define its own timeout limit. If a client is willing to wait indefinitely for a Web service response, it is permitted.

Continuing with our example, this means that if all five DVMs are actively processing requests, and a sixth requests comes in, that request is placed in the connection queue until a DVM is available to process the request, or a timeout is reached based on settings in either the Web server or the Web service client.

The figure shows one GWSProxy launching / managing five DVMs. In addition, the Connection Queue joins the workflow at the GWSProxy.