I understand. However, it looks to me like retryPolicy won't work (unless the Enterprise codebase is significantly different to the community) as I've just found the following line in JMSConnector:
<![CDATA[ if (recoverJmsConnections && getRetryPolicyTemplate() instanceof NoRetryPolicyTemplate && connection != null) {
...go on and register exception listener...
}]]>
This suggests to me that only instances of NoRetryPolicyTemplate get Exception callbacks when the JMS broker fails during runtime. You can imagine my concern as I tried to implement my own retryPolicy...
Luckily it looks like I can extend NoRetryPolicyTemplate, however non-intuitive that might be. Is the above instance check doing something else I should be aware of?
Nick Heitz
Travis Carlson-2 wrote:
You are correct, I have just added the folllowing section to
http://mule.mulesource.org/display/MULE2INTRO/Migrating+Mule+2.0+to+2.1
explaining this.
Retry Policies (ex-Reconnection Strategies)
-------------------------------------------
Due to some fundamental issues with the previous implementation of
Reconnection Strategies, these have now been redesigned and renamed to
"Retry Policies". The API for implementing retry policies is available
in org.mule.api.retry and related classes in org.mule.retry
Mule Enterprise includes common retry policies which can be configured
in your XML (e.g., )
but Mule Community users will need to implement their own based on
org.mule.retry.policies.AbstractPolicyTemplate
Travis
