[rabbitmq-discuss] Handling Channel.Flow method

[Chris Duncan]

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.

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.

Regards,

Chris

On 6 Jan 2010, at 00:58, Scott Brooks wrote:

> From http://www.tin.org/bin/man.cgi?section=2&topic=select
>
> If you specify select with a NULL timeout, then it will wait for  
> ever which you don't want.
> You should be able to specify a wait of 0, to have it return  
> immediately.
>
> Scott
>
> On 2010-01-05, at 2:32 PM, Chris Duncan wrote:
>
>> Hi Scott,
>>
>> 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?
>>
>> Regards,
>>
>> Chris
>>
>> On 5 Jan 2010, at 14:48, Scott Brooks wrote:
>>
>>> 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
>>> 60 Columbia Way, Suite 310
>>> Markham, ON L3R 0C9
>>> (905) 946-0300 x2356 - phone
>>> (888) 666-3120 - fax
>>> scott.brooks at epicadvertising.com
>>>
>>
>
> ---------------------
> Scott Brooks
> Web Developer
> Epic Advertising - New York, Toronto, San Francisco, London
> 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/20100106/384b6566/attachment.htm