Services Pool (GWS Only)

When you define a Web Service application, you specify execution parameters that determine the number of Virtual Machines (DVMs) that can be available to service a request for that Web Service. These parameters are defined in the Application Server configuration file.

When you define a Web Service application, the EXECUTION element sets the runtime environment for that application by specifying the parameters for executing the Web Service application. This application configuration can either reference a predefined SERVICE_APPLICATION_EXECUTION_COMPONENT (and inherit the runtime environment settings defined for that component) or the individual execution elements can be explicitly set for the application.

Within the EXECUTION element, the POOL element sets the limitations regarding the number of DVMs that are attached to a Web Service.

• The START element specifies the number of Virtual Machines to start when the Genero Application Server starts.

• The MIN_AVAILABLE element specifies the minimum number of Virtual Machines to have alive while the Genero Application Server is running.

• The MAX_AVAILABLE element specifies the maximum number of Virtual Machines to have alive while the Genero Application Server is running.

• The MAX_REQUESTS_PER_DVM element specifies the maximum number of requests a DVM can handle before to be stopped by the pool manager.

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.

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. If the web services load is large for the previous period, the DVMs are not released as rapidly as they are when the incoming requests are spread over time, yet eventually they are released to reach the amount specified by MIN_AVAILABLE. For 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.

On the other hand, as more requests come in, the GWS proxy determines whether there is a need to start up new DVMs. The GWS proxy computes the average request execution time, the time to start a DVM, and it knows the number of pending requests in the queue -- so 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.

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

What happens when there are MAX_AVAILABLE DVMs actively processing requests, and a new requests 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 defines its own timeout before to break if the response is not coming. If a client is willing to wait indefinitely for a Web Service response, it is permitted.

For 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.