"...yet they all fail (in the sense that they all receive the original START incoming payload. Can anyone explain how this is expected behavior?"
All or just A and C receive the same message. I'd expect A and C to receive the same message but not for B and D to (unless you don't change the message in A and C. The pipelines should all receive the same messages that is available between the multicast. Is that the behavior you are seeing? The results of the first pipeline are not propagated to the second pipeline. I'm not sure what the underlying mechanics are without cracking open the source code but it is as if the multicast is cloning the message it receives and sending the clone to each of the pipelines. "In any case I don't understand how the multicast could leak into a vararg pipeline(...). " How is it leaking? Each pipeline specified between the multicast tags is intended to receive exactly the same exchange as the others without mutation of the content based on the results of any of the others. Remember, the multicast is designed so that it can parallel process all the routes specified at the beginning of each pipeline. The only way it could do that is if it were sending the same message to all of them. Again, what exactly, are you trying to do with the processing. On Fri, Oct 28, 2016 at 4:40 PM, Edoardo Causarano < edoardo.causar...@gmail.com> wrote: > Hi Brad, > > yes that's the definition of multicast but the documentation also suggests > that pipelines are supposed to be implicitly derived from a vararg to(...) > statement. > > In any case I don't understand how the multicast could leak into a vararg > pipeline(...). It really feels like a bug to me, but I know little enough > of Camel to assume there's probably a good reason (in which case I'm happy > to understand it's logic) >
