camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zhi Zhou <zz.syb...@gmail.com>
Subject Re: Error handling Questions
Date Tue, 05 May 2009 08:14:48 GMT
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.ibsen@gmail.com> wrote:

> On Mon, May 4, 2009 at 12:44 PM, Zhi Zhou <zz.sybase@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.ibsen@gmail.com>
> wrote:
> >
> >> On Mon, May 4, 2009 at 11:40 AM, Zhi Zhou <zz.sybase@gmail.com> wrote:
> >> > Claus,
> >> > Thank you very much for the quick response!
> >> >
> >> > On Mon, May 4, 2009 at 5:07 PM, Claus Ibsen <claus.ibsen@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.zhou@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
>

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