Passive adapters in Oracle ESB that won’t be activated

Configuring SOA Suite 10g for high availability (HA) isn’t the most easy thing to do. Several administrators I spoke with and worked with in projects brought this up. I really hope that FMW 11g -besides all the new functionality, enhancements and support for new standards such as SCA- also makes things like HA easier to configure.

One particular issue we recently ran into in one of our projects has to do with the use of non-concurrent adapters in Oracle ESB when upgrading our clustered environment from 10.1.3.3 to 10.1.3.4. Non-concurrent (or singleton) adapters are adapters that cannot run in an active-active configuration since the underlying infrastructure does not provide a good locking mechanism. Examples are file and FTP adapters. JMS and database adapters on the other hand support concurrency. For non-concurrent adapters you have to ensure that there is only one adapter instance active at runtime. Otherwise you could have two active file adapters both reading the same file, starting two ESB flows instead of one. Futhermore, you want to have fail-over. If the ESB RT (runtime) node on which the active file adapter is running (or adapter itself) fails, the passive adapter on another ESB RT node should be activated. In earlier SOA Suite 10g releases you had to install and configure a separate ESB RT for this (ESB Singleton) and deploy non-concurrent adapters to this separate node. Real overkill. Fortunately, in later versions you could deploy non-concurrent adapters to the existing ESB RT’s and configure these adapters in an active-passive configuration by setting the clusterGroupId property. The jGroups protocol is then used so that only one instance of all adapters that have the same clusterGroupId value will be activated.

When we upgraded to SOA Suite 10.1.3.4 none of our file adapters in the acceptance environment was activated anymore! After some investigation it seemed that ESB 10.1.3.4 uses its own jGroups configuration instead of the jGroups configuration as specified in the global jgroups-protocol.xml file (as was the case for ESB 10.1.3.3). That isn’t a problem by default. However, in our case both our test and acceptance environment are clustered and both run in the same network. The internal jGroups configuration of both test and acceptance by default probably use the same ip and subnet addresses. Meaning all adapters of all ESB projects in the same network with the same clusterGroupId are all put in the same active-passive configuration. For ESB project “A” only one file adapter instance for test was active, the same file adapters for ESB project “A” for acceptance were all in passive mode. Luckily you can specify the useJgroupConfigFile property for an ESB endpoint and set it to true to enforce using the jgroups-protocol.xml configuration file; as was the case in ESB 10.1.3.3. Then configure a different ip and subnet address combination for test and acceptance. That way the non-concurrent adapters in the same ESB projects but in different environments are separated when they have the same clusterGroupId. Another workaround would be to include the environment name in the clusterGroupId value, e.g. MY_ESB_TEST_ID and MY_ESB_ACCEPTANCE_ID.