This blog post evaluates the runtime evaluation of the Oracle JCA Adapter endpoint property jca.retry.count on an outbound connection under Oracle SOA Suite 12c compared to Oracle SOA Suite 11g. Obviously, the runtime engine counts differently under 12c compared to 11g. When migrating a project from 11g to 12c, I first noticed this behavior in a more complex scenario. I drilled this down to the important endpoint property for this blog post.

But let’s first have a look at the documentation of Oracle SOA Suite 12c:

“jca.retry.count – Indicates the maximum number of retries before throwing a retryable error condition back to the invoking service engine.”

The exact same description can be found in the documentation of Oracle SOA Suite 11g. From this description, I would expect the initial connection try plus addition n retries on connection failure as defined in the jca.retry.count property. To prove this, I created a simple application trying to write a file from an inbound parameter as Mikku did in his blog post to explain the JCA retry properties.

composite.xml of JCA-retry sample

Fig. 1: composite.xml of JCA-retry sample

First of all, I ran a test where everything should work fine. The flow trace showed the expected result.

Flow-Trace of successful JCA-Call in Oracle SOA Suite 11g

Fig. 2: Flow-Trace of successful JCA-Call in Oracle SOA Suite 11g

This looked exactly the same for the migrated project under 12c:

Flow-Trace of successful JCA-Call in Oracle SOA Suite 12c

Fig. 3: Flow-Trace of successful JCA-Call in Oracle SOA Suite 12c

Afterwards I revoked the write permissions of the Oracle File Adapters target directory in order to provoke a retry. My JCA retry was configured to a retry count of 3 and a retry interval of 2 seconds.

  <reference name="WriteFileWithJcaRetry"
             ui:wsdlLocation="WSDLs/WriteFileWithJcaRetry.wsdl">
    <interface.wsdl interface="..."/>
    <binding.jca config="Adapters/WriteFileWithJcaRetry_file.jca">
        <property name="jca.retry.count" type="xs:string" many="false">3</property>
        <property name="jca.retry.interval" type="xs:string" many="false">2</property>
    </binding.jca>
  </reference>

Running a test under 11g resulted in an initial, failing connection try followed by 3 retries.

Flow-Trace of failed JCA-Call in Oracle SOA Suite 11g

Fig. 4: Flow-Trace of failed JCA-Call in Oracle SOA Suite 11g

However, in 12c, the initial, failing connection try was followed by only 2 retries although the retry configuration was exactly the same.

Flow-Trace of failed JCA-Call in Oracle SOA Suite 12c

Fig. 5: Flow-Trace of failed JCA-Call in Oracle SOA Suite 12c

Conclusion: Contra dictionary to the documentation, from 12c onwards, retry count is the total of the initial try and the subsequent retries for JCA connections.

This difference between 11g and 12c counts for the JCA endpoint binding property jca.retry.count to be configured in composite.xml. Using the Oracle Fault Handling Framework to perform retry operations defined in fault-policy.xml, the retry behavior is what we would expect it to be.

<Action id="default-retry">
  <retry>
    <retryCount>3</retryCount>
    <retryInterval>2</retryInterval>
   </retry>
 </Action>

If a retryCount of 3 is defined, one will get an initial try plus three retries … never mind if Oracle SOA Suite 11g or Oracle SOA Suite 12c is used.

Flow-Trace of failed JCA-Call with Fault Policy Retry Action in Oracle SOA Suite 12c

Fig. 6: Flow-Trace of failed JCA-Call with Fault Policy Retry Action in Oracle SOA Suite 12c