On 10/8/07, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> On 10/8/07, William Tam <[EMAIL PROTECTED]> wrote:
> > >
> > > Ok i agree. But the problem is we are looking at the seda example
> > > which does NOT populate the out message.
> >
> > Ok, I know seda component only supports in-only MEP and the producer
> > process is considered done once the exchange is enqueued.
> >
>
> Ok good.
>
> > I am kind of looking at the bigger picture. Suppose
> > from("seda:queue").to("a") is my route and endpoint "a" supports
> > in-out MEP. I'm afraid it is hard for me to get the populated
> > exchange back from of "a". I realize that you are advising me not to
> > use seda componet and I have no problem with that. So, is SEDA
> > strictly an in-only MEP architecture or is it a Camel impl specific?
>
> Since you acknowledge that seda supports in only exchanges, why do you
> find it odd that its "hard for me to get the populated exchange back
> from of "a".
>
> I think that perhaps our seda component is miss named. I think that
> your are thinking of the SEDA pattern and that this component should
> fully support it. Unfortunately it does not. Would everything be
> more clear if the seda: component was renamed to memory-queue: ?
+1. Anything but SEDA. vm:// sounds good too imho, or queue://.
SEDA is confusing.
>
> But the SEDA processing pattern IS supported by the
> ThreadProcessor/thread() dsl method. I think it makes more sense for
> it to be implemented in a processor than a component since seda is
> about setting up processing pipelines that have stages. The thread
> processor demarcates those stages in the pipeline.
>
>
> >
> > > For example if this was an async http component instead, then no, the
> > > callback.done() method would not be called until the http component
> > > populated the out message.
> >
> > IMO, it would be nicer if the sender don't have to think about the
> > type of endpoint including whether it supports in-out or not. So, I
> > can make my send call in the same way (i.e. without worrying about
> > holding on to my exchange's reference for in-out MEP) IMO, we
> > should pass the processed exchange to CB and let the CB worry about
> > MEP is used in the exchange.
> >
> > In your example, the sender assumes the async http component does not
> > make copies of the exchange and populate the originals. That's really
> > impl details of the async http component.
>
> This just complicates the async contract. The contract today is that
> when the CB.done() is called the original exchange has been processed.
> Regardless of implementation details of the sender, when CD.done() is
> called, any results need to be in the original exchange and it should
> not be modified further by the processor after CD.done() is called.
> The async send CB does not have to worry about there being given a
> copy of an exchange or if it's the same exchange and what do if they
> data the hold are different. It's not very difficult to implement
> this in the sender, and makes life simpler for folks using the async
> interface.
>
> >
> > > The point of the seda doing a copy is
> > > that once the message it enqueued, the consumer from that queue should
> > > not be working on exchange that could be changing behind it's back.
> > > But I still fail to see how this is related to passing the exchange as
> > > a parameter to the done method call.
> > >
> > If seda endpoint only supports in-only MEP and stays that way, then it
> > is really a moot point to talk about passing exchange back to the CB
> > at least in the context of seda component.
>
> agreed.
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
