3 Configuring the Oracle WebLogic Server Proxy Plug-In for Apache HTTP Server

To configure the Oracle WebLogic Server Proxy Plug-in for Apache HTTP Server, Oracle recommends you to read the information included in this section.

This section includes the following topics:

Configuring the Oracle WebLogic Server Proxy Plug-in

Edit the httpd.conf file to proxy requests by path or by MIME type, to enable HTTP tunneling and to use the other Oracle WebLogic Server Proxy Plug-in parameters.

This section includes the following topics:

Configuring the httpd.conf File

To configure the Oracle WebLogic Server Proxy Plug-in, edit the httpd.conf file in your Apache HTTP Server installation. Complete the following tasks:

Task 1: Configure MIME Requests

You can proxy requests by MIME type and/or by path. Open the httpd.conf file in a text editor and complete the following steps:

Note:

If both MIME type and proxying by path are enabled, proxying by path takes precedence over proxying by MIME type.
Configuring Proxy Requests by MIME Type

To configure MIME requests by MIME type in the httpd.conf file, add a MatchExpression line to the <IfModule> block:

  • For a non-clustered Oracle WebLogic Server: Define the WebLogicHost and WebLogicPort parameters with the MatchExpression directive.
    In the example below, a non-clustered Oracle WebLogic Server specifies that all files with MIME type .jsp are proxied:
    <IfModule mod_weblogic.c> 
     WebLogicHost my-weblogic.server.com
     WebLogicPort 7001
     MatchExpression *.jsp
    </IfModule>
    You can use multiple MatchExpression as well. For example:
    <IfModule mod_weblogic.c>
     WebLogicHost my-weblogic.server.com
     WebLogicPort 7001
     MatchExpression *.jsp
     MatchExpression *.xyz
    </IfModule>
  • For a cluster of Oracle WebLogic Servers: Define the WebLogicCluster parameter with the MatchExpression directive.
    In the example below, a clustered Oracle WebLogic Server specifies that all files with MIME type .jsp are proxied:
    <IfModule mod_weblogic.c>
     WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
     MatchExpression *.jsp
    </IfModule>

    See MatchExpression.

Configuring Proxy Requests by Path

To configure MIME requests by path in the httpd.conf file, configure the PathTrim parameter inside the <Location> tag. The PathTrim parameter specifies a string trimmed from the beginning of the URL before the request is passed to the Oracle WebLogic Server instance. See PathTrim.

For example, the following Location block proxies all requests that contain /weblogic in the URL:
<Location /weblogic>
  WLSRequest On
  PathTrim /weblogic
</Location>

The <Location> directive limits the scope of the enclosed directives by URL. See Apache Location Directive.

Task 2: Define Additional Parameters for Oracle WebLogic Server Proxy Plug-In

Define any additional parameters for the Oracle WebLogic Server Proxy Plug-in for Apache HTTP Server.

The Oracle WebLogic Server Proxy Plug-in for Apache HTTP Server recognizes the parameters listed in General Parameters for Oracle WebLogic Server Proxy Plug-Ins. To modify the behavior of your Oracle WebLogic Server Proxy Plug-in for Apache HTTP Server, define these parameters either:

  • In a <Location> block, for parameters that apply to proxying by path, or
  • At global or virtual host scope, for parameters that apply to proxying by MIME type.
Task 3: Enable HTTP Tunneling (Optional)

You can enable HTTP tunneling for the T3 protocol by configuring the <Location> blocks.

To enable HTTP tunneling if you are using the T3 protocol and weblogic.jar, add the following <Location> block to the httpd.conf file:

<Location /bea_wls_internal>
 WLSRequest On
</Location>
Task 4: Enable Web Services Atomic Transaction (Optional)
You can enable Web Services Atomic Transaction (WS-AT) by configuring the <Location> blocks. The <wls-wsat> parameter applies to proxying by path. You can optionally define the parameter to modify the behavior of the Oracle WebLogic Server Proxy Plug-in for Apache HTTP Server.
<Location /wls-wsat>
 WLSRequest On
