Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Thu, 9 Jun 2011 09:17:58 +0000 (UTC)
From: "Claus Ibsen (JIRA)" <jira@apache.org>
To: dev@camel.apache.org
Message-ID: 
 <439960240.6208.1307611078983.JavaMail.tomcat@hel.zones.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
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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