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, you can change
the configuration settings for an application server to prevent the
controller from accepting new requests.
About this task
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.
You can handle this problem in one of the following ways:
- You can configure the server to automatically detect a no-server
situation and stop accepting requests until the minimum configured
number of servants are ready to accept work. This is the simplest
approach.
- You can create an automation routine to handle the problem if
you are able to detect that you are having a system problem before
servants are terminated because of timeouts. This automation routine
can issue the f server, pauselisteners command
to prevent requests from being accepted by this server. The routine
must then detect when circumstances have changed and issue the f server, resumelisteners command
when the detected system problem is resolved.
- You can configure the server to detect a no-server condition and
stop accepting requests, and create the previously discussed automation
routine. The automation routine must recognize the different processing
that can take place because the server is configured to detect a no-server
condition:
- If the last servant terminates even though the f server, pauselisteners command
is issued, the server starts to reject all requests and issues message
BBOO0299I. The server automatically starts to accept requests when
the minimum number of servants, for which the server is configured,
are ready to accept work. It also issues message BBOO0300I to indicate
that requests are again being processed. Therefore, the automation
routine must be sensitive to the fact that the server might have resumed
accepting requests upon detecting that the minimal number of servants
are available.
- If the control_region_confirm_recovery_on_no_srs custom property
is specified for the server, the server issues WTOR message BBOO0297A
after it detects that the minimal number of servants, for which the
server is configured, are ready to process new requests. You must
enter a response to this message before the server actually starts
to accept work.
- If the automation routine prevents the server from terminating
the servants because of timeout processing, it must also recognize
when it is safe for the server to resume taking requests and issue
the f server, resumelisteners command
at that point in time. The automation routine can be set up to determine
whether or not it needs to issue the f server, resumelisteners command
based on whether or not the message BBOO0299I is issued. This message
indicates that the server ran out of servants and is rejecting requests.
This approach is the most complex, but provides the most flexibility.
Complete the following steps if you want to configure the
server to handle no-server conditions.
Procedure
- In the administrative console, click , and select the application server for which you want
to automatically detect no-servant conditions.
- Under Additional Properties, click .
- 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.
- Specify control_region_confirm_recovery_on_no_srs in
the Name field and either 0 (zero) or 1 in
the Value field. If you 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 you 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.
- Click Review, select Synchronize changes with
Nodes, and then click Save to update the master repository
with your 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.