Ops, pls disregard the body "Regarding the exchange in callback.
Sure, you can do that if yourasync callback is an anonymous class."
On 10/5/07, William Tam <[EMAIL PROTECTED]> wrote:
> Regarding the exchange in callback. Sure, you can do that if your
> async callback is an anonymous class.
>
> On 10/5/07, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> > On 10/5/07, William Tam <[EMAIL PROTECTED]> wrote:
> > > On 10/4/07, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> > > > On 10/4/07, William Tam <[EMAIL PROTECTED]> wrote:
> > > > > 1. In SedaEndpoint.process(Exchange exchange, AsyncCallback callback)
> > > > > method. I wouldn't expect callback.done() to be invoked immediately
> > > > > when an exchange is enqueued. (right?) But rather I would expect
> > > > > callbacks are enqueued with the exchanges so that when the
> > > > > SedaConsumer can invoke them after their corresponding exchanges are
> > > > > processed.
> > > >
> > > > I don't agree. I think seda should behave like a jms queue.. The
> > > > producer is done when the message gets enqueued. If what you are
> > > > trying to do is to do async processing of a pipeline, you should use
> > > > the thread processor, like:
> > > > from(x).thread(5).to(y)
> > > >
> > >
> > > How about if I want to have a seda rather than just a thread pool? I
> > > want to have a bunch of stages. Each stage is a queue backed by a
> > > thread pool and some processing.
> >
> > Every thread pool is providing the split in your seda stage. So it
> > sounds like you want to declare each stage in a seperate route, then
> > you should use direct: endpoints to break them up.
> >
> > from("direct:stage1").thread(5).process(x).to("direct:stage2");
> > from("direct:stage2").thread(5).process(y).to("direct:stage3");
> > ...
> >
> > Remember that a thread pool also has a built in queue, which can be
> > configured to be blocking or non-blocking.
> >
>
> I forget about thread pool's build-in work queue. It makes sense to
> me now. Thanks for pointing that out.
>
> > >
> > > So, I might have something like:
> > >
> > > from("seda:stage1").thread(pool).process(...).to("seda:stage2"), and so
> > > forth
> > >
> > > If I make a async-send to seda:stage1, my callback is called when my
> > > exchange has been enqueued to stage1. IMO, this notification is not
> > > very useful. Actually, I think there is no point in making an async
> > > call at all. since I know my exchange has been enqueued when the send
> > > call returns (in either sync or async).
> >
> > Your right an async call to seda destination does not add much value.
> > But then again I don't recomend you use seda component for your use
> > case.
> >
> > >
> > > But if my callback is invoked after my exchange has been processed by
> > > the seda consumer of seda:stage1, I am notified when stage one is
> > > finished which gives me a reason to do async send. If I want to be
> > > notified this way, can it be done with pipeline or something else?
> >
> > I'm not sure I understand. Could you clarify??
>
> You already answered it (with your direct endpoint example).
>
> >
> > >
> > > BTW, I think if the callback passes me the processed exchange, there
> > > would be super nice. I probably care more about out message (if any)
> > > than whether it has been done synchronously or not.
> > >
> >
> > Since the caller of the asyc process call passes in the exchange, he
> > can pass that same exchange to the call back via either injection or
> > via final local reference. Something like:
> >
> > final Exchange exch = ...
> > processor.process(exch, new AsyncCallback() {
> > public void done(boolean sync) {
> > System.out.println( exch.getOut() );
> > }
> > });
> >
> Sure, it can be done. I am just saying if the exchange is passed to
> callback, the caller does not have do any extra work to get it. I
> guess is a matter of personal preference. I wouldn't worry about it.
>