</Location>

WebLogic web services enable interoperability with other external transaction processing systems, such as IBM WebSphere, JBoss, Microsoft .NET. For more information about Web Services Atomic Transaction (WS-AtomicTransaction), see https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx.

Task 5: Verify and Apply Your Configuration

Follow these steps to verify the httpd.conf configuration and apply it to the Apache HTTP Server.

  1. Verify the syntax of the httpd.conf file by running the following command (UNIX/Linux):
    > APACHE_HOME/bin/apachectl -t

    If the httpd.conf file contains any errors, the output of this command shows the errors; otherwise, the command returns the following:

    Syntax OK
  2. Start the Apache HTTP Server (for UNIX/Linux):
    > APACHE_HOME/bin/apachectl start
  3. Send a request to http://apache-host:apache-port/mywebapp/my.jsp from the browser. Validate the response.

Placing the WebLogic Properties Inside the Location or VirtualHost Blocks

If you choose to not use the <IfModule>, you can instead directly place the WebLogic properties inside the Location or <VirtualHost> blocks. Consider the following examples of the <Location> and <VirtualHost> blocks:

<Location /weblogic>
WLSRequest On
WebLogicHost myweblogic.server.com
WebLogicPort 7001
</Location>
<Location /weblogic>
WLSRequest On
WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
</Location>
<VirtualHost apachehost:80>
WLSRequest On
WebLogicServer weblogic.server.com
WebLogicPort 7001
</VirtualHost>

Example: Configuring the Oracle WebLogic Server Proxy Plug-In

This example demonstrates basic instructions for quickly setting up the Oracle WebLogic Server Proxy Plug-in to proxy requests to a back-end Oracle WebLogic Server.

  1. Make a copy of $APACHE_HOME/conf/httpd.conf file.
  2. Edit the file to add the following code:
    ... 
    LoadModule weblogic_module /home/myhome/weblogic-plugins-12.2.1/lib/mod_wl_24.so
    
    <IfModule mod_weblogic.c>
      WebLogicHost wls-host
      WebLogicPort wls-port
    </IfModule>
    
    <Location /mywebapp>
      WLSRequest On
    </Location>
    ...
    
  3. Include $PLUGINS_HOME/lib in the LD_LIBRARY_PATH, using the following command:
    $ export LD_LIBRARY_PATH=/home/myhome/weblogic-plugin-14.1.1.0.0/lib:$LD_LIBRARY_PATH

    Note:

    You can also update the LD_LIBRARY_PATH by copying the 'lib' contents to APACHE_HOME/lib or by editing the APACHE_HOME/bin/apachectl to update the LD_LIBRARY_PATH.

  4. Set PLUGINS_HOME to point to the directory where the proxy plug-ins zip file is extracted to, using the following command:
    export PLUGINS_HOME=/home/myhome/weblogic-plugins-14.1.1.0.0/
  5. Include the path containing the OpenSSL libraries in the LD_LIBRARY_PATH, using the following command:
    export LD_LIBRARY_PATH=/home/myhome/openssl_installation/lib:$LD_LIBRARY_PATH
  6. At the prompt, start the Apache HTTP Server by entering:
    $ ${APACHE_HOME}/bin/apachectl start
  7. Send a request to http://apache-host:apache-port/mywebapp/my.jsp from the browser and validate the response

Including a weblogic.conf File in the httpd.conf File

To keep several separate configuration files, you can define parameters in a separate configuration file called weblogic.conf, by using the Apache HTTP Server Include directive in an <IfModule> block in the httpd.conf file.

<IfModule mod_weblogic.c>
 # Config file for Oracle WebLogic Server that defines the parameters
 Include conf/weblogic.conf 
</IfModule>

The syntax of weblogic.conf files is the same as that for the httpd.conf file.

The following sections describe how to create the weblogic.conf files, and include the sample weblogic.conf files:

