Check out this wonderful blog post:
Example #1: My simple process failing
My simple BPEL process called AhmedConsume reads a message from a topic, and writes it to a database table. In the example below, the password of the database user has expired. Thus, the composite has faulted.
Example #2: Setting the WebLogic JMS destination delivery failure settings
If you enable delivery failure via the JMS destination itself (basically, setting the Redelivery Delay Override, Redelivery Limit, Expiration Policy, and Error Destination in the queue/topic itself on WebLogic Admin Console), you can see here that the on each failed invocation, the error is rolled back to the topic, which retries again.
Here, I have a Redelivery Limit or 3, resulting in a total of 4 invocations (1 initial and 3 retries).
Example #3: Using JCA retry properties
In the example below, I am only using the JCA retry properties. These are located in your composite.xml file and look like:
Example #4: Setting both WebLogic JMS destination delivery and JCA retries
When setting both WebLogic JMS destination delivery retries and JCA retries, both take effect. If both retries are set to 3, it should be clear by now why I get a total of 16 invocations.
What should you use?
If you want failed messages to persist in some error destination, then consider using WebLogic JMS delivery failure, but you must be aware of a few points:
Applicable Versions:
References:
http://blog.ipnweb.com/2012/03/enabling-weblogic-jms-queues-for.htmlIn it, I demonstrated how to set up JMS destination retries.
Example #1: My simple process failing
My simple BPEL process called AhmedConsume reads a message from a topic, and writes it to a database table. In the example below, the password of the database user has expired. Thus, the composite has faulted.
Example #2: Setting the WebLogic JMS destination delivery failure settings
If you enable delivery failure via the JMS destination itself (basically, setting the Redelivery Delay Override, Redelivery Limit, Expiration Policy, and Error Destination in the queue/topic itself on WebLogic Admin Console), you can see here that the on each failed invocation, the error is rolled back to the topic, which retries again.
Here, I have a Redelivery Limit or 3, resulting in a total of 4 invocations (1 initial and 3 retries).
Example #3: Using JCA retry properties
In the example below, I am only using the JCA retry properties. These are located in your composite.xml file and look like:
In this example, my JCA retry is set to 3, resulting in a total of 4 invocations as expected.<property name="jca.retry.count" type="xs:int" many="false" override="may">3</property>
<property name="jca.retry.interval" type="xs:int" many="false" override="may">1</property>
<property name="jca.retry.backoff" type="xs:int" many="false" override="may">2</property>
<property name="jca.retry.maxInterval" type="xs:string" many="false" override="may">120</property>
Example #4: Setting both WebLogic JMS destination delivery and JCA retries
When setting both WebLogic JMS destination delivery retries and JCA retries, both take effect. If both retries are set to 3, it should be clear by now why I get a total of 16 invocations.
What should you use?
If you want failed messages to persist in some error destination, then consider using WebLogic JMS delivery failure, but you must be aware of a few points:
- Performance of WebLogic JMS retries is slightly worse than JCA retries (because the error is rolled back up to the JMS destination), so you may opt in using a combination of JCA retries (say 3) and WebLogic JMS retries (say 1).
- WebLogic JMS does not persist messages to the error destination if it is due to a bindingFault. However, remoteFault is persisted.
Applicable Versions:
- Oracle WebLogic Server 11g (10.3.5)
- Oracle SOA Suite 11g (11.1.1.5)
References:
1 comment:
There are no longer any pictures in the blog post. can you please re-attach them. Thanks.
Post a Comment