camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: a few comments on SedaComponent
Date Mon, 08 Oct 2007 23:56:32 GMT
On 10/8/07, Hiram Chirino <hiram@hiramchirino.com> wrote:
> On 10/8/07, William Tam <email.wtam@gmail.com> 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/

Mime
View raw message