Web server plug-ins enable the Web server to communicate
requests for dynamic content, such as servlets, to the application
server. A Web server plug-in is associated with each Web server definition.
The configuration file (plugin-cfg.xml) that is generated for each
plug-in is based on the applications that are routed through the associated
Web server.
A Web server plug-in is used to forward HTTP requests from a supported
Web server to an application server. Using a Web server plug-in to
provide communication between a Web server and an application server
has the following advantages:
- XML-based configuration file
- Standard protocol recognized by firewall products
- Security using HTTPS, replacing proprietary Open Servlet Engine
(OSE) over Secure Sockets Layer (SSL)
Each of the supported Web server plug-ins runs
on a number of operating systems. See Supported Hardware and Software for the product
for the most current information about supported Web servers.
Avoid trouble: The
default behavior for the Web server plug-in is to buffer requests
up to 64 kilobytes, and retry the requests if there is no response
from the application server. If you want to ensure high availability,
and your HTTP requests tend to be large, set the
Maximum
buffer size used when reading HTTP request content property
on the Web server plug-in request routing property page in the administrative
console to
-1. Setting this property to -1
removes the maximum buffer size limit, and enables the Web server
plug-in to buffer all requests regardless of their size. Requests
are retried if the request body fits within the buffer size. If you
want to disable all request buffering, and thereby disable retries
of requests with request bodies, you can set this property to
0.
gotcha
Affinity requests
Affinity
requests are requests that contain a JSESSIONID. Session affinity
means that all requests of the same JSESSIONID are sent to the same
application server. For example, if the first request is sent to clone5,
then the next affinity request from that same browser is also sent
to clone5 regardless of the weight valued specified for the LoadBalanceWeight
property in the plugin-cfg.xml file.
If you use Round Robin
for the LoadBalance property in the plugin-cfg.xml file, and leave
the IgnoreAffinityRequests property in the plugin-cfg.xml file set
to its default value of true, the affinity
requests do not lower the weight. This behavior might cause an uneven
distribution of requests across the servers in environments that make
use of session affinity. Setting the IgnoreAffinityRequests property
to false causes the weight to be lowered every
time an affinity request is received, which results in a more balanced
Round Robin environment.
If you specify Random for the LoadBalance
property, affinity requests are still sent to the same cloneid, but
new requests are routed randomly, and the value specified for the
LoadBalanceWeight property is ignored.
Failover
If
a request connection exceeds the time limit specified on the ConnectTimeout
property in the plugin-cfg.xml file, or a 5xx error is returned from
the application server, the Web server plug-in marks the server as
down, and attempts to connect to the next application server in the
list of primary servers that is specified for the PrimaryServers property
in the plugin-cfg.xml file. If the Web server plug-in successfully
connects to another application server, all requests that were pending
for the down application server are sent to this other application
server. All other new and affinity requests are sent to other servers,
based on whether Round Robin or Random is the setting for the LoadBalance
property.
Failover typically does not occur the first time
that the time limit specified on the ServerIOTimeout property in the
plugin-cfg.xml file is exceeded for either a request or a response.
Instead, the Web server plug-in tries to resend the request to the
same application server, using a new stream. If the time specified
on the ServerIOTimeout property is exceeded a second time, the Web
server plug-in marks the server as down, and initiates the failover
process.
Avoid trouble: Sending a large
number of pending requests to the same application server might impact
the performance of that application server if a failover situation
occurs. You can use the MaxConnections property to limit the number
of requests that might be pending for an application server.
gotcha
Running multiple Web
server child processes
You can configure most Web servers
to start multiple child processes. In this situation, each child process
loads its own instance of the Web server. When running multiple Web
server child processes, remember that:
- Multiple running instances of the Web server plug-in cannot share
information. Therefore the dynamically changing load balance weight
of each application server is not shared between the Web server plug-in
instances. For example, one instance of the Web server plug-in might
consider an application server to be running with a weight of 5, while
another instance of the Web server plug-in might be consider the same
application server to be down and unusable. This difference in perspective
might cause an incoming request to be handled differently, depending
on which Web server plug-in instance handles the request.
- The Web server plug-in settings are handled on a per instance
basis. For example, the MaxConnections property specifies the number
of pending requests that are allowed on that Web server, for each
Web server plug-in instance. If the MaxConnections property is set
to 20, and you start three Web server child
processes, each of the three Web server plug-in instances allow 20
pending connections to the same application server, which means that
there could be up to 60 pending connections.