Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-user@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of chirino@gmail.com designates
 209.85.198.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=KRm8dBT5BqnXLJBzKG/5Uw8LlTBEVzqasbaoxGNnNDeRZYkPho4EJnRA+qAVsVf32lN2jC2l44KSVlAFDcVp++M74MOlsY0Cy4C0zPVg600DTqEQZteUrSmw3mETUEE7srH+mPTiuglejBeUcAIYOO901y1cZLeyhUSf51t+eNM=
Message-ID: <af2843cd0708100806m3a0a12d8rfc1edac40bbb774b@mail.gmail.com>
Date: Fri, 10 Aug 2007 11:06:50 -0400
From: "Hiram Chirino" <hiram@hiramchirino.com>
Sender: chirino@gmail.com
To: camel-user@activemq.apache.org
Subject: Re: Exception based routing
In-Reply-To: <ec6e67fd0708100741m4256d913v33f230aedcff817c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <12024679.post@talk.nabble.com> <12068759.post@talk.nabble.com>
	 <ec6e67fd0708090227m7999658q5ac8ff99b50951ab@mail.gmail.com>
	 <12071407.post@talk.nabble.com>
	 <ec6e67fd0708090528u6f21b3bbu9c8a8e8806ad192@mail.gmail.com>
	 <ec6e67fd0708090942t48a8af55i662ca977103b7c7f@mail.gmail.com>
	 <ec6e67fd0708091045i544324fan790f3816c0747b87@mail.gmail.com>
	 <12082262.post@talk.nabble.com>
	 <ec6e67fd0708100608k2c491714w3cabd94d7ecdf8e8@mail.gmail.com>
	 <ec6e67fd0708100741m4256d913v33f230aedcff817c@mail.gmail.com>

On 8/10/07, James Strachan <james.strachan@gmail.com> wrote:
> Here's a thought. The default error handler used in Camel is the
> DeadLetterChannel; in an attempt to do what most people want out of
> the box without having to explicitly customize things.
>
> So most errors tend to be transient system issues (e.g. database
> deadlocks, temporary unavailability of connections/dependent
> services), so retrying N times before sending to a dead letter channel
> is a reasonable default.
>
> When a user customizes certain exceptions in a route; its often gonna
> be a business exception or something similar. e.g. validation
> exceptions (whether XSD or business logic constraint violations etc).
> Usually for these cases, you don't want redelivery at all - since the
> exception isn't gonna change as its business logic.
>
> So I was thinking, the default case should be that specifying an
> exception handler route - without doing anything else - would
> effectively by default, turn off retry for that exception, unless the
> user explicitly customizes the retry count for that exception - or
> maybe the user customizes the default value for all exception()
> policies.
>
> e.g.
>
> exception(Validation.class).to("seda:badlyValidatedMessages");
> from("activemq:foo").to("jpa:MyEntityBean");
>
> if we get a database exception, we retry N times. However by default
> if we get a validation error we don't retry and just immediately send
> to "seda:badlyValidatedMessages".
>
> If you don't want this, you can still be explicit...
>
> // lets retry for this exception...
> exception(NullPointerException.class).maximumRetries(3);
>
> // otherwise lets not retry for validations...
> exception(Validation.class).to("seda:badlyValidatedMessages");
>
> from("activemq:foo").to("jpa:MyEntityBean");
>
> Does that seem reasonable & non-confusing? Am a tad conscious of
> adding too much magic under the covers - but in many ways conceptually
> I kinda think when someone uses the code
>
>   exception(that).to(somewhere);
>
> they are kinda saying 'on that exception, go to somewhere" - which
> kinda implies there'd be no retry logic applied by default - unless
> you explicitly say you want that.
>

This sounds good to me..
And a question I have.. will it be possible in 1 route builder to
define a global exception handler for one set of routes and then
change it to different one for a different set of routes.

For example, if we want to keep each customer's messages on different
jms queues:

 exception(Validation.class).to("activemq:cust-a-failures");
 from("activemq:cust-a-po").to("seda:po");
 from("activemq:cust-a-invoice").to("seda:invoice");

 exception(Validation.class).to("activemq:cust-b-failures");
 from("activemq:cust-b-po").to("seda:po");
 from("activemq:cust-b-invoice").to("seda:nvoice");


> --
> James
> -------
> http://macstrac.blogspot.com/
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com