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.

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

Reply via email to