Last updated on APRIL 13, 2016

Applies to:

Symptoms

• Oracle Application Server 10g 10.1.3.X.X is installed in a distributed topology
• The topology contains three Oracle Homes - 'ohs only' (ohs1), 'oc4j only' (oc4j1) and another 'oc4j only' (oc4j2). The two oc4j homes are on separate nodes.
• A J2EE application is deployed to a group consisting of two OC4J instances
• First, using the default Oc4jSelectMethod roundrobin in mod_oc4j.conf, the application is accessed and a note of the active OC4J instance is noted.
  
• Next, the active OC4J instance is shut down cleanly from Application Server Control or using opmnctl
• In this case, a clean failover occurs to the other available OC4J instance in the group.
• If a weighted load-balancing scheme is used instead of the default random such as :

Oc4jSelectMethod roundrobin:weighted
Oc4jRoutingWeight <host1> 1
Oc4jRoutingWeight <host2> 1

Oc4jSelectMethod random:weighted
Oc4jRoutingWeight <host1> 2
Oc4jRoutingWeight <host2> 3

• This results in an HTTP-500 error being displayed to the browser.
• The error_log shows:
  

[error] [client 1.1.1.1] [ecid:1213958400:10.174.108.80:24774:0:36,0] mod_oc4j: request to OC4J hostname1.uk.oracle.com:12504 failed:
Connect failed (errno=111)
[error] [client 1.1.1.1] [ecid:
1213958515:10.174.108.80:24803:0:54,0] mod_oc4j: There is no oc4j process (for destination:
application://test) available to service request.

• http://<host>:port/oc4j-status shows correctly that only one oc4j instance is available,so the notification is being received by HTTP Server.
• After some time, or after a restart of OHS, new requests are successfully routed to the available OC4J instance.
• The problem reproduces if the ons discovery method is static or dynamic.
• The problem reproduces if the oc4j mount points are static or dynamic
  

Cause