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.
