[rabbitmq-discuss] Flow Control

[Edwin Fine]

>
> > == 8-Nov-2008::20:08:59 == ERROR -  emulator
> > Error in process <0.191.0> on node 'xhg_rel at ender' with exit value:
> > {badarg,[{erlang,list_to_binary,[{frame_rec,<<217
> > bytes>>,1226192940,0,active,ok,0,undefined,0,<<33
> >
> bytes>>}]},{rabbit_binary_generator,create_frame,3},{rabbit_binary_generator,build_content_frames,5},{rabbit_binary_generator,build_simple_content_frames...
>
>
> That is a fair point. May I suggest that we let the application choose
> what it wants to do - adding an equivalent call command would be
> trivial. What do you think?
>

I think that's a very fair compromise.


> > What I was trying to describe was having a gen_server or gen_fsm that has
> a
> > clause something like this;
> >
> > handle_info(#'channel.flow'{active = false}, State) ->
> >     {noreply, State#state{channel_flow = false}};
> >
> > handle_info(#'channel.flow'{active = true}, State) ->
> >     {noreply, State#state{channel_flow = true}};
>
> Sure, but this is all on the receiving process' side, so whether it
> handles it as a gen_server or as a plain jane receive block *should*
> be irrelevant. Furthermore, the receiving process may just ignore the
> notification or it may not register itself in the first place.
>
> So I think the more important side of things is how the channel
> process propagates the event that it receives from the broker.
>
> And this is what I have done - when the amqp_channel receives the
> #'channel.flow'{active = false} from the broker, it sends the
> registered listener a pause atom - in the reverse it sends it a resume
> atom.
>
> Hence what you are suggesting is equivalent to what I have already done :-)


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  pause and resume atoms. (a) Do you agree and
(b) How do you plan to handle that side of it?

Is this a re-transmission issue in your mail ;-)

No, it's a re-transmission issue in my brain :)

Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20081110/8437835d/attachment.htm