camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Exception based routing
Date Mon, 13 Aug 2007 16:36:26 GMT
On 8/10/07, James Strachan <> 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.

FWIW this logic has made it into the forthcoming 1.1 release (CAMEL-97).

If you don't specify a redeliveryPolicy at all for a specific
exception(class) clause then no retries is assumed; otherwise your
custom redeliveryPolicy overloads the default redelivery policy.

So you can just overload, say, the maximumRedeliveries() or a specific
exception type - while inheriting all the other values etc. For
example see this test case...


View raw message