[3.3][CORE] Rollback exception strategy (MULE-5986)

[Pablo La Greca]

Hi,

As part of 3.3 M2 we are working on improving exception strategy.

The following wiki page explains the behavior of the new exception strategy <rollback-exception-strategy>.

http://www.mulesoft.org/documentation/display/MULECDEV/Rollback+Exception+Strategy

This exception strategy allows to avoid consuming inbound message so it can be processed again later. In case max redelivery has been reached then message should be consumed to avoid an infinite loop.

We need feedback from every user mostly around how this new behavior should work and know use cases that can be implemented using this feature. Any kind of feedback or comments will be appreciated.

Thanks, Pablo.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Ken Yagen]

Is <redelivery-exhausted/> tied to the maxRedelivery attribute in the inbound endpoint? Will that branch of the flow only be executed if MessageRedeliverException is thrown? That part is not clear in the spec. Can you explain it more?

The language in the spec is a little confusing because sometimes you refer to "do not consume message" and sometimes you refer to "rollback". Do these mean the same? What is the difference when you say one versus the other - it's making it hard to understand the true meaning of some of the use cases.

The use cases seem pretty complete but since their are so many of them it makes the feature seem more complex then it probably is. I'm afraid this could translate into overly complex documentation of the feature. Is there a simples way to explain the feature first and then provide the use cases? i.e. I can't rationalize whether the use cases are just demonstrating the feature can support the different use cases or there are subtle differences around the behavior of the feature in the different use cases. If it's the former, then it's fine. if it's the latter, then the differences need to be bolded.

Ken

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Pablo La Greca]

Wiki page has been updated. Please take a look at it again and let me know.

Pablo.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Ken Yagen]

Pablo,

Much better. Still one question - what if redelivery is set on JMS or idempotent with max redelivery is configured and no retry exhaused element configured? Does it just ignore the redelivery setting then?

Having this decoupled in three different places in the code (in JMS endpoint, in a specific message processor, and in the exception strategy) seems complex and confusing. Is there any way to simplify this? Think about someone trying to configure this from Studio. How would they do it?

Ken

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Pablo La Greca]

Ken,

From the exception strategy perspective, yes, a MessageRedeliveryException will be thrown but it will be treated as any other type and will always rollback.

From the flow perspective, no, the flow will fail fast by throwing a MessageRedeliveryException.

Existent <idempotent-redelivery-policy> allows to configure a dead letter queue endpoint in case that maxRedeliveryCount has been exceeded. I find that behavior inconsistent since that scenario is an exceptional case and should be treated by exception strategy. Having these kind of inconsistencies makes Mule really hard to understand.

What can be improved is the fact that there's different way to configure maxRedelivery attempts depending on the transport. I think each inbound endpoint should allow to define maxRedelivery attribute and use a default idempotent-redelivery-policy. JMS will still use it's own redelivery handler but users won't notice that since it will be done behind the scenes. This way users won't have to know about <idempotent-redelivery-policy>, they can just use maxRedelivery attribute.

Getting into details, we will have to:
- Add maxRedelivery attribute only for those inbound-endpoints that make sense
- Add in each transport support for maxRedelivery attribute. Each transport should define it's own idempotent-redelivery-policy for the sake of efficiency.
- Advance users should be able to redefine idempotent-redelivery-policy.

We can also consider that MessageRedeliveryException will only be thrown in the presence of maxRedelivery attribute configured in the inbound endpoint, so it makes sense to consume message without the need to configured <redelivery-exhausted> element. Configuration will look like:

<flow name="..">
<inbound-endpoint address=".." maxRedelivery="4"/>
<processor ref=".."/>
<rollback-exception-strategy/>
</flow>

Message will be processed at most 5 times and the next time it will throw a MessageRedeliveryException and message will be consumed. If the user wants to customize behavior when a MessageRedeliveryException has been thrown then it can put message processors inside <redelivery-exhausted> element.

If an user sets maxRedelivery in a inbound endpoint inside studio, studio should:
- suggest user to use a rollback-exception-strategy or
- put a rollback-exception-strategy in the flow (if no exception strategy) has been defined yet.

Pablo.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Pablo La Greca]

After several discussions we though that we could do it event easier to use.

If an user wants to handle redelivery in a flow, he will just have to configure a rollback-exception-strategy with maxRedeliveryAttempts attribute set.

Configuration example:

<flow name="flow">
<jms:inbound-endpoint queue="in"/>
<processor ref="someMessageProcessor"/>
<rollback-exception-strategy maxRedeliveryAttempts="3">
<on-redelivery-attempts-execeeded>
<jms:outbound-endpoint queue="dlq"/>
</on-redelivery-attempts-exceeded>
</rollback-exception-strategy>
</flow>

This would fit around %80 use cases.

From studio perspective, users will only have to drag and drop a rollback-exception-strategy in their flows. If they have a dead letter queue to send the message to then just adding <on-redelivery-attempts-execeeded> and putting there their dlq outbound endpoint will be enough.

Pablo.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Daniel Feist]

This looks great. I really like the fact no separate redelivery-policy needs to be configured on the inbound endpoint! Also the fact that everything I need to configure for rollback/redelivery is in one place in a dedicated exception strategy.

Looking forward to seeing these new exception strategy patterns in studio, and with great pattern-oriented docs.

Dan

Post by Pablo La Greca
After several discussions we though that we could do it event easier to use.
If an user wants to handle redelivery in a flow, he will just have to configure a rollback-exception-strategy with maxRedeliveryAttempts attribute set.
<flow name="flow">
<jms:inbound-endpoint queue="in"/>
<processor ref="someMessageProcessor"/>
<rollback-exception-strategy maxRedeliveryAttempts="3">
<on-redelivery-attempts-execeeded>
<jms:outbound-endpoint queue="dlq"/>
</on-redelivery-attempts-exceeded>
</rollback-exception-strategy>
</flow>
This would fit around %80 use cases.
From studio perspective, users will only have to drag and drop a rollback-exception-strategy in their flows. If they have a dead letter queue to send the message to then just adding <on-redelivery-attempts-execeeded> and putting there their dlq outbound endpoint will be enough.
Pablo.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email