| Oracle® Containers for J2EE Configuration and Administration Guide 10g (10.1.3.1.0) Part Number B28950-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Configuration and Administration Guide 10g (10.1.3.1.0) Part Number B28950-01 |
|
|
View PDF |
This chapter explains how to configure and manage cluster topologies in an Oracle Application Server environment and groups of OC4J instances within Oracle Application Server clusters. It includes the following topics:
Creating and Managing OC4J Groups Within Oracle Application Server Clusters
Configuring Routing and Load Balancing with Oracle HTTP Server
Application clustering, the clustering of applications deployed to Oracle Application Server nodes for the purpose of session or state replication, is covered in Chapter 9, "Application Clustering in OC4J".
This section provides an overview of the clustering mechanisms supported in Oracle Application Server 10g Release 3 (10.1.3.1.0) and notes the significant changes in functionality between the 10.1.3 release and previous releases. It includes the following topics:
In the current release, a cluster topology is defined as two or more loosely connected Oracle Application Server nodes.
The connectivity provided within a cluster is a function of Oracle Notification Server (ONS), which manages communications between Oracle Application Server components, including OC4J and Oracle HTTP Server. The ONS server is a component of Oracle Process Manager and Notification Server (OPMN), which is installed by default on every Oracle Application Server host. When configuring a cluster topology, you are actually connecting the ONS servers running on each Oracle Application Server node.
Previous releases of Oracle Application Server supported clustering of a fully connected set of server nodes only, which meant that each node had to be explicitly specified in the ONS configuration file (ons.conf). When a node was added or removed from the cluster, the configuration had to be updated on each server node and the server restarted.
The current release supports a new dynamic discovery mechanism, enabling the cluster to essentially manage itself. In this framework, each ONS maintains a map of the current cluster topology. When a new ONS is added to the cluster, each existing ONS adds the new node and its connection information to its map. At the same time, the new ONS adds all of the existing nodes to its map. Alternatively, when an ONS is removed from the cluster, the maps for the remaining nodes are updated with this change.
As of Oracle Application Server Release 3 (10.1.3.0.0), the ONS configuration file (ons.conf) is no longer used. Instead, ONS configuration data is set in the <notification-server> element within opmn.xml, the OPMN configuration file located in the ORACLE_HOME/opmn/conf directory on each node. Clustering configuration in turn is set within a <topology> subelement. Only one <topology> subelement is allowed within a <notification-server> element.
The following example illustrates a cluster topology configuration in opmn.xml:
<notification-server>
<topology>
<discover list="*225.0.0.20:8001"/>
</topology>
...
</notification-server>
The clustering configuration specified in the <topology> element applies to all instances of Oracle Application Server components, including Oracle HTTP Server and OC4J, installed on the node. All nodes within a cluster topology must have the same configuration specified in the opmn.xml file.
The following clustering models are supported:
Dynamic node discovery
In this configuration, each ONS node within the same subnet announces its presence with a multicast message. The cluster topology map for each node is automatically updated as nodes are added or removed, enabling the cluster to be self-managing.
See "Configuring Dynamic Node Discovery Using Multicast" for configuration instructions.
Static hubs as discovery servers
Specific nodes within a cluster are configured to serve as discovery servers, which maintain the topology map for the cluster. The remaining nodes then connect with one another through a discovery server. A discovery server hub in one topology can be connected to hubs in other topologies.
Connection of isolated topologies via gateways
This configuration is used to connect topologies separated by firewalls or on different subnets using specified gateway nodes.
See "Configuring Cross-Topology Gateways" for details.
Manual node configuration
In this configuration, the host address and port for each node in the cluster are manually specified in the configuration. This is the same clustering mechanism supported in Oracle Application Server 10g Release 3 (10.1.2) and is supported primarily to provide backward compatibility.
See "Configuring Static Node-to-Node Communication" for instructions.
The following are changes in cluster configuration in Oracle Application Server 10g Release 3 (10.1.3) from previous releases.
As of Oracle Application Server 10g Release 3 (10.1.3.1.0), OC4J instances belong to groups within the cluster topology, enabling you to perform group deployment, configuration, and administration operations across an Oracle Application Server cluster.
In Oracle Application Server 10g Release 3 (10.1.3.1.0), groups are explicitly created by administrators using any desired name. Once a group has been created, it can be populated with any of the OC4J instances that are resident within the cluster topology.
|
Note: The procedures for creating and managing groups have changed since Oracle Application Server 10g Release 3 (10.1.3.0.0). If you have used the 10.1.3.0.0 release, be sure to review the new procedures for creating and managing groups in the 10.1.3.1.0 release, described in Creating and Managing OC4J Groups Within Oracle Application Server Clusters. |
The Distributed Configuration Management (DCM) framework, used in prior releases of Oracle Application Server to replicate common configuration information across a cluster, is not included in the current release. This means that:
Configuration using the dcmctl command line utility or Application Server Control Console is no longer supported.
Cluster configurations must now be manually replicated in the opmn.xml file installed on each node within the cluster.
The ONS configuration file (ons.conf) is no longer used. ONS connection data is now set in the <notification-server> element within opmn.xml, the OPMN configuration file located in the ORACLE_HOME/opmn/conf directory on each node containing an OC4J or Oracle HTTP Server instance.
Each node is no longer required to be manually configured to connect to every other node in the cluster.
All OC4J instances in an OPMN-managed environment must be part of a group, which is a set of OC4J instances that belong to the same cluster topology. Groups enable you to perform some common configuration, administration, and deployment tasks simultaneously on all OC4J instances in a group.
Through the Application Server Control Console, you can create additional groups and, from the Group page, perform the following tasks on a group of OC4J instances:
Process management operations, such as start, stop, and restart
Deployment operations, such as deploy, undeploy, and redeploy
JDBC management operations, such as creating, modifying, or removing JDBC data sources and connection pools
JMS Provider operations, such as creating and removing JMS destinations, and creating, modifying, or removing JMS connection factories
To display the Group page, simply click the name of the group in the Groups section of the Cluster Topology page.
Figure 8-1 Group Section on Cluster Topology Page
The default OC4J group (default_group) is created automatically when you install an application server instance. When you install Oracle Application Server 10g Release 3 (10.1.3.1.0), the installer creates a default OC4J instance that resides in the default group. Later, you can add OC4J instances and organize them into groups.
For example, you can create a new group for the deployment of a particular application to all OC4J instances of the group across the Oracle Application Server cluster. Then you can use the Group page in the Application Server Control Console to make application-specific configuration changes to all instances of the application in the OC4J group, across the cluster.
In the following topics, this section describes how to create and manage groups of OC4J instances for group operations on applications replicated across one or more Oracle Application Server clusters:
With groups, you can perform each of the following tasks once across multiple OC4J instances:
Modify the OC4J server properties for all OC4J instances in a group
Start or stop all the OC4J instances in a group
Deploy, undeploy, or redeploy applications on all OC4J instances in a group
Perform JDBC management operations, such as creating, modifying, or removing JDBC data sources or connection pools
Perform JMS Provider operations, such as creating or removing JMS destinations and creating, modifying, or removing JMS connection factories
You can administer a group through the Application Server Control Console, as follows:
In the Cluster Topology page, under Groups, choose the group.
Select the Administration tab.
The Administration page provides administration features for the group as a whole. These features do not include Security Provider administration.
To create a new OC4J group through the Application Server Control Console:
In the Cluster Topology page, under Groups, choose Create.
In the Create Group page:
Specify a name for the group.
A group name can contain only alphanumeric characters and underscores and cannot contain any special characters, such as parentheses, periods, dollar signs ($), asterisks (*), or commas. The name must start with a letter or an underscore.
Table 8-1 lists some examples of valid and invalid names for OC4J instances and groups.
Select the OC4J instances to move to the group.
When you move an OC4J instance into the new group, the instance is removed from its previous group. The instance must be stopped before it can be moved.
Choose Create.
|
Note: You can also move an OC4J instance into a group after the group is created, as follows:
|
After you create a group, it appears in the list of groups on the Cluster Topology page. You can later add OC4J instances to the group or remove instances from the group, as "Managing OC4J Instances in a Group" describes.
You can also create a group during the following operations:
Creating a new OC4J instance
When you create a new OC4J instance, you can create a new group or identify an existing group for the instance. If you do not specify a group, the new instance is assigned to default_group.
Removing an OC4J instance from a group
When you remove an OC4J instance from a group, you create a new group or identify an existing group for the instance.
|
Notes: The following restrictions apply to moving OC4J instances between groups:
|
Consider the following examples of using multiple OC4J instances and groups to manage your Oracle Application Server environment:
Create OC4J instances for specific purposes. For example, use the default OC4J instance as your administration OC4J and be sure you use it exclusively for deploying Application Server Control. Create another OC4J instance to deploy your production applications.
Create additional OC4J instances to improve performance and provide load balancing for your production applications.
Group OC4J instances on which you deploy the same application so you can make application-specific modifications to the group instead of to individual OC4J instances. You can also deploy an application to the group once instead of multiple times to the individual OC4J instances.
OC4J includes tools for creating additional OC4J instances in a group and removing instances from a group within an Oracle Application Server cluster. Once created, new OC4J instances can be accessed and managed through the Application Server Control Console.
This section includes the following topics:
You can add an OC4J instance to a group in the following ways:
Through an Application Server Page in the Application Server Control Console
With the createinstance utility, which is installed in the ORACLE_HOME/bin directory
To create an OC4J instance through the Application Server Control Console:
On the Cluster Topology page, click the name of an Oracle Application Server instance to navigate to an Application Server: instance_name page.
Click Create OC4J Instance.
On the Create OC4J Instance page, enter the following information:
OC4J Instance Name: Enter a name for the instance.
|
Note: You cannot enterhome as the instance name because home is reserved for the name of the default OC4J instance. |
Select one of the following items:
Add to an existing group with name: Select a group from Existing Group Name.
Add to a new group with name: In the New Group Name field, enter a name for the new group.
Select Start this OC4J instance after creation.
Click Create.
A confirmation screen is displayed after the instance has been created. The password for this OC4J instance is the same as the password used for the oc4jadmin user for the installation.
The createinstance utility enables you to create additional OC4J instances in an group with the following syntax:
createinstance -instanceName instanceName [-port httpPort] [-groupName group]
|
Note: You cannot specifyhome for instancename because home is reserved for the name of the default OC4J instance. |
You must supply an HTTP listener port as the value for httpPort when creating a new instance in a standalone OPMN-managed OC4J instance (J2EE Server and Process Management install type.) This HTTP listener port will be set in the default-web-site.xml Web site configuration file created for the instance.
Every new OC4J instance is assigned to a group. If the specified group does not exist, it is created. If the -groupName switch is not provided, the instance goes into the default_group group.
As part of the creation process, you will be asked to enter a password. This password will be tied to the oc4jadmin user for this instance. Oracle recommends that you enter the same password used by the oc4jadmin user to access the Application Server Control Console in the administration instance to prevent problems with OPMN.
As part of the creation operation, the new instance is added to the existing opmn.xml file. To ensure that OPMN is aware of the new instance, an OPMN reload is performed at the end of the create operation. For this reload, the createinstance utility must connect to the MBeanServer used to configure OPMN. The password of the new OC4J instance is used for authentication. If the password of the new instance is not the same as the instance running the MBeanServer, an error is returned. This does not prevent the instance from being created, but it does cause problems when OPMN or other components need to connect to the new instance. Therefore, Oracle recommends that you create all OC4J instances in the target Oracle Application Server cluster with the same password.
You also need to specify the same password for the oc4jadmin user in each OC4J instance of a group within an Oracle Application Server cluster so the user can perform group operations.
|
Usage Notes:
|
You can optionally supply an HTTP port for the value of -port. This feature can be used when the Oracle Application Server instance does not include Oracle HTTP Server. Setting an HTTP port makes it possible to access the OC4J instance's home page directly.
The new instance will be created within a new ORACLE_HOME/j2ee/instance directory, the same location as the default home OC4J instance. A new <process-type> element containing the instance configuration will also be added to the opmn.xml configuration file.
The following directories and files are generated in the new ORACLE_HOME/j2ee/instance directory structure:
applib/ applications/ config/ contains default versions of all server-level configuration files config/database-schemas/ contains all database schema XML files packaged with OC4J connectors/ contains RAR files packaged with OC4J log/ persistence/
The new instance does not include the OC4J binary libraries; instead, the instance will utilize the libraries installed in the home instance. The default application is deployed to the new instance; however, binaries and configuration files for other deployed applications, including Application Server Control Console, are not copied to the instance.
Once the new instance is started by OPMN, you can access it through the Cluster Topology page in Application Server Control Console.
Log in as the oc4jadmin user and supply the password set when the instance was created using the createinstance utility.
Once logged in, you can perform the full range of administrator tasks on the instance, including deploying applications to it.
You can remove an OC4J instance from a group by moving it to another group, as described in "Creating Groups of OC4J Instances", or by deleting it. You can delete an OC4J instance in the following ways:
In the Application Server Control Console, through the Application Server Page for Oracle Application Server on which the OC4J instance is installed
With the removeinstance utility, which is installed in the ORACLE_HOME/bin directory
Both methods delete the directory created for the instance from the j2ee directory structure and remove configuration data for the instance from opmn.xml. The following guidelines apply to deleting an OC4J instance.
You cannot delete the OC4J home instance that was created by Oracle Application Server during installation.
You can delete OC4J instances that were created by a user after installation.
The OC4J instance to be deleted must be in a stopped state (which Application Server Control does for you).
If OPMN is running when the removeinstance tool is in use, you must invoke opmnctl reload to reload the updated opmn.xml into the runtime.
To delete an OC4J instance through the Application Server Control Console:
On the Cluster Topology page, click the name of the Oracle Application Server instance where the OC4J instance is running to navigate to the Application Server: instance_name page.
Click the Delete icon for the instance you want to delete.
On the confirmation page, click Yes.
A confirmation screen is displayed after the instance has been deleted.
You can delete an OC4J instance by using the removeinstance utility, which deletes the directory created for the instance from the ORACLE_HOME/j2ee directory structure and removes configuration data for the instance from opmn.xml.
The removeinstance utility is installed in the ORACLE_HOME/bin directory. The syntax is as follows:
removeinstance -instanceName instanceName
To delete an instance with the utility, take the following steps:
Stop the instance:
ORACLE_HOME/opmn/bin/opmnctl stopproc process-type=oc4J_instanceName
Delete the instance:
ORACLE_HOME/bin/removeinstance -instanceName oc4J_instanceName
Because the Distributed Configuration Management (DCM) framework is not provided in Oracle Application Server Release 3 (10.1.3), configuration file synchronization within a cluster has changed in Oracle Application Server 10.1.3 Table 8-2 summarizes the files that might need to be replicated.
Using the OC4J grouping feature introduced in release 10.1.3.1.0 (described in "Creating Groups of OC4J Instances"), it is possible to deploy EARs, WARs, RARs, and shared libraries consistently across groups of OC4J instances using Application Server Control, the admin_client.jar command-line utility, and OC4J Ant tasks. This ensures consistent configuration at a module level within groups of OC4J instances. For information about deploying to groups of OC4J instances using these tools, see Chapter 6, "Using the admin_client.jar Utility" and the Oracle Containers for J2EE Deployment Guide.
For specific configuration files, the group feature also enables administrators to configure data sources, connection pools, and JMS resources across groups of OC4J instances from the Application Server Control Console, admin_client.jar command line, and OC4J Ant tasks. Specifically, the configuration files that support this are data-sources.xml and jms.xml.
The simplest way to achieve consistent configuration file across multiple OC4J instances is to use the multiple JVM feature of the Oracle Application Server. This feature enables the user to set the number of JVM instances, n, off which a single OC4J configuration will run simultaneously. The result is that from a single consistent configuration set, n instances of OC4J will be started. Changing any files in that single configuration set will update all the OC4J instances that started, corresponding to the number of JVMs set. Configuring the number of JVMS per OC4J instance is covered in "Running an OC4J Instance on Multiple JVMs".
Beyond these specific features, Table 8-2 summarizes the complete set of configuration files and their usage in case manual configuration across a cluster is determined to be necessary for an application configuration change.
Table 8-2 Configuration Files to Replicate Across a Cluster
| File | Location in ORACLE_HOME |
Data to Replicate or Manage |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This section contains instructions on configuring the following clustering models:
Dynamic node discovery is the most straightforward clustering configuration. In this model, each ONS node broadcasts a simple multicast message announcing its presence, enabling nodes within the cluster to dynamically discover one another.
The following tools can be used to add OC4J instances to a cluster using multicast discovery:
opmnctl
This utility includes commands for updating opmn.xml with the multicast port:address and Web site configuration data needed to add an instance to a cluster. See "Configuring Multicast Discovery with opmnctl" for details.
opmnassociate
This utility provides a one-step solution for adding an OC4J instance to a cluster. See "Configuring Multicast Discovery with opmnassociate" for details.
|
Note: An Oracle Application Server can be added to a cluster at installation time. |
Each ONS maintains its own map of the cluster topology. When a new ONS is added to the cluster, each existing ONS adds the new node and its connection information to its map. At the same time, the new ONS adds all of the existing nodes to its map. Alternatively, when an ONS is removed from the cluster, the maps for the remaining nodes are updated with this change.
Because multicast messages may be restricted by different network configurations dynamic node discovery may be an option only for ONS nodes that are on the same subnet. However, multiple subnets using dynamic node discovery may be connected using gateway servers. See "Configuring Cross-Topology Gateways" for details.
|
Notes:
|
The dynamic discovery configuration is set within a <discover> subelement of the <topology> element in the opmn.xml file on each Oracle Application Server instance in the topology. To add a new node to the cluster, simply add this element to its opmn.xml file. To remove a node from the cluster, remove this element.
Set the multicast IP address and port as the value for the list attribute. The asterisk (*) preceding the IP address is critical because it informs OPMN that the value specified is a multicast address. Multiple values can be specified, each separated from the next by a comma.
<opmn>
<notification-server>
<port ... />
<ssl ... />
<topology>
<discover list="*225.0.0.20:8001"/>
</topology>
</notification-server>
...
</opmn>
|
Note: Theopmn.xml file must be reloaded for changes made to take effect. Run the following command on the affected node to reload opmn.xml:
opmnctl reload This command will not affect OPMN-managed components, including Oracle HTTP Server, OC4J, and deployed applications. |
The OPMN command-line tool, opmnctl, supports a new config topology command that enables you to specify, update, or delete the multicast <discover> entry within opmn.xml.
The opmnctl tool is installed in the ORACLE_HOME/opmn/bin directory on each node. The tool must be run individually on each node and will update only the opmn.xml file on that node.
|
Note for Adding OPMN-Managed Standalone OC4J Instances: An OPMN-managed OC4J instance does not include Oracle HTTP Server (J2EE Server and Process Management install type). The When adding the instance to a cluster, you must configure the Web site to use the Apache JServ Protocol (AJP). This modification is necessary to enable the OC4J instance to receive and respond to requests from Oracle HTTP Server. The protocol and ports used by the default Web site can be configured using the Runtime Ports page in the Application Server Control Console. The |
Inserting or Updating Discovery Data
The update command inserts or updates the <discover> element with the specified values. The syntax is as follows:
opmnctl config topology update discover="*multicastAddress:multicastPort"
For example:
opmnctl config topology update discover="*225.0.0.20:8001" opmnctl reload
Deleting Discovery Data
The delete command removes the <discover> element from opmn.xml, effectively removing the node from the cluster. If the <topology> element contains no other subelements, it will be removed as well.
opmnctl config topology delete discover opmnctl reload
The opmnassociate utility adds the default home OC4J instance to a cluster using multicast discovery. This utility performs the following steps:
Inserts or updates the <discover> element in opmn.xml with the specified multicast address and port
Configures the default Web site to receive and respond to requests from Oracle HTTP Server using the Apache JServ Protocol (AJP) by modifying the corresponding <port> element in opmn.xml
Restarts OPMN to load the new configuration into the runtime
The opmnassociate tool is installed in the ORACLE_HOME/bin directory on each OC4J instance. The tool must be run individually on each instance and will update only the opmn.xml file on that instance.
On UNIX and Linux systems, the syntax is as follows:
opmnassociate.sh "*multicastAddress:multicastPort" [-restart]
For example:
opmnassociate.sh "*225.0.0.20:8001" -restart
On Windows systems, the syntax is as follows:
opmnassociate "*multicastAddress:multicastPort" [-restart]
For example:
opmnassociate "*225.0.0.20:8001" -restart
The asterisk (*) preceding the IP address is required.
|
Note: You can use theopmnassociate utility only to add the default home OC4J instance to a cluster. If you want to add another OC4J instance, such as home2, use the opmnctl utility, as described in "Configuring Multicast Discovery with opmnctl". In general, opmnassociate is a simplified form of the more complete opmnctl command set for configuring multicast discovery. Using opmnctl for configuring multicast discovery, as described in "Configuring Multicast Discovery with opmnctl", is the recommended approach. |
This configuration is similar to a peer-to-peer clustering model, with one or more ONS nodes within the same cluster configured to serve as static hubs, or discovery servers.
Each ONS node in the cluster establishes a connection with a discovery server, which maintains the topology map for the cluster. The discovery server provides the connecting node with the current topology map, enabling the connecting node to communicate with the other ONS nodes within the cluster.
You can use opmnctl to configure the connection to a static discovery server. See "Configuring a Static Discovery Server Connection with opmnctl" for details.
Set the TCP/IP connection information for the discovery server within the <discover> element in the opmn.xml file on each static hub node within the cluster. For example:
<opmn> <notification-server> <port ... /> <ssl ... /> <topology> <discover list="node1.company.com:6200"/> </topology> </notification-server> ... </opmn>
The required information is as follows:
The host name or IP address of the static discovery server
The OPMN remote port, which is defined in the <port> element within the opmn.xml file installed on the static server, as illustrated below.
<port local="6100" remote="6200" request="6003"/>
|
Note: Theopmn.xml file must be reloaded for changes to take effect in the OPMN runtime. Run the following command on the affected node to reload opmn.xml:
opmnctl reload This command will not affect OPMN-managed components, including Oracle HTTP Server, OC4J, and deployed applications. |
The OPMN command line tool, opmnctl, supports a new config topology command which allows you to specify, update or delete the <discover> entry within opmn.xml.
The opmnctl tool is installed in the ORACLE_HOME/opmn/bin directory on each node. The tool must be run individually on each node, and will only update the opmn.xml file on that node.
Inserting or Updating Discovery Data
The update command inserts or updates the <discover> element with the specified values. The syntax is as follows:
opmnctl config topology update discover="serverHost:opmnRemotePort"
For example:
opmnctl config topology update discover="node.company.com:6200" opmnctl reload
Deleting Discovery Data
The delete command removes the <discover> element from opmn.xml, effectively removing the node from the cluster. If the <topology> element contains no other subelements, it will be removed as well.
opmnctl config topology delete discover opmnctl reload
For situations in which cluster topologies are on different subnets or are isolated by firewalls or physical locations, specific ONS nodes can be configured as gateways, enabling ONS notifications to be sent across the disparate topologies.
Figure 8-4 Using Gateway Servers to Connect Topologies
In this model, an ONS node within each isolated topology is configured as a gateway server, which serves as an entry point into the cluster. The gateway configuration is specified within a <gateway> subelement of the <topology> element.
Set the host and port for the source gateway node and each target node it will connect to as the value for the list attribute. The order in which the nodes are listed does not matter.
For each node, specify the host name or IP address of the server and the OPMN remote port, which is defined in the <port> element within the opmn.xml file installed on the static server, as illustrated below.
<port local="6100" remote="6200" request="6003"/>
Separate the data for each node with an ampersand (&).
Include a / at the end of the list of nodes.
The following example shows the opmn.xml configuration for node1, which will connect with gateway nodes node2 and node3. This same configuration can be set on each of these gateway nodes. Note the / at the end of the list:
<opmn> <notification-server> <port ... /> <ssl ... /> <topology> <gateway list="node1.com:6201&node2.com:6202&node3.com:6203/"/> <discover list="*224.0.0.37:8205"/> </topology> </notification-server> ... </opmn>
In addition to the <gateway> element, the <topology> element includes the <discover> element, which contains the multicast address and port used for dynamic discovery within the node's own cluster.
Alternatively, the entire <topology> element in the preceding example can be copied to the opmn.xml file on every node within the cluster topology. Only node1 will utilize the <gateway> configuration; it will be ignored by the other nodes.
To simplify configuration, you can set the connection data for all gateway nodes - sources and targets - in the <gateway> subelement and then copy this element to the opmn.xml file on each gateway node. Again, the order of the nodes does not matter; each node will simply ignore its own entry in the list.
|
Note: Theopmn.xml file must be reloaded for changes to take effect in the OPMN runtime. Run the following command on the affected node to reload opmn.xml:
opmnctl reload This command will not affect OPMN-managed components, including Oracle HTTP Server, OC4J, and deployed applications. |
When you work on a single machine using localhost, add the IP address in the <ipaddr> subelement of the <notification-server> element and explicitly set up a discover list in the <discover> element to refer to the localhost OPMN remote port, as defined in the cluster <port> element. An example of this configuration follows:
<notification-server>
<ipaddr remote="127.0.0.1" request="127.0.0.1"/>
<port local="6101" remote="6201" request="6004"/>
<ssl enabled="true"
wallet-file="$ORACLE_HOME\opmn\conf\ssl.wlt\default"/> <topology>
<discover list="localhost:6201"/>
</topology>
</notification-server>
If you supply the localhost IP address, 127.0.0.1, the machine can work with or without a network.
The static configuration model is essentially the same mechanism used in Oracle Application Server 10.1.2 and 9.0.4. It continues to be supported primarily to provide backward compatibility with these earlier releases.
In this configuration, a node list containing the host address and ONS remote listener port for each node in the cluster is supplied. Prior to Oracle Application Server Release 3 (10.1.3.0.0), when ONS configuration data was integrated into opmn.xml, this configuration would have been set in the ons.conf configuration file.
Define the host address and the ONS remote listener port - specified within the <port> subelement of <notification-server> - for each node in the cluster within the <nodes> subelement. Separate each node from the next with a comma.
For example:
<opmn> <notification-server> <port local="6101" remote="6202" request="6004"/> <ssl ... /> <topology> <nodes list="node1-sun:6201,node2-sun:6202"/> </topology> </notification-server> ... </opmn>
Supply the same list for each node in the cluster; each ONS instance will identify itself in the list and ignore that entry.
|
Note: Theopmn.xml file must be reloaded for changes to take effect in the OPMN runtime. Run the following command on the affected node to reload opmn.xml:
opmnctl reload This command will not affect OPMN-managed components, including Oracle HTTP Server, OC4J, and deployed applications. |
You can view the current status of the Oracle Application Server components within a cluster, using either opmnctl or Application Server Control Console.
You can check the status of the cluster using opmnctl on any Oracle Application Server node within the cluster.
opmnctl @cluster status
The output shows the status of the components installed in each active Oracle Application Server instance within the cluster:
Processes in Instance: AppSrv1.comp1.yourcompany.com -------------------+--------------------+---------+--------- ias-component | process-type | pid | status -------------------+--------------------+---------+--------- OC4JGroup:COLORS | OC4J:home | 26880 | Alive OC4JGroup:COLORS | OC4J:oc4j_soa | 26256 | Alive HTTP_Server | HTTP_Server | 26879 | Alive Processes in Instance: AppSrv2.comp2.yourcompany.com-------------------+--------------------+---------+--------- ias-component | process-type | pid | status -------------------+--------------------+---------+--------- OC4JGroup:COLORS | OC4J:home | 26094 | Alive OC4JGroup:COLORS | OC4J:oc4j_soa | N/A | Down HTTP_Server | HTTP_Server | 26093 | Alive
Click the Cluster Topology link in the upper left corner of the Application Server Control Console home page.
The resulting page displays each Oracle Application Server instance that is active within the cluster, as well as the active applications on each instance. You can access an instance or a deployed application within the cluster through this page.
The term load balancing refers to the process of distributing incoming service requests over server instances within a cluster. Load balancing in an Oracle Application Server cluster is managed by the mod_oc4j module of Oracle HTTP Server. In this configuration, the Oracle HTTP Server instance acts as front-end listener for incoming HTTP and HTTPS requests; mod_oc4j then routes each request to an OC4J instance serving the requested application.
In Oracle Application Server Release 3 (10.1.3), load balancing is completely dynamic for Oracle Application Server instances that belong to the same cluster. No additional Oracle HTTP Server or mod_oc4j configuration is required:
Dynamic OC4J instance discovery
Oracle HTTP Server instances are dynamically updated with information on each OC4J instance in the cluster and the applications deployed to it, enabling Oracle HTTP Server to route requests to the appropriate instance.
See "Enabling Dynamic Configuration of Application Mount Points" for details.
Dynamic routing
The new release supports a routing ID mechanism that enables you, optionally, to control which OC4J instances to which an Oracle HTTP Server instance forwards requests, essentially enabling you to control the set of instances that will service requests from specific Oracle HTTP Server instances. All Oracle HTTP Server and OC4J instances are configured to use a default routing ID upon installation; as such, no configuration is required.
See "Using Web Server Routing IDs to Control OC4J Request Routing" for details.
The only requirement is that the ONS servers within the various Oracle HTTP Server and OC4J instances within the cluster be connected using one of the clustering configuration mechanisms outlined in this chapter. See "Configuring a Cluster" for details.
Every Oracle HTTP Server and OC4J instance in an OPMN-managed installation is assigned a routing ID that is defined in opmn.xml. An Oracle HTTP Server instance will route incoming Web requests only to OC4J instances that share its routing ID. This means that you can effectively define the set of OC4J instances to which a specific Oracle HTTP Server instance will route requests.
A default routing ID is assigned to all component instances, so that upon installation, every Oracle HTTP Server instance in a cluster can route requests to any OC4J instance within the cluster.
In a typical Oracle Application Server cluster, one or more Oracle HTTP Server instances receives requests from users and then routes those requests to the applications deployed within the cluster. The routing ID of each application server, each OC4J instance, each group, and each deployed application determines where the Oracle HTTP Server routes each request.
|
Caution: Changing the routing ID for an application server, component, or individual applications can prevent HTTP requests from being sent to your deployed applications. Unless other instances of the application are available in the cluster and have the same routing ID, this action can make the application unavailable to your users. |
The rest of this section describes how to change routing IDs, in the following topics:
For information on how Web sites are configured to listen for AJP requests, see Configuring Web Site Connection Data.
To change or view the routing ID assigned to each application and component of your cluster through the Application Server Control Console:
Navigate to the Cluster Topology page
Scroll to the Administration section of the page and click Routing ID Configuration.
The Routing ID Configuration page is designed to show the hierarchy of components and applications within your cluster topology. For example, if you click the Expand icon for an application server, then you see the groups within the application server instance. Within each group, you see the OC4J instances that are part of that group. And finally, if you expand a specific OC4J instance, you see the applications deployed to the OC4J instance.
By default, the application server instance is assigned a routing ID, and the groups, OC4J instances, and applications inherit the routing ID of the application server. If you enter a different routing ID for a specific group, OC4J instance, or application, then that new routing ID will override the routing ID inherited from the application server.
If you are managing multiple application server instances within a cluster, notice that the same group appears multiple times in the hierarchy, once for each application server that contains an OC4J instance that is a member of the group. This is because the hierarchy of the Routing ID Configuration page is based on the Oracle Process Management and Notification (OPMN) software configuration file (opmn.xml), which is stored in the Oracle home directory of each application server. As result, use caution when modifying the routing ID of a group. Be sure to assign the same routing ID to all instances of the group on the Routing ID Configuration page, unless you want specific Oracle HTTP Server requests to be routed to only some of the OC4J instances in the group.
The routing ID is defined in opmn.xml in a <data> element where the id attribute equals routing-id. The <data> element entry is a subelement of <category id="start-parameters">, which specifies parameters passed to the instance at startup. The default routing-id value set for each instance is g_rt_id.
<category id="start-parameters">
<data id="routing-id" value="g_rt_id"/>
</category>
The <data> element containing the default routing ID is set within the <ias-instance> element, which contains the OPMN configuration data for the Oracle Application Server instance. Because the routing ID is set at this level, the routing-id value set in this <data> element is applied to all instances of the Oracle HTTP Server and OC4J components installed within the OAS instance.
<opmn> <process-manager> ... <ias-instance id="instance1" name="instance1"> ... <environment> ... </environment> <module-data> <category id="start-parameters"> <data id="routing-id" value="g_rt_id"/> </category> </module-data> </environment> <ias-component id="HTTP_Server"> ... </ias-component> <ias-component id="default_group"> ... </ias-component> </ias-instance> </process-manager> </opmn>
However, the routing ID can be set at the individual Oracle HTTP Server or OC4J instance level by adding a <data> element within the <category id="start-parameters"> element for the component. This value overrides the routing ID assigned at the Oracle Application Server instance level.
You can specify any string as the value of the routing-id attribute. There is no required format for this identifier. The following entry in opmn.xml sets the routing ID for an Oracle HTTP Server instance:
<opmn>
<process-manager>
...
<ias-instance id="instance1" name="instance1">
...
<ias-component id="HTTP_Server">
<environment>
...
</environment>
<process-type id="HTTP_Server" module-id="OHS">
<module-data>
<category id="start-parameters">
<data id="start-mode" value="ssl-enabled"/>
<data id="routing-id" value="group_b_id"/>
</category>
</module-data>
<process-set id="HTTP_Server" numprocs="1"/>
</process-type>
</ias-component>
</ias-instance>
</process-manager>
</opmn>
The following entry in opmn.xml sets the routing ID for the OC4J home instance:
<opmn>
<process-manager>
...
<ias-instance id="instance1" name="instance1">
...
<ias-component id="default_group">
<environment>
</environment>
<process-type id="home" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="java-options" ... />
<data id="routing-id" value="group_b_id"/>
</category>
</module-data>
<process-set id="HTTP_Server" numprocs="1"/>
<port id="default-web-site" range="12501-12600" protocol="ajp" /> <port id="rmi" range="12401-12500"/>
<port id="jms" range="12601-12700"/
<port id="rmis" range="12701-12800"/
<process-set id="default_group" numprocs="1"/>
</process-type>
</ias-component>
</ias-instance>
</process-manager>
</opmn>
The mod_oc4j module within Oracle HTTP Server delegates requests to OC4J processes. Whenever Oracle HTTP Server receives a request for a URL that is intended for OC4J, Oracle HTTP Server routes the request to the mod_oc4j module, which then routes the request to an OC4J process. If an OC4J process fails, OPMN detects the failure and mod_oc4j does not send requests to the failed OC4J process until the OC4J process is restarted.
You can configure mod_oc4j to load balance requests to OC4J processes. Oracle HTTP Server, through mod_oc4j, supports different load balancing policies. Load balancing policies provide performance benefits along with failover and high availability, depending on the network topology and host machine capabilities.
You can specify different load balancing routing algorithms for mod_oc4j depending on the type and complexity of routing you need. Stateless requests are routed to any destination available based on the algorithm specified in mod_oc4j.conf. Stateful HTTP requests are forwarded to the OC4J process that served the previous request using session identifiers, unless mod_oc4j determines through communication with OPMN that the process is not available. In this case, mod_oc4j forwards the request to an available OC4J process following the specified load balancing protocol.
By default, all OC4J instances have the same weight (all instances have a weight of 1), and mod_oc4j uses the round robin method to select an OC4J instance to forward a request to. An OC4J instance's weight is taken as a ratio compared to the weights of the other available OC4J instances in the topology to define the number of requests the instance should service. If the request belongs to an established session, mod_oc4j forwards the request to the same OC4J instance and the same OC4J process that started the session.
The mod_oc4j load balancing options do not take into account the number of OC4J processes running on an OC4J instance when determining which OC4J instance to send a request to. OC4J instance selection is based on the configured weight for the instance, and its availability.
To modify the mod_oc4j load balancing policy, set the Oc4jSelectMethod and the Oc4jRoutingWeight directives in the ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf file:
In the mod_oc4j.conf file on each Oracle Application Server instance, within the <IfModule mod_oc4j.c> section, set the Oc4jSelectMethod directive to one of the values shown in Table 8-3.
If you set the Oc4jSelectMethod directive to either roundrobin:weighted or random:weighted, you may also need to set the Oc4jRoutingWeight directive to specify the weight (see the next step).
See "Choosing a mod_oc4j Load Balancing Algorithm" for tips on choosing a routing algorithm.
Table 8-3 Values for Oc4jSelectMethod
| Value | Description |
|---|---|
|
|
mod_oc4j places all the OC4J processes in the topology in a list, and it selects processes in order from the list. |
|
|
Similar to |
|
|
mod_oc4j distributes the total request load to each OC4J instance based on routing weight configured on each instance. It then selects OC4J processes from the local instance in a round robin manner. You configure the weight using the |
|
|
mod_oc4j randomly selects an OC4J process from a list of all OC4J processes in the topology. |
|
|
Similar to |
|
|
mod_oc4j selects an OC4J process based on the weight configured for each instance in the topology. You configure the weight using the |
|
|
mod_oc4j routes requests based on runtime metrics that indicate how busy a process is. |
|
|
Similar to metric, but mod_oc4j gives preference to local OC4J processes. If no local OC4J processes are available, then it routes to a remote OC4J process. |
Example:
Oc4jSelectMethod random:local
For information on how to set up metric-based load balancing, see Oracle HTTP Server Administrator's Guide.
If you set the Oc4jSelectMethod directive to a weight-based method (that is, roundrobin:weighted or random:weighted), you may also need to set the Oc4jRoutingWeight directive to specify the weight.
Oc4jRoutingWeight has the following syntax:
Oc4jRoutingWeight hostname weight
If you do not set the Oc4jRoutingWeight directive, it uses a default weight of 1.
Example: If you have a topology that consists of three instances (A, B, and C), and you want B and C to get twice as many requests as A, set the following directives for B and C:
Oc4jSelectMethod roundrobin:weighted Oc4jRoutingMethod hostB 2 Oc4jRoutingMethod hostC 2
Setting Oc4jRoutingMethod for hostA is optional because the default value is 1.
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.
To route incoming requests, Oracle HTTP Server utilizes a list of application-specific mount points, which map the URLs supplied in requests with the OC4J instances that will service the requests. This section includes the following topics on mount point creation:
See the Oracle HTTP Server Administrator's Guide for additional details on mount point configuration.
In previous releases of Oracle Application Server the list of application mount points had to be managed manually in the mod_oc4j configuration file, mod_oc4j.conf.
In the current release the list of mount points is dynamically updated as new nodes and applications are added to, or removed from, the cluster. Using ONS notifications, every OC4J instance within the cluster sends mount point data for each of its deployed applications to mod_oc4j, which adds this information to its internal routing table.
This dynamic discovery mechanism is enabled by default for clustered Oracle Application Server instances and requires no additional configuration.
The mount point information sent by each OC4J instance to Oracle HTTP Server includes these items:
The OC4J host address
OC4J port information, including the Apache JServ Protocol (AJP) listener port
This value is the lowest available port assigned to AJP in the opmn.xml file on the node.
The Web module name
This value is defined as the value of the name attribute in the <web-app> element defined for the module in the *-web-site.xml configuration file the module is bound to.
The Web context(s) defined for the application
This value is set in the root attribute of the <web-app> element defined for the module *-web-site.xml configuration file.
|
Note: Dynamically configured mount points are not written to the themod_oc4j configuration file, mod_oc4j.conf. |
When a new application is deployed to an OC4J instance, its mount point information is transmitted to Oracle HTTP Server, enabling mod_oc4j to dynamically discover the application and begin routing requests to it.
Conversely, when an application is stopped or removed from an OC4J instance, the mod_oc4j routing table is updated to reflect the application's absence, causing mod_oc4j to stop routing requests to the application instance.
You can still configure application mount points manually, as "Changing the Mount Point Configuration Algorithm" describes. For information about viewing the mount point list, see "Viewing Mount Point Configuration Data". For additional information about configuring mount points, see Oracle HTTP Server Administrator's Guide.
Although dynamic mount point creation is enabled by default, you do have the option of continuing to use manually configured mount points, which is the default mechanism supported in previous releases of Oracle Application Server.
Static mount points are defined in the mod_oc4j configuration file, mod_oc4j.conf, which is installed in the ORACLE_HOME/Apache/Apache/conf directory. By default, Oracle HTTP Server will create dynamic mount points as applications are deployed; however, static mount points defined in mod_oc4j.conf will also be honored.
The mount point configuration mechanism to use is specified in the Oc4jRoutingMode parameter in mod_oc4j.conf. Table 8-4 lists the values for this variable. See the Oracle HTTP Server Administrator's Guide for details on mount point configuration and using mod_oc4j.conf.
|
Note: If you changeOc4jRoutingMode to Static in the mod_oc4j configuration file, you also need to add the following configuration to mod_oc4j.conf to prevent losing access to the Application Server Control Console:
Oc4jMount /em/* home Oc4jMount /em home |
Table 8-4 Oc4jRoutingMode Values
| Value | Description |
|---|---|
|
|
Dynamically configured mount points are used exclusively. Static mount points will be ignored. |
|
|
Static, manually configured mount points defined in |
|
|
Both dynamic and static mount points are used. In the event of a conflict, the dynamically configured mount point will be used. |
|
|
Both dynamic and static mount points are used; however, in the event of a conflict, the static, manually configured mount point will be used. This is the default mode used, although it is not defined in |
The following mod_oc4j.conf example enables the DynamicOverride mode, in which the dynamic mount points specified will take precedence over static mount points in the event of a conflict:
#########################################################
# Oracle iAS mod_oc4j configuration file: mod_oc4j.conf #
#########################################################
LoadModule oc4j_module libexec/mod_oc4j.so
Oc4jRoutingMode DynamicOverride
<IfModule mod_oc4j.c>
<Location /oc4j-service>
SetHandler oc4j-service-handler
</Location>
Oc4jMount /j2ee/*
Oc4jMount /webapp home
Oc4jMount /webapp/* home
Oc4jMount /cabo home
Oc4jMount /cabo/* home
Oc4jMount /stressH home
Oc4jMount /stressH/* home
</IfModule>
You can configure Oracle HTTP Server to output mount point configuration data to a Web page generated on the Oracle HTTP Server host.
Add the following entry to the Oracle HTTP Server configuration file, httpd.conf, on the Oracle HTTP Server host machine. This file is installed in ORACLE_HOME/Apache/Apache/conf.
<IfModule mod_oc4j.c> Oc4jSet StatusUri /oc4j-status </IfModule>
You will now be able to view mount point data by appending the /oc4j-status context URI to the Oracle HTTP Server server URL:
http://ohsHost:ajpPort/oc4j-status
For example:
http://node1.company.com:7777/oc4j-status
The following is sample output displayed in the resulting Web page, with comments:
hostname : node1.company.com
local instance : node1.company.com
select method : Round-Robin
select affinity : None
# OHS routing configuration
routing mode : Static-Dynamic
routing ID : g_rt_id
OC4J Dynamic routing
# Applications using dynamic routing
# 'ascontrol' application
application : ascontrol
context : /em
process (Jgroup): 0
# 'demos' application
application : demos
context : /ojspdemos/jstl, /ojspdemos
process (Jgroup): 0 (demos)
OC4J Process List
process,ias instance,host,port,status
0 : home.node1.company.com, node1.company.com, 12502, ALIVE
1 : home.node1.company.com, node1.company.com, 12501, ALIVE
2 : home.node1.company.com, node1.company.com, 12503, ALIVE
OC4J executes on the Java Virtual Machine (JVM) of the standard Java Development Kit (JDK). By default, each OC4J instance uses one JVM; however, you can configure an OC4J instance so it runs on multiple JVMs, as Figure 8-6 shows. When you configure an OC4J instance to run on multiple JVMs, the instance essentially runs on multiple processes, which can improve performance and provide a level of fault tolerance for your deployed applications.
Figure 8-6 OC4J Instance Running on Multiple JVMs
This figure shows four processes that are configured to run from an OC4J instance named OC4J_home in one of the Oracle Application Server instances within a cluster.
|
Note: The OC4J instance namedhome typically cannot be configured to run with multiple processes because it hosts the Application Server Control application, which is not suitable for running in the multiple-process model. |
Multiple JVMs, however, require additional hardware resources to run efficiently. Also, if multiple processes run on the same host and the host goes down, all the JVM processes will go down.
If you install and manage multiple application server instances, you can install those application server instances on multiple hosts. By clustering the application servers and creating OC4J groups from the Cluster Topology page (or from the command line or API), you can also take advantage of application clustering and load balancing. Application clustering, described in Chapter 9, "Application Clustering in OC4J", ensures that state information is replicated to the different instances of your application running in each JVM.
In addition, Oracle Application Server clusters and OC4J groups provide added protection against hardware or network outages. If one host goes down, the applications deployed on the other hosts are still available.
|
Note: Application Server Control (represented by theascontrol application) cannot run on an OC4J instance that is running on multiple JVMS. Make sure that you do not configure multiple JVMs for the OC4J instance that is hosting the active Application Server Control Console. |
By default, each OC4J instance uses one JVM. However, you can configure the OC4J instance so it runs on multiple JVMs. To create additional JVMs for an OC4J instance: through Application Server Control Console:
Navigate to the OC4J Home page and then click Administration to display the OC4J Administration page, which contains a table listing the various administration tasks you can perform for the OC4J instance.
On the Administration page, select Server Properties to display the OC4J Server Properties page.
Enter the number JVMs to configure for the OC4J instance in the Number of VM Processes field.
Click Apply.
Restart the OC4J instance from the Cluster Topology page or the OC4J Home page.
When you use multiple JVMs, it is important to monitor the performance of the JVMs to be sure the current hardware resources can handle the configuration. From the Application Server Control Console, you can monitor and compare the performance of JVMs associated with the OC4J instance.
The following topics describe how to monitor JVM metrics through the Application Server Control Console:
Setting the jmxremote System Property for Monitoring J2SE JVM 5.0 Metrics
Monitoring J2SE 5.0 JVM Metrics in an Oracle Application Server Environment
Monitoring J2SE 5.0 JVM Metrics in a Standalone OC4J Environment
Before you can monitor the J2SE 5.0 JVM metrics from the Application Server Control Console, you must be running OC4J on JDK 5.0 (1.5) and set the jmxremote system property for each OC4J instance to enable this monitoring.
If you are running OC4J in an Oracle Application Server environment, then you can monitor a set of Dynamic Monitoring Service (DMS) metrics for each JVM. These metrics are unavailable in the standalone OC4J environment.
To view the DMS JVM Metrics in an Oracle Application Server environment through the Application Server Control Console:
Navigate to the OC4J Home page.
Locate the Virtual Machines field in the General section of the OC4J Home page.
Click the number that indicates how many JVMs are configured for the OC4J instance.
The JVM Metrics page displays a summary of key metrics for all the JVMs configured for the selected OC4J instance. You can use this table to compare the performance of multiple JVMs.
For more detailed information, click the name of a JVM.
The OC4J JVM page displays a set of charts and numeric metrics that give you a detailed picture of how the JVM is performing. Select a refresh interval from the View Data list. You can then view the changes in the performance charts over a period of time.
You can set the jmxremote System Property for monitoring J2SE JVM 5.0 metrics through the Application Server Control Console, through an OC4J startup option, or for an OPMN-managed environment, in the opmn.xml file.
Using Application Server Control to Set the jmxremote System Property
To enable the monitoring of JVM J2SE 5.0 metrics for each OC4J instance through the Application Server Control Console:
Navigate to the OC4J Home page and then click Administration to display the OC4J Administration page, which contains a table listing the various administration tasks you can perform for the OC4J instance.
On the OC4J Administration page, select Server Properties to display the OC4J Server Properties page.
Scroll down to the Command Line Options section of the page and select Enable J2SE 5.0 Platform MBeans.
Click Apply to apply the changes.
Navigate to the Cluster Topology page, select the OC4J instance, and then click Restart.
Setting the jmxremote System Property in an OC4J Startup Option
You can also enable monitoring of JVM J2SE 5.0 metrics by including the following string as an OC4J runtime startup option:
com.sun.management.jmxremote
For information about how to specify OC4J runtime startup options, see Setting OC4J Runtime Options at Startup.
If you are running OC4J in a standalone environment, include the following argument to the OC4J java command:
java -Dcom.sun.management.jmxremote -jar oc4j.jar
Manually Setting the jmxremote System Property in the opmn.xml File
If you are running OC4J in a Oracle Application Server managed environment, include -Dcom.sun.management.jmxremote in the in the opmn.xml file, as follows:
<ias-component id="default_group">
<process-type id="home" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="java-options" value="-Dcom.sun.management.jmxremote"/>
...
</category>
...
</module-data>
...
</process-type>
...
</ias-component>
Using the Application Server Control Console to enable the J2SE 5.0 Platform MBeans results in the jmxremote system property being set in the opmn.xml file. If you use this approach, then there is no need to set the property manually in the opmn.xml file.
To view the J2SE 5.0 JVM Metrics in an Oracle Application Server environment through the Application Server Control Console:
On the OC4J Home page, locate the Virtual Machines field in the General section.
Click the number that indicates how many JVMs are configured for the OC4J instance.
Enterprise Manager displays the JVM Metrics page.
Click the name of a JVM.
Enterprise Manager displays the OC4J JVM page.
Scroll to the Related Links section of the page and click J2SE 5.0 Metrics.
To view the J2SE 5.0 JVM Metrics in a standalone OC4J environment through the Application Server Control Console:
On the OC4J Home page, click Performance to display the OC4J Performance page.
Scroll to the Related Links section of the page and click J2SE 5.0 Metrics.
