[rabbitmq-discuss] How to implement the Aggregator pattern?

[Matthew Sackman]

Hi Shane,

Apologies for the near-month-long delay - this one seemed to slip
through somewhat.

On Fri, Jun 25, 2010 at 11:57:51AM -0700, Shane wrote:
> I think you interpreted my question correctly. A and B are actually
> calculations on specific messages. C requires the result of the calcs
> of A and B in order to do it's work (another calculation). If I do as
> you suggested, then that seems to imply that I need to manage the
> messages based on the content to correctly group them. Otherwise, the
> calc of C might include calc results of arbitrary messages not related
> to it.

No. A and B should be consuming from their own queues and then
republishing as necessary such that their published messages end up on
separate queues to which C is subscribed. C can detect which
subscription a message is coming from - indeed that's the purpose of the
consumer tag. Thus C will be able to detect when a message comes from A
or if it comes from B.

> I should also mention that C may or may not be necessary based on the
> message content. So the flow may look something like this:
> 
> data(x): A, B
> data(y): A, B, C
> 
> So in the case of data(x), C is not needed and in the case of data(y)
> C needs the results of A and B.

How is this determined? If all the messages from A and B flow through C,
can C work this out and just fail to do any further work, or does A and
B know this, in which case they could avoid publishing their transformed
messages?

Matthew