camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Thorne <>
Subject Re: Exception based routing
Date Tue, 07 Aug 2007 06:47:21 GMT

Hi Neil
Hi James thanks for the quick reply.

>> a) a system exception gets thrown. A system exception indicates an
>> infrastructure problem that will be fixed ASAP as it is essential to the
>> correct functioning of the system as a whole. eg. jdbc connection failed,
>> remote system is down etc. If a system exception is thrown then that
>> operation should be continually retried until it is successful.
>> b) a business exception is thrown. A business exception indicates that
>> there
>> was a problem with the request itself. It should not be retried (at least
>> not until the problem has been resolved). The message should be moved
>> onto a
>> hospital queue where it can be inspected, changed and retried after
>> possible
>> manual intervention.

> BTW how can you tell the difference between a) and b)? Are there
> certain base exception types you can use?

Yes I can. Although our applications can throw quite a few different
exceptions, so far in terms of routing we only need these two base types. We
have translators that convert the original exception to one of these types. 

>> What is the simplest way to achieve this with camel? Currently I can only
>> see an errorHandler which assumes you want to dump messages that cannot
>> be
>> processed to an error endpoint.

>An ErrorHandler could do anything - e.g. based on the type of
>exception it could decide whether or not to retry (if at all) etc.

>The default implementation is DeadLetterChannelErrorHandler, which
>assumes n-retries with optional backoff delays - before sending to a
>'dead letter' endpoint, which is kinda like your hospital queue

Okay I can write my own implementation. We're using the Java DSL style of

I'd need to set two different retry strategies depending on the type of


Without explicit DSL support I'm wondering about the custom ErrorHandler
impl, and what the current DSL
would have to look like. I don't have to specify any endpoint for the
ErrorHandler right?

In that case I could just manually post messages to the "business exception"
endpoint if the exception type matches using a spring configured proxy, or
otherwise just go into an infinite loop. I'll read the source for
DefaultErrorHandler to get a better understanding of the ErrorHandlers in

>Firstly you can customize the errorHandler on a set of routes, or a
>specific route, or within the processing of a route. So if you had
>your own idea errorHandler implementation you could use it wherever
>you like

>Currently there's no 'exception-type-based error handler'
>implementation; but it should be easy to add such a thing. e.g. we
>could add a Set<Class> property to the DeadLetterChannel for
>exceptions which should not be retried maybe?

> If I could then I suppose I could move business exceptions immediately to
> the hospital queue (with a retry count of zero).
> I could also bind a different error handler with an infinite retry count
> (-1?).

>Yeah - I've been pondering similar things. I'm wondering if we should
>have some kinda version of the Content Based Router that uses a
>similar notation to try/catch/finally; where known business related
>exceptions are caught and the message forwarded to a 'business logic
>failed' type endpoint, otherwise system exceptions (which are way more
>random and harder to catch all) filter up to the default errorHandler
>- such as for retrying & dead letter channels etc.
>e.g. in XML I was pondering something like

  <!-- do some stuff here which may throw exceptions -->

  <catch error="">
    <!-- for business level exceptions, send to some reject queue -->
    <to uri="activemq:myRejections'/>

  <!-- any other system exceptions cause the error handler to retry n-times



yes this would also seem to do the trick. Would this style be supported in
the Java DSL?

I'm just going into the office. I'll be back in an hour or so. Hopefully the
DSL above clarifies what we need.



View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message