[rabbitmq-discuss] Flow Control

[Edwin Fine]

Ben,

Truly, I always felt uncomfortable with using a cast on publish because you
can't tell directly if there was a problem. I'd prefer a call.

Maybe this is a hare-brained idea, but can't the broker just send a
channel.flow to the producer; the Erlang client just forwards it on to the
producer in precisely the same way as it sends a basic.receive to a
consumer? The publishing application would just need to write a handle_info
for channel.flow just like a consumer does for basic.receive, or have I
missed the point?

I realize that this means that publishing applications can choose to ignore
channel.flow commands, but that would be shooting themselves in the foot. In
the 0.8 spec it says "The peer that requests a Channel.Flow method MAY
disconnect and/or ban a peer that does not respect the request.", so the
server could just drop the channel if the publisher ignores it.

Now I am not sure what is meant by a "peer", if that's the client itself or
the application that is using the client. Either way, I believe that the
Erlang client simply forwarding the channel.flow command to the application
and requiring it to respond with the ok (and stop sending) is within the
spirit of the spec, and should (?) be simple to do in the client.

Can you see any issues with doing it like this?

Regards,
Ed

On Sun, Nov 9, 2008 at 5:28 PM, Ben Hood <0x6e6562 at gmail.com> wrote:

> Edwin,
>
> On Sun, Nov 9, 2008 at 6:58 PM, Edwin Fine
> <rabbitmq-discuss_efine at usa.net> wrote:
> > This is greatly welcome news! I look forward to the implementation of
> this
> > in the Erlang client, so that I can pause my producers when I get the
> > channel.flow command from the broker and avoid any possibility of
> exhausting
> > Rabbit's memory. Any ETA?
>
> Not really. But I have knocked up a first version that works - 19560
> refers. The only I am not sure about yet is the fact that publish
> function uses gen_server:cast/2 under the covers, making it difficult
> to on this invocation. My first thought was to keep the cast/2
> invocation as it is and just send out {pause,resume} atoms to a
> registered flow control handler, but this means more code on the
> client side. I suppose you could add a convenience function to
> encapsulate the blocking receive when you're in the pause state, but
> there may be a simpler way to do this. Have a look at the code
> yourself and maybe you have an idea.
>
> HTH,
>
> Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20081109/062eb915/attachment.htm