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.
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...
https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/RedeliveryPolicyPerExceptionTest.java
--
James
-------
http://macstrac.blogspot.com/
