[rabbitmq-discuss] Handling Channel.Flow method

Alexis Richardson alexis.richardson at gmail.com
Tue Jan 5 13:36:02 GMT 2010


Chris

I agree that use of TX, especially around a single message, is a bit
hefty for many cases, especially in the presence of persistence.  A
form of asynchronous ack is possible with TX too, but of course that
is not really what you are asking about.

The interesting phenomenon here, IMO, is the relationship between flow
control and (n)acks.  It would be good to make this clearer either
within or as an extension of 0-8/0-91.  I'll leave it to others to
comment on your proposed approach.

alexis




On Tue, Jan 5, 2010 at 12:21 PM, Chris Duncan <celldee at gmail.com> 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
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>




More information about the rabbitmq-discuss mailing list