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] [Created] (CAMEL-4078) 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
Date Thu, 09 Jun 2011 09:17:58 GMT
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
-------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 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