camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: a few comments on SedaComponent
Date Mon, 08 Oct 2007 21:48:45 GMT
On 10/8/07, William Tam <> 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: ?

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

> >  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.




View raw message