On 8/10/07, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> On 8/10/07, James Strachan <[EMAIL PROTECTED]> wrote:
> > On 8/10/07, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> > > 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..
> >
> > 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).
> >
>
> That's too bad.. Would you at least be able to do the above with
> multiple route builders on a single context?
Oh definitely - the previous restrictions I mention are purely down to
a single RouteBuilder instance. We could add some clear kinda method
to zap any interceptors/error handlers in between defining groups of
routes maybe?
--
James
-------
http://macstrac.blogspot.com/
