camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Exception based routing
Date Fri, 10 Aug 2007 15:15:01 GMT
On 8/10/07, Hiram Chirino <hiram@hiramchirino.com> wrote:
> 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..

Cool!


> 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");

Yeah - currently each exception(Foo.class) will override the previous
one (currently only one exception policy/handler is allowed per
exception type).

The exception to this (pun intended :) is for interceptors - if using
intercept(), they are always added for each intercept() call; so we'd
need some kinda clearInterceptors() or something if you want to remove
previous interceptors; in that case it might be cleaner to have
separate builder for rules which don't have a previously registered
interceptor applied.

Or some nice DSL way to disable certain interceptors; or to include a
predicate in the interceptor which allows you to excluse the routes
you don't want to use it on :)

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

Mime
View raw message