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 <[email protected]> wrote: > On Mon, May 4, 2009 at 12:44 PM, Zhi Zhou <[email protected]> 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 <[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 > >> > > > > > > -- > 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 >
