[rabbitmq-discuss] Seeking 'right way' to do IPC

[Brian Jones]

On Mon, Nov 1, 2010 at 5:30 PM, Jon Brisbin <
jon.brisbin at npcinternational.com> wrote:

>
> IMHO it's easier to decide whether a message is your own message or not (by
> setting your own name in a header) in the consumer and toss it if it is.
> I've done this before and it's easier than creating complicated routing
> rules to prevent the producer from receiving its own message, given the
> simplicity of fanout exchanges. It's simple and it works (my favorite! :).
>

With all due respect, I'm not after easier from a dev perspective, I'm after
more efficient from an overall workflow and performance perspective.

I'm currently doing as you suggest, and I've done it on other projects as
well, and it works, but I wouldn't call it "right". Consider that in a
scenario where hundreds or thousands of messages per second are being
processed, every single consumer has to *consume* every single message
whether they sent it or not. This is inelegant, in addition to being
inefficient.

Also, what in the world could be easier than simply not getting the messages
you published? ;-)


> Basic.Reject might also be something to look at here:
>
>
> http://www.rabbitmq.com/blog/2010/08/03/well-ill-let-you-go-basicreject-in-rabbitmq/
>
>
>From the spec:

 The client MUST NOT use this method as a means of selecting messages to
> process.


There's also nothing in there saying that the message is not actually
delivered. It's not a 'standing' rejection of items matching some routing
key, it appears to be meant for clients who, for whatever reason, are unable
to process the message "at this time".


> FWIW- I've found it's almost always easier to deal with messages by
> deciding what to do with them after you've consumed them rather than by
> trying to prevent them from ever going to your consumers in the first place.
> I can also shove more messages down the pipe because it doesn't have to try
> and figure out whether or not to deliver a message.
>

I should think it *has* to be more costly in the scope of the wider
application environment to deliver a message and make the decision on the
client end than to have RabbitMQ do the check before delivering. That said,
I also agree that, given Rabbit's inability to do this at the moment, doing
it on the client *is* easier.

Thanks for the insights. At least I know I'm not the only one doing things
this way.

brian



>
> Jon Brisbin
> Portal Webmaster
> NPC International, Inc.
>
>
>
>


-- 
Brian K. Jones
My Blog          http://www.protocolostomy.com
Follow me      http://twitter.com/bkjones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20101102/20ce8936/attachment.htm>