Back to Contents | GAS Configuration File Overview
Timeout components provide instruction on how the Genero Application Server (GAS) or Web service responds after a specific period of time has passed, providing mechanisms to react to time-based events (such as user inactivity or the time it takes to start a new application). Each timeout element specifies the number of seconds to wait prior to having the application server perform the task related to the timeout element. A timeout is fired when the specific condition is met.
Timeout elements can be defined for either:
Within the COMPONENT_LIST element of the Genero Application Server configuration file, you can define timeout components (a WEB_APPLICATION_TIMEOUT_COMPONENT or SERVICE_APPLICATION_TIMEOUT_COMPONENT) that can later be referenced when configuring an application, in order to set the timeout values for the application. Individual timeout elements can then be overwritten within the application's configuration itself.
The WEB_APPLICATION_TIMEOUT_COMPONENT element creates a Web application timeout component, which define a set of timeout values to be used when configuring a Web application. It takes an attribute Id, which specifies the unique identifier for this set of timeout definitions. It is this unique identifier that is referenced by an application, providing that application with a base set of timeout values.
Why are Web application timeouts necessary? When a Front End client connects to a DVM via the Genero Application Server (GAS), the connection between the Front End client and the GAS is not persistent (although the connection between the GAS and the DVM is persistent). The Genero Application Server needs the timeout settings to determine whether these components have remained alive and that communication can continue between the two.
The Front End client can send two types of requests to the DVM: a POST request when sending data to the DVM and a GET request when asking whether there is data to retrieve. The Genero Application Server, however, cannot send a request to the Front End client because the Front End client does not have a public address.
As a result, a request is always initiated by the Front End client and the server response is done with the same connection. Between requests, the Genero Application Server stores data sent from the DVM in its buffer and keeps it for the next GET request from the Front End client.
<WEB_APPLICATION_TIMEOUT_COMPONENT Id="appTimeOutID">
[ <USER_AGENT> uaTimeOut </USER_AGENT> ]
[ <REQUEST_RESULT> requestTimeOut </REQUEST_RESULT>
]
[ <DVM_AVAILABLE> dvmTimeOut </DVM_AVAILABLE> ]
</WEB_APPLICATION_TIMEOUT_COMPONENT>
The WEB_APPLICATION_TIMEOUT_COMPONENT element may contain the following child elements (described below):
<WEB_APPLICATION_TIMEOUT_COMPONENT Id="cpn.wa.timeout.set1"> <USER_AGENT>300</USER_AGENT> <REQUEST_RESULT>240</REQUEST_RESULT> <DVM_AVAILABLE>10</DVM_AVAILABLE> </WEB_APPLICATION_TIMEOUT_COMPONENT>
In this example, the Id value - cpn.wa.timeout.set1 - can be referenced when defining an application. When an application references a component by its Id value, it inherits the settings defined by that component.
The User Agent timeout is used to identify a period of user inactivity. The USER_AGENT element specifies the number of seconds to wait for a client request before assuming that the Front End client has died (based on user inactivity). After the specified period passes without the client emitting a further request, the Genero Application Server asks the Virtual Machine to properly close the application.
Under normal operation, the Front End client sends a GET request to the Genero Application Server immediately after receiving a response. Therefore, if the client has not sent a request to the Genero Application Server before the USER_AGENT timeout expires, the Genero Application Server assumes that the Front End client has died and asks the DVM to shut down.
With the Genero Desktop Client Active X and Genero Java Client, the USER_AGENT timeout usually does not expire. When the user closes the application, the DVM handling that application is properly shut down.
With the Genero Web Client, however, the USER_AGENT timeout proves to be particularly useful. As with the other Front End clients, when a user properly exits an application, the DVM handling that application is properly shut down and the license that the application consumed is released back into the Genero license application pool. When the user does not properly exit the application, however, the DVM remains alive and continues to consume a license even though the Front End client has died. This can occur with the Genero Web Client when a user closes the browser instead of properly exiting the application; the Front End client has no mechanism to tell the Genero Application Server that the user has closed his browser. Because of the USER_AGENT timeout, however, the USER_AGENT timeouts and Genero Application Server unilaterally close the socket to the DVM, which causes the DVM to shut down and the license to be released.
<USER_AGENT>300</USER_AGENT>
In this usage example, the User Agent timeout is set to 300 seconds.
The Request Result timeout is used to inform the user when a transaction is taking longer than expected. The REQUEST_RESULT element specifies the number of seconds to wait for the Virtual Machine to give an answer to the Application Server, after which the Application Server sends a “transaction pending” page to the Front End client to inform the user that this transaction may take a little longer than expected. This is also known as sending a keepalive response. The default transaction pending page automatically submits a new request to wait for the DVM to complete its processing.
Under normal operations, the Front End client sends a GET request to the Genero Application Server immediately after receiving a response. Meanwhile, the Genero Application Server stores data sent by the DVM for the application in its buffer, waiting for a GET request from the client. When the GET request is received by the Genero Application Server, if the server has data sent by the DVM in its buffer, the stored data is sent back to the Front End client. If the DVM does not have data to send, the Genero Application Server waits and, if the DVM is still processing the request after the specified REQUEST_RESULT timeout expires, it sends the keepalive response to the Front End client and resets the REQUEST_RESULT timer.
Tip: The number of seconds specified for the REQUEST_RESULT timeout should be less that the cgi timeout. By default, the Apache Web server has the cgi timeout default to 300 seconds. Therefore, the REQUEST_RESULT timeout has an initial default setting of 240 seconds.
<REQUEST_RESULT>240</REQUEST_RESULT>
In this usage example, the Request Result timeout is set to 240 seconds.
The DVM Available timeout provides a delay for the DVM to start and be available. The DVM_AVAILABLE element specifies how long (in seconds) the Genero Application Server allows for the DVM to start.
The DVM_AVAILABLE timeout provides a mechanism for the Genero Application Server to handle the failure of the DVM to start. If the DVM has not started by the time the DVM_AVAILABLE timeout expires, the Genero Application Server sends an error message to the Front End client and logs the message: "DVM_AVAILABLE timeout expired."
The DVM_AVAILABLE timeout is only applicable when you start an application or you launch sub process in interactive mode (IN FORM MODE). If you run the sub process in background (IN LINE MODE), the DVM_AVAILABLE timeout is not applicable.
<DVM_AVAILABLE>10</DVM)AVAILABLE>
In this usage example, the DVM Available timeout is set to 10 seconds.
The SERVICE_APPLICATION_TIMEOUT_COMPONENT element creates a Web service application timeout component, which define a set of timeout values to be used when configuring a Web service. It takes an attribute Id, which specifies the unique identifier for this set of timeout definitions. It is this unique identifier that is referenced by a Web service, providing that Web service with a base set of timeout values.
The Genero Application Server handles the Web Services Server side. It takes care of the DVM requested by a Web Services client.
<SERVICE_APPLICATION_TIMEOUT_COMPONENT Id="sTimeOutID">
<DVM_AVAILABLE>dvmTimeOut</DVM_AVAILABLE>
<DVM_FREE>dvmFreeTimeOut</DVM_FREE>
<REQUEST_QUEUE>rqTimeOut</REQUEST_QUEUE>
<REQUEST_RESULT>rrTimeOut</REQUEST_RESULT>
</SERVICE_APPLICATION_TIMEOUT_COMPONENT>
The SERVICE_APPLICATION_TIMEOUT_COMPONENT element may contain the following child elements (described below):
<SERVICE_APPLICATION_TIMEOUT_COMPONENT Id="cpn.ws.timeout.set1"> <DVM_AVAILABLE>10</DVM_AVAILABLE> <DVM_FREE>10</DVM_FREE> <REQUEST_QUEUE>10</REQUEST_QUEUE> <REQUEST_RESULT>240</REQUEST_RESULT> </SERVICE_TIMEOUT_COMPONENT>
In this example, the Id value - cpn.ws.timeout.set1 - can be referenced when defining an Web service. When a Web service references a component by its Id value, it inherits the settings defined by that component.
The DVM Available timeout provides a delay for the DVM to start and be available. The DVM_AVAILABLE element specifies how long (in seconds) the Genero Application Server allows for the DVM to start.
The DVM_AVAILABLE timeout provides a mechanism for the Genero Application Server to handle the failure of the DVM to start. If the DVM has not started by the time the DVM_AVAILABLE timeout expires, the Genero Application Server sends an error message to the Front End client and logs the message: "DVM_AVAILABLE timeout expired."
<DVM_AVAILABLE>10</DVM_AVAILABLE>
In this usage example, the DVM Available timeout is set to 10 seconds.
The DVM Free timeout is used to shut down a DVM that has no request to process. The DVM_FREE element specifies how long (in seconds) a DVM waits with no request to process before determining whether to shut down.
How the DVM reacts when it has no request to process is dependant on the settings for the Web services pool of DVMs. After the DVM_FREE timeout expires, the DVM is shut down if the number of running DVMs is greater than MIN_AVAILABLE. If a DVM has no request to process and the number of DVMs is greater than MAX_AVAILABLE, the DVM does not wait for the DVM_FREE timeout to expire but instead shuts down immediately.
<DVM_FREE>10</DVM_FREE>
In this usage example, the DVM Free timeout is set to 10 seconds.
The Request Queue timeout prevents a request from waiting indefinitely for a DVM to be made available. The REQUEST_QUEUE element specifies how long (in seconds) a request waits for a DVM to be available to handle the request. The DVM can either be an existing DVM or a new DVM started to handle the request. If a new DVM cannot be started and all other DVMs are busy processing other requests, the request will be rejected after the REQUEST_QUEUE timeout expires and an error message is logged: "REQUEST_QUEUE timeout expires". This prevents a request from being in the request queue indefinitely.
Note: The pool of requests and the pool of DVMs are independent. A request is processed as long as a DVM is available to process the request. If a request comes in and there are no available DVMs to process that request, the system attempts to start a new DVM. If a new DVM cannot be started and the DVM_AVAILABLE timeout expires, the request remains in the pool of requests until either a DVM becomes available to process the request or the REQUEST_QUEUE timeout expires, at which time the request is notified that it could not be processed.
<REQUEST_QUEUE>10</REQUEST_QUEUE>
In this usage example, the Request Queue timeout is set to 10 seconds.
The Request Result timeout prevents a request from processing indefinitely. The REQUEST_RESULT element specifies the maximum amount of time (in seconds) for the DVM to process the request. If the time expires, GAS closes the connection and logs an error.
<REQUEST_RESULT>240</REQUEST_RESULT>
In this usage example, the Request Result timeout is set to 240 seconds.