camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zhi Zhou <>
Subject Re: Error handling Questions
Date Mon, 04 May 2009 09:40:59 GMT
Thank you very much for the quick response!

On Mon, May 4, 2009 at 5:07 PM, Claus Ibsen <> wrote:

> Hi
> What version of Camel are you using? Camel 2.0 has many improvments in
> error handling and processing over 1.x.

Sorry that I forgot to mention I am using 1.x for now as 2.0 is still going
through milestone release stage.

> On Mon, May 4, 2009 at 10:54 AM, Zhi Zhou <> wrote:
> > Hello all,
> >
> > Camel's error handling is pretty powerful, but lately I am having two
> > questions about it.
> >
> > 1) I am working a custom camel component, and not quite sure how to
> handle
> > certain error condition. I may be having wrong idea from the very
> beginning
> > but let me give you a simple scenario to describe the issue.
> >
> > from("jms:someQueue").to("myCustom:endpoint");
> >
> > My custom endpoint does some async message sending. For performance
> reason,
> > it should keep sending messages from the jms queue without waiting for
> > responses. responses come back asynchronously from the remote host. The
> > question here is that if a response doesn't return without a timeout
> period,
> > I would like an exception to be thrown and hence to be captured by
> camel's
> > error handling where some redelivery logic is made possible.
> unfortunately,
> > with this async nature of producing, the timeout event will be triggered
> in
> > a different thread and hence no way to have camel to capture my created
> > exception up to my limited camel knowledge.
> We are planning to add a new Async API in Camel 2.0 so you leverage
> Camel to do async routing much more easily.

> Anyway if you leverage the async task execution in the JDK 1.5
> concurrent API then you can get a handle to your async task, known as
> a Future handle.
> With that you can test whether the task is complete, get the result,
> get the result within a timeout period etc.
Exactly I am using the concurrent API to implement a timeout task. but my
headache is how to have camel informed of the exception that's created in my
timeout task. it seems impossible to call any current 1.x API to align this
timeout exception with the camel's standard error handling yet.

well look forward to the new Async API of 2.0. before having it on board, I
probably still need to think of a solution.

> >
> >
> > 2) my second question: is it possible that the error handling will happen
> in
> > multiple threads in case of multi-threaded exchange processing. for
> example,
> > the following route:
> >
> > from("direct:start").thread(10).process(new Processor(){/*throw some
> > exception*/});
> >
> > will the error handling happen in the same thread of the caller that
> > produces message to "direct:start", or will happen concurrently in
> multiple
> > threads?
> The thread is basically a worker pool, and since you use direct
> component your route is synchronous all the way. Leveraging up till 10
> worker threads.
> If you want to divide into async you should use the seda component.
> But when you want to do request-reply over seda it gets complicated.

I am just wondering whether camel will spawn a thread for error handing or
it's just using the current thread context. my above example might not be
exactly what I wanted to show. Put it more straightforward, if I have an
event-driven consumer, it typically does:


to have the exchange consumed. in case of an exception ocurred down the
route, camel's error handling will be sharing the same thread as the above
call or executing in a separate thread? if it's the same thread, that means
my event-driven consumer will be delayed until the exchange gets clear on

> Hence we are planning a new Async API in Camel 2.0 that addresses this.
> There is a discussion on this in the camel-dev forum.
> >
> >
> > Zhi
> >
> --
> Claus Ibsen
> Apache Camel Committer
> Open Source Integration:
> Blog:
> Twitter:
> Apache Camel Reference Card:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message