Configure an on demand router (ODR) to determine how it handles
failure scenarios and how to tune certain work requests. You can configure
the connections and requests to the application server, configure the requests
that must be rejected, define how error responses are handled, and specify
the location of the proxy logs. The configuration of the ODR in the DMZ is
not supported.
Before you begin
After the ODR is created, it senses the
environment and can route work to WebSphere® Extended Deployment application
servers.You must first create an ODR, a proxy with advanced capabilities
that WebSphere Extended
Deployment uses to route work to application server nodes. See Creating ODRs
for
more details.
About this task
You can define the configuration of the ODR by editing its proxy
configuration. Define the configuration further by clicking Servers > On
Demand Routers >odr_name> On demand router properties > On demand
router settings. Note that the configuration of the ODR in the DMZ is
not supported.
Procedure
- Define and configure the connections and requests between the ODR
and the application servers that issue the request.
- By default, caching content is enabled. The properties that follow
apply only if caching is enabled.
- Enable - Enables caching framework for the ODR server and enables static
content caching, as defined by HTTP 1.1 specifications.
- Cache instance name - The dynamic cache object cache instance, that is
configured under Resources > Cache instances > Object cache instances,
used to cache all static and dynamic content responses. This object cache
instance must be configured to support new I/O (NIO) application program interfaces
(APIs).
- Cache SSL content - Determines whether client ODR SSL connections that
are terminated by the ODR should have their responses cached.
- Cache Aggressively - Enables caching of HTTP responses that would not
normally be cached. Caching rules that are defined by HTTP 1.1 can be broken
to gain caching optimization.
- Cache Dynamic Content - Determines whether dynamic content that is generated
by WebSphere Application
Servers V6.02, or later, is cached. Caching dynamic content generated by content
servers prior to WebSphere Application Server V6.02 is not supported
- Cache update URI - When caching dynamic content, this is the relative
URI of an installed content server application that is used to invalidate
cached entries.
- Define exclusions. The ODR examines every incoming request.
You can define certain methods for exclusion, and if the requested HTTP method
matches any of the configured methods, the ODR rejects the requests with a
Method Disallowed error.
- Logging is enabled by default. HTTP requests are logged
in one of three logs: proxy, cache, and local. Local log configuration is
not available in the administrative console, but is available at ${SERVER_LOG_ROOT}local.log.
Specify the location of this log by setting the http.log.localFileName custom
property to the file location. The content of each log is formatted using
the National Center for Supercomputing Applications common log format.
- Define trusted security proxies. A trusted security
proxy is a process that receives requests prior to the ODR and then forwards
requests to the ODR. For example, a Web server with the WebSphere Application
Web server plug-in might forward requests to the ODR. A trusted security proxy
is allowed to pass information such as the virtual host name, or user identity
to the ODR in private HTTP headers. Private headers received from an untrusted
proxy are discarded by the ODR. Use an Internet Protocol or fully-qualified
host name in this field.
- Create a proxy plug-in configuration policy on a cell level.
A proxy plug-in configuration policy generates a proxy plug-in configuration
file that can be used on a Web server that routes requests to the ODR. The
plug-in can determine the URI that the proxy is handling on behalf of the
application server and the endpoint, or boundaries of the proxy so that it
can properly route requests to the proxy. Note that the configuration of the
ODR in the DMZ is not supported.
You have three options, other than
none or
all,
for defining a scope by which to generate the plug-in.
- Cell: The ODR generates a plug-in configuration that includes all the
URIs that are handled by all the ODRs in the cell.
- Node: Includes all the URIs that are configured for the node
- Server: Generates a plug-in configuration file for the ODR that is currently
configured.
- Install an error page application on the ODR. From
the base server installation install_root/installableApps directory,
install the HttpErrorHandler.ear sample error page application
by issuing the command:
$AdminApp install <path_to_application ear> <file> [list -server <name_of_ODR_server> -node <name_of_ODR node>]
Install this application on the ODR to minimize latency. The HttpErrorHandler.ear file
also contains sample source code to use as a starting point to create your
own error page application.
- Type the Error page generation application URI. Define
your custom error page policy. For example, if you use the HttpErrorHandler.ear sample
application, use the /ErrorPageApp/ErrorPage
URI. Customized error pages with this definition can be used when
errors occur during the processing of the request.
- Configure HTTP response codes to handle. In the HTTP
status codes that are to be recognized as errors field, type any specific
HTTP response codes for your error page application to handle and click OK.
Use separate lines and comma separation for multiple codes and X as
a wildcard character to denote code ranges. For example, type 4XX to
denote all status codes between 400 and 499. Ensure that each error code is
on a separate line. For example:
4xx
5xx
What to do next
After you create and configure the ODR and apply any configuration
parameters, you can define the ability to route work to non-Extended Deployment
nodes.