[rabbitmq-discuss] Handling Channel.Flow method

[Scott Brooks]

Have you tried calling select on your socket to see if there is any data available to be read before a publish?

Then your publish method could throw a ChannelFlowException or something like that.

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.


On 2010-01-05, at 7:21 AM, Chris Duncan wrote:

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.

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.

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.

Regards,

Chris <ATT00001.c>

---------------------
Scott Brooks
Web Developer
Epic Advertising - New York, Toronto, San Francisco, London
www.EpicAdvertising.com<http://www.EpicAdvertising.com>
60 Columbia Way, Suite 310
Markham, ON L3R 0C9
(905) 946-0300 x2356 - phone
(888) 666-3120 - fax
scott.brooks at epicadvertising.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100105/2250434d/attachment.htm