Tuesday, February 17, 2009

enable Active-Passive configuration for BPEL Adapters in HA

Recently I was doing some analysis on the Active-passive configurations to be enabled while working on HA enabled clustered environment with multiple nodes. There are some adapters which needs to be configured in Active-Passive mode. File and FTP Adapters are a must two that must be setup in an active-passive configuration. This is due to file system restrictions that make it impossible to avoid race conditions when two nodes attempt to retrieve the same file. Same will be the case with AQ or JMS adapters that subscribe to the same messaging topic since each will consume the same message.

How to achieve that?

The Adapter Framework supports active fail-over of inbound Adapter Services. You can achieve this by adding a property to a particular JCA activation agent (in bpel.xml) as shown in the following example:


<BPELProcess id="HAAdapterTest" src="HAAdapterTest.bpel">


<partnerLinkBinding name="File_in">

<property name="wsdlLocation">File_in.wsdl</property>


<partnerLinkBinding name="DB_out">







<activationAgent className="oracle.tip.adapter.fw.agent.jca.JCAActivationAgent" partnerLink="File_in">

<property name="clusterGroupId">GeoClusterId</property>

<property name="portType">Read_ptt</property>

<property name="input" type="LogicalDirectory">/home/geo/hatest</property> </activationAgent>




If the BPEL PM servers (JVMs) in the cluster are located across TCP/IP subnet boundaries, then it is necessary to add the attribute clusterAcrossSubnet=true.

In a cluster group, the multiple activations of the same adapter Activation Agent will be detected implicitly and automatically by all the instances of the adapter framework active in that cluster. Only one node activation will be allowed to actually start the reading or publishing messages. The adapter framework instances chooses one among them, randomly as to who should assume the Primary Activation responsibility. The other activations (instances) in the cluster will initiate to a hot stand-by state, without actually invoking EndpointActivation on the JCA resource adapter.

If a primary activation at some point becomes unresponsive, is deactivated manually or if it crashes/exits, then any one of the remaining adapter framework members of the cluster group will immediately detect this, and reassign the primary activation responsibility to one of activation agents standing by.

This feature uses JGroups underneath for the implementation, hence the clusterGroupId property. These features require cluster and JGroups configuration in

$ORACLE_HOME/bpel/system/config/collaxa-config.xml and $ORACLE_HOME/system/config/jgroups-protocol.xml. All BPEL instances

participating in the cluster must share the same cluster name in collaxa-config.xml,and the same multicast address and port in jgroups-protocol.xml.

Try it out if you have HA clustered environment. J


Kent said...

Very helpful! Thanks!

Chris said...






koppara said...

This is very helpful.

version: oracle BPEL
We have a scenario, where we need to poll one instance per minute in clustered environment.

for that, I added the "ClusterGroupId" in bpel.xml file under the ativationAgent element.

We have two clustered environments, its working fine in one environment not in other.
Does anybody has any idea, why it is happening like this.

And if we need to compare the configuration files of those two environments, what all the files we need to check. For deployments we are using ant scripts.

"If the BPEL PM servers (JVMs) in the cluster are located across TCP/IP subnet boundaries, then it is necessary to add the attribute clusterAcrossSubnet=true. "

In which file we need to add this attribute.

Does it create's any dead lock issues?

Thanking you in advance.

George Thomas said...

the clusterGroupId sud be unique value. It sud nt be used accross different adapters.

clusterAcrossSubnet=true is to be configured in collaxa-config.xml
It wont cause any deadlock.