This FAQ addresses frequently
asked questions relating to the Oracle Application Server 10g
Release 2 (10.1.2) version of Oracle HTTP Server.
Besides the Oracle HTTP Server, Oracle Application Server has a
number of infrastructure components that provide real-time monitoring,
high availability, and distributed configuration management.
This FAQ covers these components and is divided into the following
sections:
Two versions: 1.3.31 for Oracle HTTP Server based on Apache
1.3, and 2.0.52 for Oracle HTTP Server based on Apache 2.0.
No, you should not apply those patches for the following reasons: (a) Oracle tests and appropriately
modifies the patches before releasing them to Oracle HTTP
Server users. (b) In many cases, the alerts may not be applicable
(for example, openSSL alerts) because Oracle has removed the relevant components
from the stack in use. (c) Oracle releases these patches in a timely manner so that the time-delay impact of getting the patch from
Oracle instead of the open-source organization is minimal and
the benefit with respect to supportability is significant.
Yes, mod_php is supported.
Yes. However, Apache 2.0 is only supported in a standalone
deployment version. It has the same functionality as Apache
1.3 version of Oracle HTTP Server except for the following:
- IPv6 is supported on 2.0 versions but not 1.3 versions.
- mod_oradav is not supported on 2.0 versions.
- mod_dms is not supported on 2.0 versions.
- mod_plsql is not supported on 2.0 versions.
Oracle HTTP Server is running as root only so that users can
switch to ports less than 1024. If this will never be
the case, then users can run Oracle HTTP Server as the user that
installed OracleAS instead of root. In order to do this,
perform the following steps:
- Shut down Oracle HTTP Server.
- Switch to root.
- cd $ORACLE_HOME/Apache/Apache/bin
- chown <oracle ias user> .apachectl
- cd $ORACLE_HOME/Apache/Apache/logs
- rm -f *
- If you are using mod_osso, reregister mod_osso.
- Exit root.
- Restart Oracle HTTP Server.
In general, the recommendation is to use OracleAS Web Cache
for this purpose. There are other freeware modules (for example, mod_gzip)
that may be plugged in for this purpose, but their use is not
supported. If you do use any of these modules, you may see an error message with respect to EAPI, which you can generally ignore.
Back to Top
The error message indicates that OC4J failed to bind to
one of its ports (ajp, etc). Ensure that valid available
ports have been specified. Refer to the Oracle
Process Manager and Notification Server Administrator's Guide for troubleshooting information.
The local attribute specifies a local port for notification
traffic within the iAS instance. This port can also handle administrative
requests like starting and stopping the iAS instance. It cannot
handle SSL. The remote port is for inter iAS instance
notification traffic. It is also capable of handling administrative
requests and supports SSL. The request port is to send
requests for certain OPMN data dumps. It cannot handle any administrative
commands.
Within the ohs and oc4j tags, you need to add directives such
as the following:
<environment>
<prop name="PATH" value="/private/hwen/ias/lib"/>
<prop name="CLASSPATH" value="/private/hwen/ias/bin">
</environment>
The 'level' attribute is optional and its default value is 3.
It is used to indicate the severity level for logging messages.
Specifying a level causes all messages of the severity level
and higher to be logged. Possible values are
1=FATAL, 2=ERROR, 3=WARN, 4=NOTIFY, 5=DEBUG,
6=VERBOSE
Back to Top
mod_oc4j is a module that integrates with Web servers—typically
Oracle's HTTP Server—and routes the request to the back-end OC4J
processes. OPMN module keeps mod_oc4j aware of the status
of different OC4J processes—thus, mod_oc4j routes only to
the processes that are up and running. mod_oc4j also understands
the concepts of OracleAS clusters and OC4J islands, and it routes
accordingly to provide as much transparent failover as possible.
Yes, beginning with 904, other Web servers including IIS, iPlanet,
and vanilla Apache are supported with mod_oc4j.
The format of the cookie is the following:
cookie : oc4jpart.ohspart
ohspart : oh:op:uid
oh : <oc4j host>
op : <oc4j port>
uid : ic#ii#opid#grp#oi#isl
ic : <ias cluster name>
ii : <ias instance name>
opid : <opmn id>
grp : <opmn group name>
oi : <oc4j instance name>
isl : <oc4j island name>
Since mod_oc4j needs all the above information to be able to
successfully route and failover between requests, it needs to
be tracked in the cookie.
When an old OC4J process is replaced by a new one, if the new
OC4J process listens on the same port as the old one and it is
up and running, the request will be routed to it. If the
new OC4J process listens on another port, mod_oc4j will failover
(transparently) to an OC4J process which is on the same island,
based on a deterministic selection algorithm.
mod_oc4j provides three
distinct kinds of routing: (a) round robin to all OC4J processes
or (b) random or (c) metric based. The effective performance of
round robin and random algorithms is the same. Metric-based routing is based on the OC4J process informing mod_oc4j of
a metric based on its internal resource availability (for example, connection
pools). mod_oc4j then uses this metric to route elsewhere.
Note that metric-based routing is not based on CPU and/or
memory utilization of a given machine.
The default mode for round robin and metric-based algorithms is affinity based. In this mode, these algorithms will always route to the local node, except in cases when no process is available on the local node.
For more detailed explanations of the routing algorithms, see the documentation.
Yes, the AJP communication between mod_oc4j and OC4J processes
can now be encrypted using SSL. Also,Oracle's implementation does not impose significant overhead because SSL negotiation does not happen every time the two need to
talk.
Back to Top |
