WebSphere Plug-in basics

The IBM WebSphere Application Server Web server plug-in is the “glue” between a Web server and WebSphere Application Server. The primary responsibility of the plug-in is to forward HTTP requests from the Web server to the WebSphere Application Server using the HTTP protocol. . 

Using the plug-in has many advantages:

• The plug-in provides work load management and failover capabilities by distributing requests evenly to multiple application servers and routing requests away from a failed application server.
• Static content can be served by the Web server without doing a full round trip to the application server, thus providing better performance. 
• The Web server provides an additional hardware layer between the Web browser and the application server, thus strengthening the application server’s security. 

Plug-in operation 

Essentially, there are four functions of the plug-in:

a. Initialization

b. URL matching and clone determination

c. Sending requests to the application server

d. Receiving responses from the application server 

a. Initialization

When IHS is started (using the command <IHS_HOME>\apache –k start), the IHS configuration file <IHS_HOME>\conf\httpd.conf is read during the initialization. If WebSphere is configured to use that instance of IHS, the httpd.conf file contains the following two directives:

LoadModule ibm_app_server_http_module <WASDIR>/bin/mod_ibm_app_server_http.dll

WebSpherePluginConfig <WAS5_HOME>\config\cells\plugin-cfg.xml

LoadModule points to the plug-in DLL, and WebSpherePluginConfig points to the plugin-cfg.xml file, which lists all the URLs that are to be serviced by the WebSphere cell.

When the Web server is starting, it loads the plug-in DLL, and then:

1. loads the plugin-cfg.xml into the plug-in process

2. parses and validates the plug-in configuration file.

Once the DLL has been found and loaded, and the configuration file has been found, loaded and successfully parsed, then initialization is complete and the plug-in is ready to receive HTTP requests.

b. URL matching and Clone determination

Whenever the Web server receives a new HTTP request, it first passes that request to the plug-in. If the plug-in is not configured to service that URI, then, and only then, does the Web server handle the request. The plug-in determines whether this request should be handled by WebSphere by matching the URL requested to all the URLs defined in plugin-cfg.xml. 

The purpose of a plug-in configuration file is to take a request and associate it with a server (clone) in a ServerCluster. The basic algorithm is very simple:

•  The plug-in compares the request to each route.
• If a match for URIGroup and VirtualHostGroup is found, the plug-in sends the request to the associated ServerCluster
• If there are multiple servers in the server cluster, the request is sent to one of them depending upon various factors such as WLM policy, session information, etc. 

c. Sending the request to the application server

The plug-in does more than simply “forward” the browser’s request to the application server using TCP/IP. 

The plug-in knows that the request has been successfully sent to the application server if it receives a successful TCP/IP acknowledgement back from the application server’s TCP/IP layer. If the TCP/IP response does not come back within the timeout period, an HTTP error 500 is returned to the Web browser. This timeout is either the OS level TCP/IP timeout or the ConnectTimeout parameter in plugin-cfg.xml, whichever is lower. 

If the plug-in is unable to send a request to a particular application server, it will mark that application server as being unreachable and will redirect that request (and all future requests) to the next clone in that ServerCluster. This failure/redirection step will cause a delayed response to the first request which detects the failed application server. If session sharing is enabled (using either persistence or in-memory session replication), the new clone will pick up the session information, and there will be no loss of session. But if the session is not being shared, it will cause the session information to be lost, and the user will have to create a new session. The browser gets an HTTP error 500 if every clone in the ServerCluster is down. 

The plug-in will not send future requests to the failed application server for a period specified by the RetryInterval attribute on the ServerCluster tag in plugin-cfg.xml. The unit of the RetryInterval is in seconds. 

d. Receiving response from the application server

After sending a request to the application server, the plug-in goes into a wait state (waiting for the response). The end of this wait state can be reached in the following ways: 

a. Expected behavior: When a response from the application server has been received by the plug-in, the response is passed on to the Web server and then to the Web browser.

b. Unexpected behavior: The request times out at a network level; the OS level TCP/IP times out because the destination (application server) is unreachable. This default TCP/IP timeout value varies depending on the OS. The OS level error seen in http_plugin.log is ETIMEDOUT.

c. Unexpected behavior: The request times out at a network level due to the ConnectTimeout parameter specified in plugin-cfg.xml. The OS level error in http_plugin.log is EINPROGRESS. 

d. Unexpected behavior: If the application server’s IP address is reachable but the port is not up (for example, if the application server is in the stopped state), the request will fail with the OS level error ECONNREFUSED. This error is received instantly and is not dependent on long network timeouts. You will see this error in http_plugin.log.

If the request fails, the application server is marked as unreachable and is then taken out of the routing algorithm for a period specified by the RetryInterval. If the failed application server is cloned, this request is passed on to other clones in the ServerCluster. If communication with every clone in the cluster fails due to network timeouts, the Web browser will receive an HTTP error 500.