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.