Ben,<br><br>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.<br><br>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?<br>
<br>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.<br>
<br>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.<br>
<br>Can you see any issues with doing it like this?<br><br>Regards,<br>Ed<br><br><div class="gmail_quote">On Sun, Nov 9, 2008 at 5:28 PM, Ben Hood <span dir="ltr"><<a href="mailto:0x6e6562@gmail.com">0x6e6562@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Edwin,<br>
<div class="Ih2E3d"><br>
On Sun, Nov 9, 2008 at 6:58 PM, Edwin Fine<br>
<<a href="mailto:rabbitmq-discuss_efine@usa.net">rabbitmq-discuss_efine@usa.net</a>> wrote:<br>
> This is greatly welcome news! I look forward to the implementation of this<br>
> in the Erlang client, so that I can pause my producers when I get the<br>
> channel.flow command from the broker and avoid any possibility of exhausting<br>
> Rabbit's memory. Any ETA?<br>
<br>
</div>Not really. But I have knocked up a first version that works - 19560<br>
refers. The only I am not sure about yet is the fact that publish<br>
function uses gen_server:cast/2 under the covers, making it difficult<br>
to on this invocation. My first thought was to keep the cast/2<br>
invocation as it is and just send out {pause,resume} atoms to a<br>
registered flow control handler, but this means more code on the<br>
client side. I suppose you could add a convenience function to<br>
encapsulate the blocking receive when you're in the pause state, but<br>
there may be a simpler way to do this. Have a look at the code<br>
yourself and maybe you have an idea.<br>
<br>
HTH,<br>
<font color="#888888"><br>
Ben<br>
<br>
</font></blockquote></div><br>