In Camel 1.x there is AsyncProcessor interface (it extends Processor) that allows you to handle things asynchronously. While it is rather hard to use it, you have a chance to process your request asynchronously.
In fact Camel doesn't specify if error handling will happen in some thread or not - it depends on components you use, and processor type you use. Especially with AsyncProcessor you don't really know which thread will execute your AsyncCallback (interface used in AsyncProcessor). But as Clause mentioned Camel plans to change this interface to something JDK's Future-based solution in 2.x. Roman 2009/5/4 Zhi Zhou <[email protected]>: > Claus, > Thank you very much for the quick response! > > On Mon, May 4, 2009 at 5:07 PM, Claus Ibsen <[email protected]> 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 <[email protected]> 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: > > getProcessor().process(exchange); > > 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 > exception. > > > >> 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: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> Twitter: http://twitter.com/davsclaus >> Apache Camel Reference Card: >> http://refcardz.dzone.com/refcardz/enterprise-integration >> >
