Great. it's closer to what I want now..Thanks Claus. However, my producer is a sync processor, which has finished processing that exchange, if I set the exception to the exchange, it seems no other way I can pass it to camel's control any more. I just cached the exchange in the timeout task when finishing producing.
in another reply, Roman mentioned about AsyncProcessor. I think I do understand AsyncProcessor. but if I implement the producer as AsyncProcessor, it defeats the purpose of the whole route being async, as the jms consumer will still wait for the callback to be called at the producer side before processing the next exchange. I don't think the jms consumer is doing async, as I only consider InOnly for getting messages from queue. On Mon, May 4, 2009 at 6:32 PM, Claus Ibsen <[email protected]> wrote: > On Mon, May 4, 2009 at 11:40 AM, Zhi Zhou <[email protected]> wrote: > > 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. > You can set an exception on the Exchange to indicate a timeout > > exchange.setException(new ExchangeTimedOutException()); > Or just set your own kind of time out exception. > > Then Camel standard error handling will notice the exception and take > it from there. > > > > > > > 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 > >> > > > > > > -- > 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 >
