| Oracle® Application Server Enterprise Deployment Guide 10g Release 3 (10.1.3.5.0) Part Number E15355-01 |
|
|
View PDF |
| Oracle® Application Server Enterprise Deployment Guide 10g Release 3 (10.1.3.5.0) Part Number E15355-01 |
|
|
View PDF |
Best Practices for Cluster-based BPEL Deployments
Resolving Out-of-Memory Errors in the BPEL Runtime Console
Configuring Oracle Enterprise Service Bus for Singleton Adapters
Common administration operations are listed in Table 5-1. You can monitor and manage the system using consoles or command line tools.
Table 5-1 System administration tasks, tools, and related documentation
For recommendations and instructions on enabling disaster recovery, see the Oracle Application Server High Availability Guide
When deploying applications in a BPEL cluster, ensure that you:
Start the computers one at a time, and wait until one computer is completely started before starting the next one.
Copy the client interfaces for EJB bindings to each computer's system/classes directory and then restart theOracle BPEL Process Manager to load the classes.
Ensure that for applications you build and deploy, define wsdlLocation in the bpel.xml file to point to the wsdl file on the local file system, and define wsdlRuntimeLocation to point to the wsdl file at run time. An example is provided in ORACLE_ HOME/bpel/samples/demos/LoanFlow/LoanDemo/bpel/bpel.xml.
Confirm that the BPEL process works after deployment using the sample application, LoanFlow, located in the ORACLE_ HOME/bpel/samples/demos/LoanDemo directory.
Refer to Chapter 1, Oracle BPEL Process Manager Security in the Oracle BPEL Process Manager Administrator's Guide for Release 10g (10.1.3.1) for information about securing BPEL and invoking secure BPEL processes.
When you work with tasks in the BPEL Console, this error may occur:
500 Internal Server Error
java.lang.OutOfMemoryError: PermGen space
To resolve the error, you increase the memory allocated to the PermGen space (used for loading static classes) with the MaxPermSize parameter. Follow these instructions to set the MaxPermSize parameter in the Oracle Application Server instances on APPHOST1 and APPHOST2:
Open the ORACLE_HOME/opmn/conf/opmn.xml file and locate the MaxPermSize parameter, if present (shown in bold in Example 5-1). You might need to add the parameter to opmn.xml. The parameter must be added for the OC4J_SOA container startup.
Example 5-1 MaxPermSize Parameter in opmn.xml
...
<category id="start-parameters">
<data id="java-options" value="-Xrs -server
-XX:MaxPermSize=128M -ms512M -mx1024M -XX:AppendRatio=3
-Djava.security.policy=$ORACLE_HOME/j2ee/Admin/config/java2.policy
-Djava.awt.headless=true -Dhttp.webdir.enable=false"/>
</category>
<category id="stop-parameters">
<data id="java-options"
value="-Djava.security.policy=$ORACLE_HOME/j2ee/Admin/config/java2.policy
-Djava.awt.headless=true -Dhttp.webdir.enable=false"/>
...
Increase the value, or add the MaxPermSize parameter for all OC4J containers., for example:
-XX:MaxPermSize=256M
Save and close the file, and restart the OC4J instance using these commands:
opmnctl reload
opmnctl stopproc process-type=OC4J_SOA
opmnctl startproc process-type=OC4J_SOA
If Oracle Enterprise Service Bus is deployed across a cluster, and an ESB flow is triggered by a singleton adapter (such as a file adapter), one, and only one instance of the clustered ESB should pick up the file and start one process. The ESB inbound endpoint property clusterGroupId enforces singleton behavior by adapters in a clustered environment. This feature is designed for endpoints, such as a file system, that do not natively support a solid locking mechanism, as does a SQL database.
This singleton control of adapters requires that the ESB and BPEL instances belong to the same Jgroup configuration, obtained from the mcast-addr and mcast-port values in the ORACLE_HOME/bpel/system/config/jgroup-protocol.xml file, as described in Section 3.12, "Configuring the Cluster of BPEL Instances on APPHOST1 and APPHOST2."
To configure this behavior, you assign a combination of J2EE Connector Architecture (JCA) endpoint activations to a specific cluster group (typically, activations toward the same non-transactional endpoint, such as the same directory). Only one activation can be active at any given time. For example:
Cluster 1, instance 1:
<service name="InboundServiceX" ...>
...
<endpointProperties>
<property name="clusterGroupId" value="cluster1"/>
</endpointProperties>
</service>
Cluster1, instance 2:
<service name="InboundServiceX" ...>
...
<endpointProperties>
<property name="clusterGroupId" value="cluster1"/>
</endpointProperties>
</service>
Cluster1, instance 3:
<service name="InboundServiceX" ...>
...
<endpointProperties>
<property name="clusterGroupId" value="cluster1"/>
</endpointProperties>
</service>
[...]
In this configuration, all JCA adapter endpoint activations belonging to the same cluster group (in this case, cluster 1) will at any given time have only one activation active (the primary activation), and will be actively polling the endpoint (the file system). The others will be "hot standby", or secondary activations. For example, if instance 2 is the primary activation and it stops, instance 1 and instance 3 will immediately detect this, and then instance 1 or instance 3 will resume the activation responsibility (that is, become the primary activation). If instance 2 is restored to operation, it may re-assume the primary activation responsibility if instance 1 or instance 3 stops, and so on.
For more information, see "How to Add Endpoint Properties" in the Oracle SOA Suite Developer's Guide.
|
 Copyright © 2004, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|