camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-4078) 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
Date Thu, 09 Jun 2011 11:18:59 GMT

     [ 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

Mime
View raw message