Rules for Creating the weblogic.conf Files

Be aware of the following rules and best practices for constructing a weblogic.conf file.

  • Enter each parameter on a new line. Do not put "=" between a parameter and its value. For example:
    PARAM_1 value1
    PARAM_2 value2
    PARAM_3 value3
  • If a request matches both a MIME type specified in a MatchExpression in an <IfModule> block and a path specified in a Location block, the behavior specified by the <Location> block takes precedence.
  • If you use an Apache HTTP Server <VirtualHost> block, you must include all configuration parameters (MatchExpression, for example) for the virtual host within the <VirtualHost> block (see Apache Virtual Host documentation at http://httpd.apache.org/docs/vhosts/).
  • You should use the MatchExpression statement instead of the <Files> block.

Here is sample of the weblogic.conf file:

Global configuration:
<IfModule mod_weblogic.c>
 WebLogicCluster johndoe02:8005,johndoe:8006
 WLTempDir "/tmp"
 DebugConfigInfo ON
 KeepAliveEnabled ON
 KeepAliveSecs 15
</IfModule>
Location configuration:
  • All the requests that match /jurl/* will have the POST data files in /tmp/jurl and will reverse proxy the request to myCluster and port 7001.
    <Location /jurl>
     WLSRequest On
     WebLogicCluster myCluster:7001
     WLTempDir "/tmp/jurl"
    </Location>
  • All the requests that match /web/* will have the POST data files in /tmp/web and will reverse proxy the request to myhost and port 8001.
    <Location /web>
     WLSRequest On
     PathTrim /web
     WebLogicHost myhost
     WebLogicPort 8001
     WLTempDir "/tmp/web"
    </Location>
  • All the requests that match /foo/* will have the POST data files written to /tmp/foo and will reverse proxy the request to myhost02 and port 8090.
    <Location /foo>
     WLSRequest On
     WebLogicHost myhost02
     WebLogicPort 8090
     WLTempDir "/tmp/foo"
     PathTrim /foo
    </Location>
Sample weblogic.conf Configuration Files

These examples of weblogic.conf files may be used as templates that you can modify to suit your environment and server. Lines beginning with # are comments.

Example 3-1 Using WebLogic Clusters

# These parameters are common for all URLs which are 
# directed to the current module. If you want to override
# these parameters for each URL, you can set them again in
# the <Location> or <Files> blocks. 
<IfModule mod_weblogic.c>
 WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
 ErrorPage http://myerrorpage.mydomain.com
 MatchExpression *.jsp
</IfModule>
####################################################

In the example, the MatchExpression parameter syntax for expressing the filename pattern, the Oracle WebLogic Server host to which HTTP requests should be forwarded, and various other parameters are as follows:

MatchExpression [filename pattern] [WebLogicHost=host] | [paramName=value]

The first MatchExpression parameter below specifies the filename pattern *.jsp, and then names the single WebLogicHost. The paramName=value combinations following the pipe symbol specify the port at which Oracle WebLogic Server is listening for connection requests, and also activate the Debug option. The second MatchExpression specifies the filename pattern *.html and identifies the WebLogic Cluster hosts and their ports. The paramName=value combination following the pipe symbol specifies the error page for the cluster.

Example 3-2 Using Multiple WebLogic Clusters

# These parameters are common for all URLs which are
# directed to the current module. If you want to override
# these parameters for each URL, you can set them again in
# the <Location> or <Files> blocks.
<IfModule mod_weblogic.c>
 MatchExpression *.jsp WebLogicHost=myHost|WebLogicPort=7001|Debug=ON
 MatchExpression *.html WebLogicCluster=myHost1:7282,myHost2:7283|ErrorPage=
 http://www.xyz.com/error.html
</IfModule>

Example 3-3 Without WebLogic Clusters

# These parameters are common for all URLs which are 
# directed to the current module. If you want to override
# these parameters for each URL, you can set them again in
# the <Location> or <Files> blocks.
<IfModule mod_weblogic.c>
 WebLogicHost myweblogic.server.com
 WebLogicPort 7001
 MatchExpression *.jsp
</IfModule>

Example 3-4 Configuring Multiple Name-Based Virtual Hosts

# VirtualHost1 = localhost:80
<VirtualHost 127.0.0.1:80>
DocumentRoot "/test/VirtualHost1"
ServerName localhost:80
<IfModule mod_weblogic.c> 
#... WLS parameter ...
WebLogicCluster localhost:7101,localhost:7201
# Example: MatchExpression *.jsp <some additional parameter>
MatchExpression *.jsp PathPrepend=/test2
</IfModule>
</VirtualHost>
 
# VirtualHost2 = 127.0.0.2:80
<VirtualHost 127.0.0.2:80>
DocumentRoot "/test/VirtualHost1"
ServerName 127.0.0.2:80
<IfModule mod_weblogic.c> 
#... WLS parameter ...
WebLogicCluster localhost:7101,localhost:7201
# Example: MatchExpression *.jsp <some additional parameter>
MatchExpression *.jsp PathPrepend=/test2
#... WLS parameter ...
</IfModule>
</VirtualHost>

You must define a unique value for ServerName or some proxy plug-in parameters will not work as expected.

Example 3-5 With HTTP/2 Protocol Configured

LoadModule weblogic_module modules/mod_wl_24.so
Listen 4455
<VirtualHost *:4455>
  ServerName vh1.com
  WLSSLWallet /scratch/user/temp/server
  SecureProxy ON
  WLProtocol http/2
  <Location /myApp>
     SetHandler weblogic-handler
     WebLogicCluster ns1.example.com:7011,ns2.example.com:7011,ns3.example.com:7011
  </Location>
  <Location /myApp2>
     WebLogicHost example.com
     SetHandler weblogic-handler
     WebLogicPort 7025
  </Location>
</VirtualHost>
Template for the Apache HTTP Server httpd.conf File

This section contains a sample httpd.conf file for Apache HTTP Server. You can use this sample as a template and modify it to suit your environment and server. Lines beginning with # are comments.

Note:

Apache HTTP Server is not case sensitive.

Sample httpd.conf file for Apache HTTP Server

####################################################
# APACHE-HOME/conf/httpd.conf file
####################################################
LoadModule weblogic_module /home/myhome/weblogic-plugins-12.2.1/lib/mod_wl_24.so

<Location /weblogic>
 WLSRequest On
 PathTrim /weblogic
 ErrorPage http://myerrorpage1.mydomain.com
</Location>

<Location /servletimages>
 WLSRequest On
 PathTrim /something
 ErrorPage http://myerrorpage1.mydomain.com
</Location>

<IfModule mod_weblogic.c>
  MatchExpression *.jsp
  WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
  ErrorPage http://myerrorpage.mydomain.com
</IfModule>

About WebSocket Proxy Configurations

The Oracle WebLogic Server 14.1.1.0.0 Proxy Plug-in for Apache HTTP Server 2.4.x can handle WebSocket connection upgrade requests and effectively proxy to WebSocket applications hosted within Oralce WebLogic Server 14c (14.1.1.0.0) and later.

Review following timeout setting for the WebSocket connection:
  • If you use the mod_reqtimeout module within the Apache HTTP Server, then set the configured client timeout value appropriately to consider for the WebSocket connections.
  • The default timeout value for HTTP requests in the mod_reqtimeout module has changed between Apache HTTP Server 2.2 and 2.4. This change can cause the WebSocket connections to break. Therefore, you will need to use an appropriate client timeout value.
  • You should configure appropriate client timeout values for the WebSocket connections to avoid malicious attacks such as a Denial of Service attack.

Note:

WebSocket is not supported over HTTP/2.

Verifying the Log File

The Oracle WebLogic Server Proxy Plug-in logs are now part of the Apache HTTP Server error log. You can easily identify the references with the prefix weblogic:
[weblogic:debug] [pid 6571:tid 139894556022528] ApacheProxy.cpp(875): [client 10.184.61.77:53634] <657114316705052> =========New Request: [GET /weblogic/index.html HTTP/1.1] ======
To enable the proxy plug-in logs, set the Apache web server directive LogLevel to debug. The logs are included in the file pointed to by the Apache web server ErrorLog directive.
config file name: httpd.conf
setting: LogLevel debug

Additionally, a new log file named wl_exportwallet_log is created in the same file system path where the web server's log file exists. In case of the Apache web server process, this file is located at $SERVER_ROOT/logs/.

The Oracle wallets used in the web server configuration must be exported to PEM formatted files on the file system to enable OpenSSL APIs to access the key and certificates present in the Oracle wallet. This is done by forking a separate process called export_wallet from the main web server process. The export_wallet process writes to the wl_exportwallet_log, and not to the web server's log.

Understanding the DMS Metrics for Oracle WebLogic Server Proxy Plug-In

The performance metrics for Oracle WebLogic Server Proxy Plug-in are provided through the Oracle Dynamic Monitoring Service (DMS). For example, it can fetch the number of requests proxied, the number of failed requests, and other specific metrics. You can configure and view the DMS performance metrics for Oracle WebLogic Server 14.1.1.0.0 Proxy Plug-in.

The DMS metrics that can be returned are described in DMS State Metrics, DMS Event Metrics, and DMS PhaseEvent Metrics.

This section includes the following topics:

Configuring the DMS Metrics for the Oracle WebLogic Server Proxy Plug-In

To configure the DMS metrics for the Oracle WebLogic Server Proxy Plug-in , add the following code to the httpd.conf file:

# Add the following LoadModule only if it is not already present
# Use mod_wl_24.so for Apache 2.4
LoadModule weblogic_module $PLUGINS_HOME/mod_wl_24.so

<Location /metrics>
    SetHandler dms-handler
</Location>

Viewing the Performance Metrics for the Oracle WebLogic Server Proxy Plug-In

You can view the raw metrics using the following URL:

http://apachehost:apacheport/metrics

Where, apachehost is the host name of the Apache server and apacheport is the port number.

The metrics that are coming from Oracle WebLogic Server Proxy Plug-in can be found under the /WebLogicProxy [type=WebLogicProxy] section.

DMS State Metrics

A State metric tracks system status information or to track a metric that is not associated with an event. For a description of the State metrics, see Table 3-1.

Table 3-1 State Metrics for the Oracle WebLogic Server Proxy Plug-In Module

Metric Name Description

totalDeclines

The total number of requests declined (not processed by mod_wl_24). This number indicates the requests that are not configured, and/or rejected by the proxy plug-in (for example, custom HTTP methods are always rejected by the proxy plug-in)

totalErrors

Number of requests that could not be processed successfully. See Event Metrics for errors.

totalHandled

The total number of requests serviced by the mod_wl_24 proxy plug-in.

totalRequests

The total number of requests received by mod_wl_24. The number includes all the requests that are targeted to the proxy plug-in, plus the requests that are not targeted to any module (not configured).

totalRetries

Number of times a request was retried. Requests are generally retried on failure (depending on configuration). If a request is ever retried, this metric will increment (once per request, irrespective of how many times the request was retried).

totalSuccess

The number of requests successfully processed. If the requests are processed successfully (proxied to Oracle WebLogic Server, and sent the response back to client), then this metric will be incremented.

websocketActive

Number of WebSocket upgrade requests currently active.

websocketClose

Number of WebSocket upgrade requests closed. If the WebSocket session is terminated (for any reason), then this metric is updated.

websocketMax

Maximum number of simultaneous WebSocket requests that can be active.

If the WLMaxWebSocketClients parameter is configured, the value will be the lower of these:

  • The configured value, OR
  • 0.75 of the value of MaxRequestWorkers (Apache 2.4)

If WLMaxWebSocketClients parameter is not configured, the value will be 0.5 of the value of MaxRequestWorkers (Apache 2.4).

For more information about the WLMaxWebSocketClients parameter, see Tuning Apache HTTP Server for High Throughput for WebSocket Upgrade Requests.

websocketPercent

This value is defined by the number of active WebSockets (websocketActive) divided by the maximum number of simultaneous WebSocket requests (websocketMax) multiplied by 100:

(websocketActive/webocketMax)*100.

websocketRequests

The number of WebSocket upgrade requests made. If the request URI is an WebSocket upgrade request, this metric will be incremented.

websocketSuccess

Number of WebSocket upgrade requests completed successfully. If Oracle WebLogic Server responds to a WebSocket upgrade request with 101 Switching Protocols, then this metric is updated.

DMS Event Metrics

A DMS Event metric counts system events. A DMS event tracks system events that have a short duration, or where the duration of the event is not of interest but the occurrence of the event is of interest. For a description of the Event metrics, see Table 3-2.

Table 3-2 Event Metrics for the Oracle WebLogic Server Proxy Plug-In Module.

Metric Name Description

errConnRefused

The number of CONNECTION_REFUSED errors. Indicates the number of times the configured WebLogicHost and/or WebLogicPort is either not reachable or not listening.

errNoResources

The number of NO_RESOURCES errors. One scenario where this exception can occur is when SSL is configured in the proxy plug-in, but the corresponding SSL configuration is not defined in the managed server.

errOthers

The number of any other errors. For example, POST data size is greater than the value of MaxPostSize.

errReadClient

The number of READ_ERROR_FROM_CLIENT errors. Indicates the number of times that the proxy plug-in could not read from the client (browser).

errReadServer

The number of READ_ERROR_FROM_SERVER errors. Indicates the number of times a read operation could not be successfully performed on Oracle WebLogic Server.

errReadTimeout

The number of READ_TIMEOUT errors. An example is Oracle WebLogic Server not responding within WLIOTimeoutSecs.

errWriteClient

The number of WRITE_ERROR_TO_CLIENT errors. Indicates the number of times that the proxy plug-in could not write to client. This can be seen when the client sends a request but closes the connection before receiving the response.

errWriteWLS

The number of WRITE_ERROR_TO_SERVER errors. Indicates the number of times that the proxy plug-in could not write to Oracle WebLogic Server.

wsClientClose

Number of WebSocket upgrade requests closed by client. If the client sends a WebSocket upgrade request, and client closes the connection, then this metric is updated.

wsErrorClose

Number of WebSocket sessions terminated due to error. If there is any error which causes the WebSocket connection to close, then this metric is updated.

wsNoUpgrade

The number of times the WebSocket upgrade request was rejected. The response to WebSocket upgrade request is not "101 Switching Protocols". This can happen when the upgrade request is sent to Oracle WebLogic Server that does not support WebSockets (Oracle WebLogic Server version 12.1.2 or earlier).

wsServerClose

Number of WebSocket upgrade requests closed by server. If Oracle WebLogic Server initiates a close of WebSocket communication, then this metric is updated. For example, timeout or no communication (by default, 5 minutes) after upgrading the request.

DMS PhaseEvent Metrics

A DMS PhaseEvent metric measures the time spent in a specific section of code that has a beginning and an end. A PhaseEvent tracks time in a method or in a block of code. For each phase event, an "active count", "completed count", "total time", "min time", "max time", and "average time" value is included. For a description of the PhaseEvent metrics, see Table 3-3.

Table 3-3 PhaseEvent Metrics for the Oracle WebLogic Server Proxy Plug-In Module

Metric Name Description

websocketPhase

WebSocket communication in progress. The phase (time) between "WebSocket upgrade succeeded" and "WebSocket connection closed"

wlsWait

The phase (time) between "the request sent to Oracle WebLogic Server" and "Waiting for response".

Common Configuration Tasks

There are tasks that are common across all the web servers for configuring the proxy plug-ins provided by Oracle.

This section includes the following topics:

Configuring IPv6 with Proxy Plug-Ins

The Oracle WebLogic Server 14.1.1.0.0 Proxy Plug-ins support IPv6. Specifically, the WebLogicHost and WebLogicCluster configuration parameters now support IPv6 addresses. See WebLogicCluster and WebLogicHost.

For example:

<IfModule mod_weblogic.c>
 WebLogicHost [a:b:c:d:e:f]
 WebLogicPort 7002
 ...
</IfModule>

or

<IfModule mod_weblogic.c>
 WebLogicCluster [a:b:c:d:e:f]:<port>, [g:h:i:j:k:l]:<port>
 
 ....
</IfModule>

You can also use the IPv6 address mapped host name.

For example:
<IfModule mod_weblogic.c>  
#hostname1 is mapped to IPv6 address in /etc/hosts file
 WebLogicHost hostname1
 WebLogicPort 7002
 ...
</IfModule>
Sample entry in the /etc/hosts file:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
::1 hostname1

Note:

As of Windows 2008, the DNS server returns the IPv6 address in preference to the IPv4 address. If you are connecting to a Windows 2008 (or later) system using IPv4, the link-local IPv6 address format is tried first, which may result in a noticeable delay and reduced performance. To use the IPv4 address format, configure your system to instead use IP addresses in the configuration files or add the IPv4 addresses to the etc/hosts file.

In addition, you may find that, setting the DynamicServerList property to OFF in the configuration file also improves performance with IPv6. When set to OFF, the proxy plug-in ignores the dynamic cluster list used for load balancing requests proxied from the proxy plug-in and uses the static list specified with the WebLogicCluster parameter.

Understanding Connection Errors and Clustering Failover

When the proxy plug-in attempts to connect to Oracle WebLogic Server, the proxy plug-in uses several configuration parameters to determine how long to wait for connections to the Oracle WebLogic Server host and, after a connection is established, how long the proxy plug-in waits for a response.

If the proxy plug-in cannot connect or does not receive a response, the proxy plug-in attempts to connect and send the request to the other Oracle WebLogic Server instances in the cluster. If the connection fails or there is no response from any Oracle WebLogic Server in the cluster, an error message is sent. For an illustration of how the proxy plug-in handles failover, see Figure 3-1.

This section includes the following topics:

Possible Causes of Connection Failures

Failure of the Oracle WebLogic Server host to respond to a connection request could indicate the following problems:

  • Physical problems with the host machine (such as power outages, hardware malfunction, operating system crash, and so on).
  • Network problems.
  • Other server failures.

Failure of a Oracle WebLogic Server instance to respond could indicate the following problems:

  • Oracle WebLogic Server is not running or is unavailable.
  • A hung server.
  • A database problem.
  • An application-specific failure.
Tips for Reducing CONNECTION_REFUSED Errors

Under load, a proxy plug-in may receive CONNECTION_REFUSED errors from a back-end Oracle WebLogic Server instance. Follow these tuning tips to reduce CONNECTION_REFUSED errors:

  • Increase the AcceptBackLog setting in the configuration of your Oracle WebLogic Server domain.
  • Decrease the time wait interval. This setting varies according to the operating system you are using. For example, on Linux, set the net.ipv4.tcp_fin_timeout parameter to a lower value in the /etc/sysctl.conf file.
  • Increase the open file descriptor limit on your machine. This limit varies by operating system. Using the limit (.csh) or ulimit (.sh) directives, you can make a script to increase the limit.
Failover with a Single, Non-Clustered Oracle WebLogic Server

If you run only a single Oracle WebLogic Server instance, the proxy plug-in only attempts to connect to the server defined with the WebLogicHost parameter. If the attempt fails, an HTTP 503 error message is returned. The proxy plug-in continues trying to connect to that same Oracle WebLogic Server instance for the maximum number of retries as specified by the ratio of ConnectTimeoutSecs and ConnectRetrySecs.

The Dynamic Server List

The WebLogicCluster parameter is required to proxy to a list of back-end servers that are clustered, or to perform load balancing among non-clustered managed server instances.

In the case of proxying to clustered managed servers, when you use the WebLogicCluster parameter to specify a list of Oracle WebLogic Servers, the proxy plug-in uses that list as a starting point for load balancing among the members of the cluster. After the first request is routed to one of these servers, a dynamic server list is returned containing an updated list of servers in the cluster.

The updated list adds any new servers in the cluster and deletes any that have been shut down, or are being suspended, or are no longer part of the cluster or that have failed to respond to requests. This feature can be controlled by using DynamicServerList. For example, to disable this feature, set DynamicServerList to OFF.

DynamicServerList ON is a preferred performance tuning parameter. It is useful, for example, if a member of a cluster is temporarily down for maintenance or if administrators decide they want to add another member, and not need to restart the web server.

Note:

If DynamicServerList is set to ON, and the list of the back-end Oracle WebLogic Servers specified in WebLogicCluster is not in a cluster, then the behavior would be undefined.

Failover, Cookies, and HTTP Sessions

When a request contains session information stored in a cookie or in the POST data, or encoded in a URL, the session ID contains a reference to the specific server instance in which the session was originally established (called the primary server). A request containing a cookie attempts to connect to the primary server. If that attempt fails, the proxy plug-in attempts to make a connection to the next available server in the list in a round-robin fashion. That server retrieves the session from the original secondary server and makes itself the new primary server for that same session. See Figure 3-1.

Note:

If the POST data is larger than 64K, the proxy plug-in will not parse the POST data to obtain the session ID. Therefore, if you store the session ID in the POST data, the proxy plug-in cannot route the request to the correct primary or secondary server, resulting in possible loss of session data.

In this figure, the Maximum number of retries allowed in the red loop is equal to ConnectTimeoutSecs/ConnectRetrySecs.

Failover Behavior When Using Firewalls and Load Directors

In some configurations that use combinations of firewalls and load-directors, any one of the servers (firewall or load-directors) can accept the request and return a successful connection while the primary instance of Oracle WebLogic Server is unavailable. After attempting to direct the request to the primary instance of Oracle WebLogic Server (which is unavailable), the request is returned to the proxy plug-in as "connection reset."

Requests running through combinations of firewalls (with or without load-directors) are handled by Oracle WebLogic Server. In other words, responses of connection reset fail over to a secondary instance of Oracle WebLogic Server. Because responses of connection reset fail over in these configurations, servlets must be idempotent. Otherwise duplicate processing of transactions may result.

Tuning Apache HTTP Server for High Throughput for WebSocket Upgrade Requests

Oracle WebLogic Server 14c (14.1.1.0.0) supports deploying WebSocket applications. The Oracle WebLogic Server 14.1.1.0.0 Proxy Plug-in for Apache HTTP Server 2.4.x can now handle such WebSocket connection upgrade requests and effectively proxy to WebSocket applications hosted within Oracle WebLogic Server 14c (14.1.1.0.0) and later.

As a result of adding this support, a new configuration parameter WLMaxWebSocketClients is introduced.

The WLMaxWebSocketClients parameter limits the number of active WebSocket connections at any instant of time. The maximum value you can set for this parameter is 75 percent of ThreadsPerChild (Windows) or 75 percent of MaxRequestWorkers (non-Windows). Hence, to tune your HTTP Server for maximum WebSocket connection upgrade requests, set MaxRequestWorkers/ThreadsPerChild to a value that can accommodate WebSocket connections as well. Also, ensure that WLMaxWebSocketClients is set to 75 percent of MaxRequestWorkers/ThreadsPerChild.

Deprecated Directives for Apache HTTP Server

The WLLogFile and Debug directives are deprecated. If the configuration uses these directives, a note appears during startup.
[Thu May 14 23:22:19 2015] [warn] weblogic: The Debug directive is ignored.  The web server log level is used instead.

For information about log files, see Verifying the Log File.