Restart Oracle HTTP Server on all instances in the topology for the changes to take effect.

> opmnctl @cluster restartproc ias-component=HTTP_Server

Choosing a mod_oc4j Load Balancing Algorithm

Use the following guidelines to help determine which mod_oc4j load balancing option to use:

■ In a topology with identical machines running Oracle HTTP Server and OC4J in the same Oracle home, the round robin with local affinity algorithm is preferred. In this case Oracle HTTP Server gains little by using mod_oc4j to route requests to other machines, except in the extreme case that all OC4J processes on the same machine are not available.

■ For a distributed deployment, where one set of machines runs Oracle HTTP Server and another set runs OC4J instances that handle requests, the preferred algorithms are simple round robin and simple metric-based. To determine which of these two works better in a specific setup, you may need to experiment with each and compare the results. This is required because the results are dependent on system behavior and incoming request distribution.

■ For a heterogeneous deployment, where the different Oracle Application Server instances run on nodes that have different characteristics, the weighted round robin algorithm is preferred. In addition to setting the weight for each instance, remember to tune the number of OC4J processes running on each Oracle Application Server instance to achieve the maximum benefit. For example, a machine with a weight of 4 gets four times as many requests as a machine with a weight of 1, but you need to ensure that the system with a weight of 4 is running four times as many OC4J processes.

■ Metric-based load balancing is useful when there are only a few metrics that dominate the performance of an application, for example, CPU or number of database connections.

3.2.13 Configuring Java Message Service (JMS) for High Availability

For information on how to configure JMS for high availability, see chapter 3, "Java Message Service (JMS)", in the Oracle Containers for J2EE Services Guide.

Summary of High Availability Features in Oracle HTTP Server and OC4J

3.3 Summary of High Availability Features in Oracle HTTP Server and

OC4J

Table 3–5 summarizes some of the high availability features in Oracle HTTP Server and OC4J.

3.4 Miscellaneous Topics

■ Section 3.4.1, "JNDI Namespace Replication" ■ Section 3.4.2, "EJB Client Routing"

■ Section 3.4.3, "OC4J Distributed Caching Using Java Object Cache"

3.4.1 JNDI Namespace Replication

When EJB clustering is enabled, JNDI namespace replication is also enabled between the OC4J instances in a middle-tier OracleAS Cluster. New bindings to the JNDI namespace in one OC4J instance are propagated to other OC4J instances in the middle-tier OracleAS Cluster. Re-bindings and unbindings are not replicated. The replication is done outside the scope of each OracleAS Cluster (OC4J). In other words, multiple OracleAS Clusterss (OC4J) in an OC4J instance have visibility into the same replicated JNDI namespace.

Table 3–5 Summary of High Availability Features in Oracle HTTP Server and OC4J

Item Description

Protection from Node Failure

Oracle HTTP Server: A load balancer deployed in front of Oracle HTTP Server instances protects from node failure. The load balancer can be an external load balancer or OracleAS Web Cache (OracleAS Web Cache is from Release 2 (10.1.2)). OC4J: mod_oc4j routes requests only to OC4J instances that are alive. You should install and run OC4J instances on different nodes to provide greater probability that OC4J is alive and running on at least one node at any time.

Protection from Service Failure

Oracle HTTP Server: A load balancer deployed in front of Oracle HTTP Server instances sends request to another Oracle HTTP Server if first one does not respond or is deemed failed through URL pings. The load balancer can be an external load balancer or OracleAS Web Cache.

OC4J: OPMN monitors OC4J processes and restarts them upon process failure. OPMN also notifies mod_oc4j if the restart was not successful so that mod_oc4j will send requests only to OC4J processes that are alive.

Protection from Process Failure

Oracle HTTP Server: OPMN monitors Oracle HTTP Server processes and restarts them upon process failure. Each Oracle HTTP Server is also notified by OPMN when another Oracle HTTP Server process in the topology fails.

OC4J: OPMN monitors OC4J processes and restarts them upon process failure. OPMN also notifies mod_oc4j if the restart was not successful so that mod_oc4j will send requests only to OC4J processes that are alive.

Automatic Re-routing Oracle HTTP Server: A load balancer deployed in front of Oracle HTTP Server instances automatically re-routes to another Oracle HTTP Server if the first one does not respond.

OC4J: mod_oc4j automatically re-routes to another OC4J process if the first one does not respond.

See Also:

See the Oracle Containers for J2EE Services Guide for details on JNDI.

3.4.2 EJB Client Routing

In EJB client routing, EJB classes take on the routing functionality that mod_oc4j provides between Oracle HTTP Server and servlets/JSPs. Clients invoke EJBs using the Remote Method Invocation (RMI) protocol. The RMI protocol listener is set up by in the RMI configuration file, rmi.xml, for each OC4J instance. It is separate from the Web site configuration. EJB clients and the OC4J tools access the OC4J server through a configured RMI port. OPMN designates a range of ports that the RMI listener could be using.

When you use the "opmn:ormi://" prefix string in the EJB look up, the client retrieves the assigned RMI port automatically. The load balancing and client request routing is provided by OPMN selecting the different OC4J processes available. The algorithm used for this load balancing is the random algorithm. Multiple OPMN URLs separated by commas can be used for higher availability.

3.4.3 OC4J Distributed Caching Using Java Object Cache

Oracle Application Server Java Object Cache provides a distributed cache that can serve as a high availability solution for applications deployed on OC4J. The Java Object Cache is an in-process cache of Java objects that can be used on any Java platform by any Java application. It enables applications to share objects across requests and across users, and coordinates the life cycle of the objects across processes. Java Object Cache enables data replication among OC4J processes even if they do not belong to the same OracleAS Clusters (OC4J), Oracle Application Server instance, or overall Oracle Application Server Cluster.

By using Java Object Cache, performance can be improved because shared Java objects are cached locally, regardless of which application produces the objects. This also improves availability; in the event that the source for an object becomes unavailable, the locally cached version is still available.

See the "Java Object Cache" chapter in the Oracle Containers for J2EE Services Guide for details on using Java Object Cache.

4