Oracle® Application Server Release Notes 10g Release 3 (10.1.3.1.0) for Linux x86 Part Number B31014-11 |
|
|
View PDF |
This chapter describes management and security issues associated with Oracle Application Server. It includes the following topics:
This section describes general management and security issues. It includes the following topics:
Section 4.1.1, "Configuring JGroups for Minimum Thread Consumption by Adapters"
Section 4.1.2, "Deploying an Application Hangs During File Upload"
Section 4.1.4, "Limited Management Support for Multiple-JVM OC4J Instances"
Section 4.1.5, "Problem Removing a Property from a Native Data Source"
Section 4.1.6, "Use the Command-Line to Restart Standalone OC4J Instances"
Section 4.1.7, "TopLink Sessions Not Available in Application Server Control Console"
Section 4.1.8, "Unable to Receive MBean Notification Using OPMN to Start or Stop OC4J"
Section 4.1.9, "Using the Java Server Pages Standard Tag Libraries"
Section 4.1.13, "Welcome Page Link to Application Server Control Not Working"
Oracle Application Server Enterprise Deployment Guide describes how to configure JGroups for activation points for adapters, such as file adapter or FTP adapter. If too many file or FTP adapter activations are performed on the system, you may experience performance issues with this configuration, such as:
java.lang.OutOfMemoryError: unable to create new native thread
To avoid this problem, Oracle recommends that you configure JGroups for minimum thread consumption by setting all up_thread
and down_thread
parameters to false
in the JGroup configuration file. For example:
<config> <UDP mcast_port="45566" mcast_addr="228.10.10.10" tos="16" ucast_recv_buf_size="20000000" ucast_send_buf_size="640000" mcast_recv_buf_size="25000000" mcast_send_buf_size="640000" loopback="false" discard_incompatible_packets="true" max_bundle_size="10000" max_bundle_timeout="30" use_incoming_packet_handler="true" use_outgoing_packet_handler="false" ip_ttl="2" enable_diagnostics="false" down_thread="false" up_thread="false" enable_bundling="true"/> <PING timeout="2000" down_thread="false" up_thread="false" num_initial_members="3"/> <!--MERGE2 max_interval="100000" down_thread="false" up_thread="false" min_interval="20000"/--> <FD_SOCK down_thread="false" up_thread="false"/> <!--FD timeout="3000" max_tries="5" down_thread="false" up_thread="false" shun="true"/--> <!--VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/--> <pbcast.NAKACK max_xmit_size="1300" use_mcast_xmit="false" gc_lag="0" retransmit_timeout="200,300,600,1200,2400,4800" down_thread="false" up_thread="false" discard_delivered_msgs="true"/> <UNICAST timeout="300,600,1200,2400,3600" down_thread="false" up_thread="false"/> <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" down_thread="false" up_thread="false" max_bytes="2000000"/> <VIEW_SYNC avg_send_interval="60000" down_thread="false" up_thread="false" /> <pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="false" up_thread="false" join_retry_timeout="2000" shun="true" /> <FC max_credits="5000000" down_thread="false" up_thread="false" min_threshold="0.01"/> <FRAG2 frag_size="1200" down_thread="false" up_thread="false"/> <!--pbcast.STATE_TRANSFER down_thread="false" up_thread="false"/--> </config>
When you deploy an application using Application Server Control, the upload page may keep showing the "upload in progress" message until you manually refresh the page. In the ASControl.log
file, you may see these messages:
WARN util.MultipartRequestUtil _getMultiPartRequestParameter.263 - java.io.IOException: Cannot create temp directory: The system cannot find the path specified
You get this message if the temporary directory specified by the java.io.tmpdir
system property does not exist.
To determine the value of the java.io.tmpdir
system property, go to the Application Server Control's System Property page, which lists the values of system properties. If the directory specified by the java.io.tmpdir
system property does not exist, create the directory and restart the server.
If you have a database associated with a SOA database, then you will need to do a cold backup to ensure a consistent state when restoring the application.
With Oracle Application Server 10g Release 3 (10.1.3.1.0), you can configure any OC4J instance to use multiple Java Virtual Machines (JVMs). You can perform this configuration change by using the Application Server Control Console or by setting the numprocs
argument in the opmn.xml
file to a number greater than one (1).
The opmn.xml
file is located in the following directory in your Oracle Application Server Oracle home:
ORACLE_HOME/opmn/conf/
To set the number JVMs in the Application Server Control Console, see "Creating Additional JVMs for an OC4J Instance" in the Application Server Control online help.
To set the number of JVMs by editing the numprocs
argument in the opmn.xml
file, refer to the following example, which shows the numprocs
entry you must modify:
<ias-component id="OC4J"> <process-type id="home" module-id="OC4J" status="enabled"> .
.
.
<process-set id="default_group" numprocs="2"/>
</process-type>
</ias-component>
Note, however, that this feature is not supported by Application Server Control. Specifically, Application Server Control (represented by the ascontrol
application) cannot run on an OC4J instance that is running multiple JVMs. As a result, be sure that you do not configure multiple JVMs for the administration OC4J instance (the OC4J instance that is hosting the active ascontrol).If you choose to configure the number of JVMs for the administration OC4J to more than one (1), then you must use command line tools to manage your Oracle Application Server environment. For example, you must use:
admin_client.jar
for deployment, re-deployment, undeployment, start and stop applications, and shared library management
Apache Ant for deployment, redeployment, and undeployment of your applications
opmnctl
commands for starting, stopping, and other life cycle operations on the Oracle Application Server
Further, if you are using multiple JVMs on the administration OC4J and, as a result, the Application Server Control Console is not available, then you must make any Oracle Application Server instance configuration changes manually. Manual configuration changes often require you to shut down the Oracle Application Server instance, manually configure the relevant XML files, and then restart Oracle Application Server.
If you use the Application Server Control Console to remove a property from a native data source, Enterprise Manager does not remove the property from the underlying connection factory. As a result, the property (and its current value) is not changed.
This is expected behavior. To set a value on the underlying connection factory, use the setProperty
operation of the JDBCDataSource
MBean for the native Data Source to do this. You can use the MBean Browser, which is available in the Application Server Control Console, to invoke an MBean operation.
See Also:
"About the MBean Browser" in the Application Server Control online helpSome OC4J configuration pages in the Application Server Control Console (including the JTA Administration and Oracle Internet Directory Association pages) require a restart of the OC4J instance for changes to take affect. Users are notified of this with on screen warnings during configuration operations on these components.
If are using the Application Server Control Console in a standalone OC4J environment, and you use the Restart link, which is displayed after applying changes to one of these pages, the operation may take a few minutes because it performs an internal restart of the OC4J instance. As a result, instead of using the Restart link, Oracle recommends that OC4J standalone users use the command line to restart the OC4J instance.
If the TopLink Sessions for a TopLink-enabled application are not available in Application Server Control Console, check to be sure the TopLink session is configured to create the MBeans at login time. This is done by ensuring that the application has a serverPlatform
class defined, and that the ServerPlatform
class has its is RuntimeServicesEnabled
flag enabled.
For Oracle Application Server 10g Release 3 (10.1.3.1.0), you should be using the following platform class, which can be set in the sessions.xml
or through the session API:
oracle.toplink.platform.server.oc4j.Oc4j_10_1_3_Platform
When developing a TopLink-enabled application using Oracle JDeveloper, make sure to use version 11 or higher.
See Also:
"Configuring the Server Platform" in the Oracle TopLink Developer's GuideYou will not be able to receive notification from the ias:j2eeType=J2EEServer,name...
MBean entity if you start or stop Oracle Containers for J2EE (OC4J) using OPMN. This happens using either the Application Server Control or the opmnctl stop
or opmnct start
command from the command line.
There is presently no workaround for this issue.
The Java Server Pages Standard Tag Library (JSTL) makes use of Jaxp 1.2 classes that are packaged with Java Developer Kit 1.4.
Oracle Application Server 10g Release 3 (10.1.3.1.0) makes use of JDK 1.5 which uses Jaxp 1.3 classes. However, the JSTL still requires the Jaxp1.2 classes. If you run the JSTL with XML related tags in JDK 1.5 you may receive an error message similar to:
: missing class org.apache.xpath.encounter failure.
To avoid JSTL failure, include the xalan.jar
file in the required .war
file. Add the xalan.jar
file into your /WEB-INF/lib
directory with the .war
file and then re-package.
For more information refer to the JSTL release notes at:
http://java.sun.com/webservices/docs/1.6/jstl/ReleaseNotes.html
.
As documented in the Oracle Process Manager and Notification Server Administrator's Guide and functional specifications for Dynamic Resource Management (DRM), a Resource Management Directive (RMD) conditional can have a fully qualified path. However, the conditional may not evaluate at all. It may fail to trigger any action or exception even though the opmn.xml
file is valid.
RMD definitions can be either:
Hierarchical: if defined at the ias-instance
level or lower. Hierarchical RMDs assume an association within the OPMN configuration components in which they are defined.
Global: if defined at the process-manager
level. Global RMDs require explicit OPMN component specifications.
If you are referencing a hierarchical RMD, instead of a fully qualified path use a hierarchical relative reference.
For example, if the average request time is greater than 500 milliseconds for at least 60 seconds and there are less then 4 processes running for the process-set
at which the hierarchical RMD was configured for OC4J, you would use the following in the opmn.xml
file:
([process].avgReqTime > 500 {duration(60)})&([process-set].numProcs < 4)
If you are referencing a global RMD use a global absolute reference.
For example, if the heap size of a Java Virtual Machine (JVM) has exceeded 500 MBs, you would use the following in the opmn.xml
file:
[process-set=home][process].heapSize > 500000
Note that the opmn.xml
file is located in the following directory in your Oracle Application Server Oracle home:
ORACLE_HOME/opmn/conf/
When you install Oracle Application Server 10g Release 3 (10.1.3.1) and specify a name for the default OC4J instance, do not use a name that matches the name of the Oracle Application Server instance or the first few characters of the Oracle Application Server instance name; otherwise, you will be unable to browse the system or applications MBeans using the Application Server Control MBean Browser.
For example, you will not be able to browse the MBeans for the instance if the name of your OC4J instance and the name of your Oracle Application Server instance are as follows:
Oracle Application Server instance name: instance1_as10132.node1.acme.com OC4J instance name: instance1
Similarly, keep this restriction in mind when you are creating additional OC4J instances. Do not use a name that matches the name of the Oracle Application Server that is hosting the OC4J instance.
The following sections describe some important considerations if you are patching a 10g Release 3 (10.1.3.1.0) Oracle home and you selected the following installation options when you installed the 10g Release 3 (10.1.3.1.0) Oracle home:
You selected the Advanced Install option
You selected the J2EE Server, Web Server and SOA Suite installation type
You configured the instance to serve as an Administration OC4J instance.
If you selected all of these options while installing Oracle Application Server 10g Release 3 (10.1.3.1.0), then in rare circumstances the Oracle Enterprise Manager 10g Application Server Control Console does not display when the installation is complete.
If you have experienced this problem, see the following sections for more information:
If you have experienced this problem and fixed it previously, be sure to use the following individual commands to start the application server instance. Do not use the opmnctl startall
command:
opmnctl start opmnctl startproc process-type=<OC4J instance name 1> opmnctl startproc process-type=<OC4J instance name 2> opmnctl startproc process-type=<Oracle HTTP Server instance name>
If you cannot display the Application Server Control Console after installing 10g Release 3 (10.1.3.1.0) with these options selected, the server.xml
files in your application server instance might have become corrupted during the installation.
Do the following to correct the problem:
Use a text editor to open the server.xml
file for the home
OC4J instance:
ORACLE_HOME/j2ee/home/config/server.xml
Make sure that the following entry exists in the server.xml
file for the home
instance:
<global-application name="default" path="application.xml" parent="system" start="true" />
Save and close the server.xml
file for the home
instance.
Use a text editor to open the server.xml
file for the oc4j_soa
OC4J instance:
ORACLE_HOME/j2ee/oc4j_soa/config/server.xml
Note:
oc4j_soa is the default name of the second OC4J instance installed b y the Advanced Install option. If you entered a different name for this instance on the Administration Settings screen of the installer, then replace oc4j_soa in the previous example with the name you entered on the Administration Settings page.Make sure that the following entry exists in the server.xml
file for the oc4j_soa
instance:
<application name="ascontrol" path="../../home/applications/ascontrol.ear" parent="system" start="false" />
Save and close the server.xml
file for the oc4j_soa
instance.
Stop and then start both the home
instance and the oc4j_soa
instance.
Caution:
To prevent this problem from happening again, do not use theopmnctl startall
command to start the application server instance. Instead, each time you need to restart the application server instance, be sure to use the following separate commands to stop and restart each component of the application server:
opmnctl start opmnctl startproc process-type=<OC4J instance name 1> opmnctl startproc process-type=<OC4J instance name 2> opmnctl startproc process-type=<Oracle HTTP Server instance name>
Tip:
"Starting and Stopping" in the Oracle Application Server Administrator's GuideThe latest Oracle Application Server 10g Release 3 (10.1.3.1.0) Release Notes available in the 10g Release 3 (10.1.3.0.0) documentation library on the Oracle Technology Network
The Oracle Application Server Welcome Page contains a link to Application Server Control. If this link is not working:
Edit $ORACLE_HOME/Apache/Apache/htdocs/index.html.html
.
Locate the following entry:
<a href="/em">
Replace it with the following entry, substituting in your Application Server Control hostname and port number:
<a href="http://hostname:port/em">
This section describes clustering and replication issues. It includes the following topic:
Oracle Universal Installer provides an example cluster discovery address as part of the advanced installation option. The provide example discovery address is 225.0.0.1:6789
. This is not a recommended address; rather it is an example intended to provide the type of cluster discovery address users may ask for from their network administrator.
Because the cluster configuration of Oracle Application Server is fully dynamic it is possible for installations using the example cluster discovery address (225.0.0.1:6789
) to be inadvertently clustered with other servers installed with the same example cluster discovery address.
The cluster discovery address of a specific Oracle Application Server instance can be set from the command line using the following opmnctl
command:
> $ORACLE_HOME/opmn/bin/opmnctl config topology update discover=<cluster config address>
For example, to update a cluster discovery address in a specific Oracle Application Server instance to be 225.0.0.1:9876
, the command would be:
> $ORACLE_HOME/opmn/bin/opmnctl config topology update discover="*225.0.0.1:9876"
Details on configuring topologies and the cluster discovery address can be found in Chapter 8, "Configuring and Managing Clusters" of the Oracle Containers for J2EE Configuration and Administration Guide.
The section describes documentation errata in management documentation. It includes the following topics:
Section 4.3.3, "Additional Information for Changing Hostname"
Section 4.3.4, "Additional Information About Cloning and Oracle Enterprise Service Bus"
Section 4.3.6, "Online Help for the Java SSO Session Timeout Field is Incorrect"
Section 4.3.7, "Default Ping Timeout Value in OPMN Is 30 Seconds, Not 20"
Section 4.3.9, "Enabling and Disabling Components Is Supported"
The following topics in the Application Server Control online help incorrectly state the valid range of addresses you can use for a multicast address when configuring an Oracle Application Server 10g Release 3 (10.1.3.1.0) cluster topology:
"Tips When Configuring the Cluster Topology"
"Summary of the Supported Cluster Topologies"
The multicast address must be within the following range: 224.0.1.0
to 239.255.255.255.
To use the latest J2EE features of Oracle Application Server, 10g Release 3 (10.1.3.1.0), with existing Oracle Application Server, Release 2 (10.1.2), components and applications, you can use the Oracle HTTP Server from an Oracle Application Server, Release 2 (10.1.2), middle tier as the front-end for your Oracle Application Server, 10g Release 3 (10.1.3.1.0), middle tier. Section 6.4 of the Oracle Application Server Administrator's Guide describes how to do this.
However, in that section, the following command is incorrect:
ORACLE_HOME_SERVER2/opmn/bin/opmnctl config port update ias-component=OC4J process-type=instance name portid=default-web-site protocol=ajp
The command should be:
ORACLE_HOME_SERVER2/opmn/bin/opmnctl config port update ias-component=default_group process-type=instance name portid=default-web-site protocol=ajp range=12501-12600
If your environment includes Oracle Enterprise Service Bus, the following describes additional information that is not currently documented in Section 7.2.2 of the Oracle Application Server Administrator's Guide:
In Task 9, Step 1 describes editing the esbparam.properties
file to change the DT_OC4J_HOST property. Additionally, if the port number changed, you must change the DT_OC4J_HTTP_PORT property.
After you import the esbparam.properties
file as described in Step 3, you must redeploy all applications, including Oracle BPEL Process Manager applications.
If your environment includes Oracle Enterprise Service Bus, the following describes additional information that is not currently documented in Section 9.5.6 of the Oracle Application Server Administrator's Guide:
In the part that describes steps to take on the cloned instance, step 2 describes editing the esbparam.properties
file on the cloned instance to change the DT_OC4J_HOST property to the new hostname. Note that if the cloned instance is located on a remote host, you must change both the DT_OC4J_HOST and DT_OC4J_HTTP_PORT properties. If the cloned instance is on the same node as the source instance, you must change the DT_OC4J_HTTP_PORT property.
After you import the esbparam.properties
file as described in Step 4, you must redeploy all applications, including Oracle BPEL Process Manager applications.
The following contains additional and corrected information about cloning, to supplement and correct the information in the cloning chapter of the Oracle Application Server Administrator's Guide:
Section 9.6.1 does not give an example of how to add additional options to the clone_command_line. The following information should be added:
To specify multiple arguments, append the argument to the clone_command_line
, separating each argument with a space. Do not add additional clone_command_line
lines. The following example shows how to specify two arguments:
clone_command_line= -silent -invptrloc /private/oracle/oraInst.loc oracle.as.j2ee.top:szl_PortListSelect="{YES, /tmp/staticports.ini}"
Section 9.6.2 does not specify the location of the cs.properties file. The file is located in:
(UNIX) ORACLE_HOME/clone/ias/config/cs.properties (Windows) ORACLE_HOME\clone\ias\config\cs.properties
The example in Section 9.6.2 uses an incorrect option. The correct example is:
clone_command_line= oracle.as.j2ee.top:szl_PortListSelect="{YES, /tmp/staticports.ini}"
If you set VIRTUAL_HOST_NAME when you installed the Oracle Application Server instance, you must update the OUI_HOSTNAME parameter in the following file with the VIRTUAL_HOST_NAME, before you run the prepare_clone script:
(Unix) ORACLE_HOME/inventory/Clone/clone.xml (Windows) ORACLE_HOME\inventory\Clone\clone.xml
The online help provided for the *Session Timeout (secs)* field on the Java SSO Configuration page in the Oracle Enterprise Manager Application Server Control is incorrect. The field is documented correctly in Table 14-1, "Java SSO Properties," in the Oracle Containers for J2EE Security Guide.
The Session Timeout is the period of time (in seconds) for which the Java SSO cookie is valid. Note that this is a hard timeout, not an inactivity timeout.
The session will timeout after this amount of time no matter what. The default for this configuration setting is 7200 seconds (2 hours).
The Oracle Process Manager and Notification Server Administrator's Guide incorrectly states that the default ping timeout value is 20 seconds. It is actually 30 seconds.
In chapter 6, "opmn.xml Common Configuration", of the Oracle Process Manager and Notification Server Administrator's Guide, the last example shown in the <gateway>
section may produce a validation error. The example shows these two lines:
<gateway list="host1a.subA.com:6200&host2a.subA.com:6200/host1b.subB.com:6200&host2b.subB.com:6200"/> <gateway list="host1b.subB.com:6200&host2b.subB.com:6200/host1a.subA.com:6200&host2a.subA.com:6200"/>
You may get the following error if you use the lines above:
In line 9 of /scratch/aime1/10133/ohs/opmn/conf/opmn.xml: LPX-00241: entity reference is not well formed XML parse failed: error 241. opmnctl: opmn.xml validation failed.
To fix this, you should merge the two lines into a single line, as follows:
<gateway list="host1a.subA.com:6200& host2a.subA.com:6200/host1b.subB.com:6200&host2b.subB.com:6200, host1b.subB.com:6200&host2b.subB.com:6200/host1a.subA.com:6200& host2a.subA.com:6200"/>
The Oracle Application Server Administrator's Guide incorrectly states that enabling and disabling components is not supported. Although it is not supported in Application Server Control Console, it is supported by OPMN. For more information on enabling and disabling components, see the Oracle Process Manager and Notification Server Administrator's Guide.
In Oracle Process Manager and Notification Server Administrator's Guide, section 6.2, "opmn.xml Element and Attribute Descriptions", the request
attribute description contains the following incorrect statement:
"The request
attribute is for the IP address or host name to which ONS will bind its remote port."
The correct statement is:
"The request
attribute is for the IP address or host name to which ONS will bind its request port."
In Section 7.6, "Generic Apache (Linux only)", of the Oracle Process Manager and Notification Server Administrator's Guide the title is incorrect. The listed configuration for the Oracle HTTP Server process module to manage generic Apache processes is valid for Linux and Microsoft Windows operating systems.
When securing your OC4J instance, DMS will no longer work as DMS does not support AJPS and HTTPS protocols.
Since DMS always makes requests to localhost, one workaround is to configure OC4J instances to bind only to local host for AJP and HTTP requests when SSL is enabled.