Whenever you deploy a web application to a WebLogic cluster, you need something sitting before the cluster (i.e., between the client and the cluster) that can direct incoming requests to the appropriate server that hosts the primary session state. There are many ways in which you can accomplish this:
Hardware load balancer
A hardware load balancer can be placed in front of the cluster. In this case, all client requests to the cluster must pass through the load balancer. The load balancer can distribute requests across the available members of the cluster, and direct requests involved in a session to the appropriate server holding the primary state.
Web server with proxy plug-in
A web server can be augmented with a proxy plug-in, a piece of software supplied with WebLogic that will redirect certain requests (for example, those to servlets and JSPs) through to the cluster. Clients accessing the web server then can be served up static content by the web server directly and transparently proxied through to the cluster behind the web server for the dynamic content.
WebLogic with the HttpClusterServlet
The HttpClusterServlet is an alternative to a proxy plug-in. A WebLogic instance can be configured to host the servlet, which can forward requests across to the cluster in the same way as the proxy plug-in.
The main ways in which you can architect your cluster and web tiers are discussed in much more detail in Chapter 14. Here we will give a brief introduction to setting up the HttpClusterServlet, leaving the configuration of the proxy plug-ins, an almost identical task, to Chapter 3.
2.8.1 Configuring HttpClusterServlet
As its name suggests, the HttpClusterServlet is a servlet. It is supplied with WebLogic. To put the servlet into action, create a simple web application with the servlet configured as part of the web application. You need to then deploy the web application to the machine that is going to serve as the main gateway to your cluster, as suggested by Figure 2-2.
Figure 2-2. Example clustering setup
As detailed in Figure 2-2, the idea is that requests that go to the server instance called Front Server are to be redirected to one of the servers in the cluster. If Server A and Server B form a cluster, then the HttpClusterServlet will load-balance new requests between the servers, and session replication and failover will occur as detailed in the previous section. The cluster servlet maintains a list of all the servers participating in the cluster and avoids redirecting to failed servers. The client has direct access to the Front Server only, and remains unaware of the actual cluster member that eventually processes its requests.
The configuration entails several tasks, and we will use the architecture in Figure 2-2 in our configuration details.
Registering the servlet is like registering any other servlet. The class name for the servlet is weblogic.servlet.proxy.HttpClusterServlet, and it is included within WebLogic's runtime libraries. The following snippet from the web.xml descriptor file does the job:
As shown earlier in this chapter, you can create a servlet mapping to determine the set of URLs to pass to the servlet. For instance, we would like a request such as http://10.0.10.10/index.jsp to result in the cluster servlet being invoked, which will in turn proxy through to the appropriate server in the cluster. The easiest way to establish a mapping for all files is to use the special shortcut URL pattern, /, together with explicit mappings for HTML and JSP files:
HttpClusterServlet / HttpClusterServlet *.jsp HttpClusterServlet *.html
The servlet also has to be configured with the addresses of the servers in the cluster and other information. This must be done with the servlet initialization parameters. The most important parameter, WebLogicCluster, configures the addresses and ports of the members of the cluster. For the preceding example, you need the following:
The servlet can take a whole host of additional parameters, all of which are detailed in the proxy plug-in documentation in Chapter 3.
Once the cluster servlet has been configured and deployed, requests to the server Front Server will be mapped to the appropriate server in the cluster. So, assuming we have a web application deployed to the cluster, accessing http://10.0.10.10/index.jsp will result in the following activity:
2.8.2 Debugging the Configuration
The HttpClusterServlet supports the DebugConfigInfo initialization parameter, which is useful for debugging the servlet's configuration. If you've specified this initialization parameter for the HTTPClusterServlet, the servlet returns the details of its configuration whenever you invoke a servlet along with the query parameter _ _WebLogicBridgeConfig, instead of passing the request through to the cluster. In order to debug the servlet's configuration, you need to use the web.xml descriptor file to specify the initialization parameter for the HttpClusterServlet:
Now you can view the configuration of the HttpClusterServlet by navigating to a URL similar to http://10.0.10.10/index.jsp?__WebLogicBridgeConfig. In the case of our example cluster setup, we obtain the following details on the servlet's configuration:
Query String: _ _WebLogicBridgeConfig Primary Server: 10.0.10.12:7001:7002 General Server List: 10.0.10.12:7001:7002 10.0.10.14:7001:7002 ConnectRetrySecs: 2 ConnectTimeoutSecs: 10 CookieName: JSESSIONID Debug: false DebugConfigInfo: true DefaultFileName: null DisableCookie2Server: false DynamicServerList: true FileCaching: true HungServerRecoverSecs: 300 Idempotent: true KeepAliveEnabled: true KeepAliveSecs: 30 MaxPostSize: -1 MaxSkipTime: 10 PathPrepend: null PathTrim: null TrimExt: null SecureProxy: false WLLogFile: c:/temp/wlproxy.log WLProxySSL: false
Note how the output lists the servers participating in the cluster, and also indicates the primary server to which the request has been bound (if any).
Managing the Web Server
Using JNDI and RMI
Using CMP and EJB QL
Packaging and Deployment
Performance, Monitoring, and Tuning
Logging and Internationalization