<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
&gt; == 8-Nov-2008::20:08:59 == ERROR - &nbsp;emulator<br>
&gt; Error in process &lt;0.191.0&gt; on node &#39;xhg_rel@ender&#39; with exit value:<br>
&gt; {badarg,[{erlang,list_to_binary,[{frame_rec,&lt;&lt;217<br>
&gt; bytes&gt;&gt;,1226192940,0,active,ok,0,undefined,0,&lt;&lt;33<br>
&gt; bytes&gt;&gt;}]},{rabbit_binary_generator,create_frame,3},{rabbit_binary_generator,build_content_frames,5},{rabbit_binary_generator,build_simple_content_frames...<br>
<br>
<br>
</div>That is a fair point. May I suggest that we let the application choose<br>
what it wants to do - adding an equivalent call command would be<br>
trivial. What do you think?<br>
<div class="Ih2E3d"></div></blockquote><div><br>I think that&#39;s a very fair compromise.<br>&nbsp;<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">&gt; What I was trying to describe was having a gen_server or gen_fsm that has a<br>
&gt; clause something like this;<br>
&gt;<br>
&gt; handle_info(#&#39;channel.flow&#39;{active = false}, State) -&gt;<br>
&gt; &nbsp; &nbsp; {noreply, State#state{channel_flow = false}};<br>
&gt;<br>
&gt; handle_info(#&#39;channel.flow&#39;{active = true}, State) -&gt;<br>
&gt; &nbsp; &nbsp; {noreply, State#state{channel_flow = true}};<br>
<br>
</div>Sure, but this is all on the receiving process&#39; side, so whether it<br>
handles it as a gen_server or as a plain jane receive block *should*<br>
be irrelevant. Furthermore, the receiving process may just ignore the<br>
notification or it may not register itself in the first place.<br>
<br>
So I think the more important side of things is how the channel<br>
process propagates the event that it receives from the broker.<br>
<br>
And this is what I have done - when the amqp_channel receives the<br>
#&#39;channel.flow&#39;{active = false} from the broker, it sends the<br>
registered listener a pause atom - in the reverse it sends it a resume<br>
atom.<br>
<br>
Hence what you are suggesting is equivalent to what I have already done :-)</blockquote><div><br>So does that mean that when a consumer wants to perform a channel.flow, there will be a call made available on the channel, say amqp_channel:flow(true|false)? Otherwise, if the consumer sends a channel.flow command directly, it is inconsistent on an API level with the producer, which only receives&nbsp; pause and resume atoms. (a) Do you agree and (b) How do you plan to handle that side of it?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Is this a re-transmission issue in your mail ;-)</blockquote><div>No, it&#39;s a re-transmission issue in my brain :) <br>
<br>Ed<br></div></div><br>