(zos)

Automatically rejecting work requests when no servant is available to process these requests

When a controller determines that a servant has terminated, the controller normally cleans up any other work requests that were dispatched in that servant. If that servant is the last servant, new work requests are placed in the request queue until a servant is available. Depending on how long it takes for a servant to become available, these requests might terminate because the time allowed to process a request has expired. To prevent this from happening, we can change the configuration settings for an application server to prevent the controller from accepting new requests.

Controllers receive application requests on a continual basis and dispatch them to a servant for processing. When a system level problem, such as a database error, occurs, request processing stops and requests pile up in the queues between the controller and the servants. During the time it takes for a servant to become available, requests continue to pile up in the queues until they start to time out. When a timeout occurs, the request that timed out is removed from the queue.

When a new servant is ready to start accepting requests, the next request in the queue might be so close to timing out that the dispatch process for the request cannot complete and the servant again is terminated by timeout processing. Again requests accumulate in the queue until another new servant is ready and potentially the same timeout problem occurs. When this problem keeps reoccurring, it is sometimes referred to as a bouncing servant problem. We can handle this problem in one of the following ways:

Complete the following steps to configure the server to handle no-server conditions.

  1. In the console, click Servers > Server Types > WebSphere application servers, and select the application server for which to automatically detect no-servant conditions.

  2. Under Additional Properties, click Custom properties > New.

  3. Specify control_region_dreg_on_no_srs in the Name field and 1 in the Value field. When this custom property is set to 1, the server rejects all requests targeted for dispatch when it detects that there are no servants ready to process the requests. Setting this property to 0 (zero) turns off this function.

  4. Specify control_region_confirm_recovery_on_no_srs in the Name field and either 0 (zero) or 1 in the Value field. If we enter 0 in the Value field, the controller resumes taking requests as soon as the minimum number of servants are ready to receive requests. If we enter 1 in the Value field, the controller issues WTOR message BBOO0297A as soon as it detects that the minimum number of servants for which the server is configured are ready to accept work. The server waits until it receives a response to this message before it actually resumes taking requests.

  5. Click Review, select Synchronize changes with Nodes, and then click Save to update the master repository with the changes.


Results

When a controller determines that a servant has terminated, and that servant is the last servant, the controller will not accept new work requests until the minimum number of servants are available to receive requests.


Related

  • Modify command