<br><br><div class="gmail_quote">On Mon, Nov 1, 2010 at 5:30 PM, Jon Brisbin <span dir="ltr"><<a href="mailto:jon.brisbin@npcinternational.com">jon.brisbin@npcinternational.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div><div class="im"><div><br></div></div>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! :). </div>
</div></div></blockquote><div><br></div><div>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. </div><div><br></div>
<div>
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. </div>
<div><br></div><div>Also, what in the world could be easier than simply not getting the messages you published? ;-) </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div><br></div><div>Basic.Reject might also be something to look at here: </div><div><br></div><div><a href="http://www.rabbitmq.com/blog/2010/08/03/well-ill-let-you-go-basicreject-in-rabbitmq/" target="_blank">http://www.rabbitmq.com/blog/2010/08/03/well-ill-let-you-go-basicreject-in-rabbitmq/</a></div>
<div><div class="im"><br></div></div></div></div></blockquote><div><br></div><div>From the spec: </div><div><br></div>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
The client MUST NOT use this method as a means of selecting messages to process.</blockquote><div><br></div><div>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". </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div><div><br></div><div>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.</div>
</div></div></div></blockquote><div><br></div><div>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. </div>
<div><br></div><div>Thanks for the insights. At least I know I'm not the only one doing things this way. </div><div><br></div><div>brian</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div><div><div><br>Jon Brisbin</div><div>Portal Webmaster</div><div>NPC International, Inc.</div><br></div><br>
</div>
<br></div></div></blockquote></div><br><br clear="all"><br>-- <br>Brian K. Jones<br>My Blog <a href="http://www.protocolostomy.com">http://www.protocolostomy.com</a><br>Follow me <a href="http://twitter.com/bkjones">http://twitter.com/bkjones</a><br>