<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Thanks Scott. I'll try that. I was looking to do a similar thing with the Ruby socket implementation but got hung up on the timeout issue. Do you know if there are any issues with Windows and select used in this way? I don't use Windows myself, but I don't want to introduce a problem for those who do.<div><br></div><div>I've also been reading the AMQP 0-10 specification. I have only skimmed it before because I wasn't targeting a broker that implemented it. It contains a section about transfer of responsibility that seems to deal with the issues that I've been trying to address in my last two posts.</div><div><br></div><div>Regards,</div><div><br></div><div>Chris</div><div><br><div><div>On 6 Jan 2010, at 00:58, Scott Brooks wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>From <a href="http://www.tin.org/bin/man.cgi?section=2&topic=select">http://www.tin.org/bin/man.cgi?section=2&topic=select</a></div><div><br></div>If you specify select with a NULL timeout, then it will wait for ever which you don't want.<div>You should be able to specify a wait of 0, to have it return immediately.</div><div><br></div><div>Scott</div><div><br><div><div>On 2010-01-05, at 2:32 PM, Chris Duncan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> Hi Scott,<div><br></div><div>If I read the details of the select call correctly, wouldn't I have to provide a timeout value so that if there is nothing to read from the socket I stop blocking and can publish the next message?</div><div><br></div><div>Regards,</div><div><br></div><div>Chris</div><div><br><div><div>On 5 Jan 2010, at 14:48, Scott Brooks wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Have you tried calling select on your socket to see if there is any data available to be read before a publish?</div><div><br></div><div>Then your publish method could throw a ChannelFlowException or something like that.</div><div><br></div><div>If you are waiting on tx-ok, then you will have to wait the latency of your link to your rabbit server before sending your next message. Even a 1 ms delay on your link limits you to 1000 messages/second.</div><div><br></div><br><div><div>On 2010-01-05, at 7:21 AM, Chris Duncan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I've been wanting to incorporate Channel.Flow method handling into the Bunny Ruby client library for a while. It's needed, but I want to do it in a simple, efficient way. I want to be able to give a client application the option to stop sending messages as soon as possible after receiving a Channel.Flow method (with :active => false) and that means that I need to know whether a Basic.Publish succeeds as well as whether it fails.<br> <br> At the moment there is the potential for a client application to keep firing messages at the server whilst being oblivious to the fact that the server is telling it to stop. If the client application is just writing and not reading, purely a publisher of messages, then there has to be an efficient way of notifying the client that a publish has succeeded. As far as I can see, the simplest way to do that is with a publish-ok.<br> <br> Transactions may give me what I want but I don't think that I should be enforcing the use of transactions in my client library just so that it will handle Channel.Flow methods properly.<br> <br> Regards,<br><font color="#888888"> <br> Chris</font> <span><ATT00001.c></span></blockquote></div><br><div> <span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div>---------------------<br>Scott Brooks<br>Web Developer<br>Epic Advertising - New York, Toronto, San Francisco, London<br><a href="http://www.EpicAdvertising.com/">www.EpicAdvertising.com</a><br>60 Columbia Way, Suite 310<br>Markham, ON L3R 0C9<br>(905) 946-0300 x2356 - phone<br>(888) 666-3120 - fax<br><a href="mailto:scott.brooks@epicadvertising.com">scott.brooks@epicadvertising.com</a><br></div></span> </div> <br></blockquote></div><br></div></div></blockquote></div><br><div> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div>---------------------<br>Scott Brooks<br>Web Developer<br>Epic Advertising - New York, Toronto, San Francisco, London<br><a href="http://www.EpicAdvertising.com">www.EpicAdvertising.com</a><br>60 Columbia Way, Suite 310<br>Markham, ON L3R 0C9<br>(905) 946-0300 x2356 - phone<br>(888) 666-3120 - fax<br><a href="mailto:scott.brooks@epicadvertising.com">scott.brooks@epicadvertising.com</a><br></div></span> </div> <br></div></blockquote></div><br></div></body></html>