Hi I would not go down the AsyncProcessor route :) Its @deprecated and will be replaced by a new API in 2.0.
The AsyncProcessor was an experiment that was added in Camels early days and the JDK API itself has much better solutions for handling async tasks. Hence why we are replacing it totally in 2.0. In the mean time you can use your own async task handling with the JDK until its standard in Camel 2.0. On Tue, May 5, 2009 at 10:14 AM, Zhi Zhou <zz.syb...@gmail.com> wrote: > I see both jms consumer and seda consumer uses getProcessor().process() > instead of the getAsyncProcessor().process(exchange, callback). I am > concerned whether it will block even though I have an async > producer(implemented the AsyncProcessor) down the route. If this were the > case, seda consumer would still wait for the current exchange being > completely done(i.e. at a later time the callback.done(false) is called) > before pushing down the next one. the whole route is in fact not async. > > the same thing discussed here as well: > http://camel.apache.org/asynchronous-processing.html > >> *For a route to be fully asynchronous and reap the benefits to lower >> Thread usage, it must start with the consumer implementation making use of >> the asynchronous processing API. If it called the synchronous process() >> method instead, the consumer's thread would be forced to be blocked and in >> use for the duration that it takes to process the exchange. >> * > > > > On Mon, May 4, 2009 at 7:29 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > >> On Mon, May 4, 2009 at 12:44 PM, Zhi Zhou <zz.syb...@gmail.com> wrote: >> > 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. >> Hi >> >> Many solutions >> >> a) >> Put a seda queue in between JMS and your custom component. Then its >> inOnly and the JMS listener do not expect a reply >> from("jms:queue:foo").to("seda:foo") >> >> from("seda:foo").to"(mycomponent:foo"); >> >> b) >> Or you can use some of the DSLs to set the Message Exchange Pattern, >> so its an Event Message EIP: >> http://camel.apache.org/event-message.html >> >> I do think the inOnly() is added to 1.6.0 also. But I cannot remember. >> >> c) >> The JMS consumer also have some option to not expect a reply AFAIR >> For instance: disableReplyTo=true >> >> >> >> >> >> > >> > >> > On Mon, May 4, 2009 at 6:32 PM, Claus Ibsen <claus.ib...@gmail.com> >> wrote: >> > >> >> On Mon, May 4, 2009 at 11:40 AM, Zhi Zhou <zz.syb...@gmail.com> wrote: >> >> > Claus, >> >> > Thank you very much for the quick response! >> >> > >> >> > On Mon, May 4, 2009 at 5:07 PM, Claus Ibsen <claus.ib...@gmail.com> >> >> 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 <zhi.z...@sybase.com> >> 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 >> >> >> > >> >> >> >> -- >> 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 Interview with me: http://architects.dzone.com/articles/interview-claus-ibsen-about?mz=7893-progress
