On 8/10/07, James Strachan <[EMAIL PROTECTED]> 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
