[rabbitmq-discuss] Handling Channel.Flow method

[Alexis Richardson]

On Wed, Jan 6, 2010 at 4:40 AM, Chris Duncan <celldee at gmail.com> wrote:
>
> 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.

Yes, that's how we designed it.  But, the goal of 0-10 was to provide
a way to use acks and nacks for exactly-once delivery.  Your email
only asks for an ack.  That's a bit easier and IMO better.

alexis



> 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
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>