camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "P.Budzik" <>
Subject Re: RecipientList works inproperly
Date Mon, 14 Jan 2008 10:02:30 GMT

P.Budzik wrote:
> My team mate Marek (Hi man!) found a bug/misfunction of RecipientList. We
> have just tested it. It seems it uses Pipeline to process the collection
> of endpoints. It works in totally different way than the documentation
> suggests. It simply sends RS from the first endpoint as a RQ for the next
> endpoint. We think that it should work in multicast mode and optionally in
> pipeline mode, but multicasting should be default mode (according to
> docs). We patched that class changing the processor from Pipeline to
> MulticastProcessor and it works for us, but probably it needs either
> fixing or improving to be able to choose the required mode. Did we miss
> something? What was actually the intent of RecipientList? What can we do
> about it to avoid patching that class on our side?


I would like to re-raise my problem.... I've been working on something
for couple of days and I'm still not confident enough. I still don't
know what's going on there :) Please enlighten my path ;-) The problem
to solve is:

Have N endpoints and want to dispatch the same message according to the
specific expression (driven by Drools). Let's say there is an expression
E(x)=y where x is a message and y is a set of endpoints eg. "direct:e1",
"direct:z3","xslt:foo.xslt" etc. Every sub-route finaly results in
sending message to the same aggregator.

Natural solution seems to be using RecipientList however surprisingly
(for me) it uses pipeline, so the N+1 message is not sent until N
sub-route is finished. Moreover the final response of N route is passed
as in to N+1.

The problem without touching Camel code could be solved using splitter
however isn't it too tricky to prepare a list of identical exchanges and
then splitting them in order to have parallel exchanges? Not to mention
it works only if Romek's splitter patch is applied (thankfully it is in
trunk already :)). There must be something wrong with that.

If I used RecipientList (slightly modified so that every endpoint is
processed with producer's processor instead of wrapping all with
pipeline) it would work correctly. Now I have some questions:

1) Is it conceptually diffrent case than recipient list pattern? Is it a
subset of RL ? Isn't it sort of "Dynamic Routing Slip"?

2) I re-ask my question if RL idea is ok. Have anybody used it in
similiar fashion I mean RL + subflows + aggregator. I don't get the idea
of that pipeline.
View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message