[
https://issues.apache.org/jira/browse/CAMEL-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-4078:
-------------------------------
Summary: Allow Splitter, Multicast and Recipient List to share unit of work
with their sub exchanges to act as one operation that either succeed or fails
(was: Allow EIPs which spawns sub routes to run in a sub unit of work, where
sub message failures propagate back to the parent, acting as a kind of combined
unit of work)
There is now a {{shareUnitOfWork}} option.
> Allow Splitter, Multicast and Recipient List to share unit of work with their
> sub exchanges to act as one operation that either succeed or fails
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-4078
> URL: https://issues.apache.org/jira/browse/CAMEL-4078
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Fix For: 2.8.0
>
>
> Okay the title may sound confusing. The reason for this is we have end users
> with common use cases which currently is a bit tricky to do.
> For example they want to split a big message, and process each sub message.
> And in case of a failure during the processing of sub messages, they want
> that error to propagate back to the big message. This is already possible
> today as you use the AggregationStrategy, and its the default behavior. So
> far so good.
> However the problem is that the sub messages may have been handled by an
> error handler, such as moving to a dead letter queue. What the end users want
> instead, is that none of the sub messages should go into the dead letter
> queue, but instead that big message. To be able to do that, we need to
> introduce a notion of sub unit of work. So we can mark a beginning and end of
> a sub unit of work. Where the child exchanges can report back their progress
> to the parent sub unit of work. And at the end of the sub unit of work, we
> can check the state, whether there was any failure or not. In case of a
> failure we can propagate that to the parent exchange, and have that act as a
> single atomic unit of work (where the children participated). Then the error
> handler can react upon the failure of the parent, and move that message into
> a dead letter channel.
> The splitter example would most likely be the prime example. But you could
> essentially also use a recipient list, or multicast, and want those child
> exchanges participate in that same sub unit of work.
> There may be other EIPs supporting sub exchanges. However for this first
> implementation we will do it on the splitter, recipient list and multicast,
> as they all share the same core logic.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
