[rabbitmq-discuss] Pika and Channel.Flow

Mon May 24 20:45:23 BST 2010

If you do a  channel.access_request before every channel.basic_publish  (or
after ever N publishes), then
amqplib properly raises the AMQPContentTransmissionForbidden exception since
the active state will have been
updated.

I don't think it's very efficient to do, but it does show that the patch is
working.   Apparently the AMQP protocol does not
send an exception to an active client connection until it reconnects or
re-requests access.

I definately don't know the AMQP protocol in detail, so someone please
correct me if I'm wrong.

thanks,
Allan

On Mon, May 24, 2010 at 11:33 AM, allan bailey <zirpubolci at gmail.com> wrote:

> Matthias,
>
> On Sun, May 23, 2010 at 10:56 AM, Matthias Radestock <
> matthias at rabbitmq.com> wrote:
>
>> Allan,
>>
>>
>> allan bailey wrote:
>>
>>> I just tried this patch in py-amqplib 0.6.2 and it doesn't seem to work,
>>> or raise an exception.  It might be
>>> rabbitmq isn't sending the channel.flow.
>>>
>>
>> Check the rabbit.log for memory alarms; that will tell you whether
>> channel.flow is working.
>>
>>
> Yes, I see the alarms.  But a connected producer is allowed, w/ the patch
> to continue sending.
> New producers are disallowed from sending though.  So it's close.  I need
> for the connected producer
> to catch and exception so that it will stop sending.
>
> I'll work on this fork and publish it when I get it working with an
> example.
>
> -allan
>
>
>>  I tested with rabbitmq 1.7.2 on OSX 10.6.2.  I'll test on a real OS when
>>> I can.   I definately need the flow control
>>> to stop producers from overwhelming the server.
>>>
>>
>> If the patch doesn't work, perhaps you could develop one that does and
>> release it, or a forked repo, to the community?
>>
>>
>> Regards,
>>
>> Matthias.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100524/4c78d304/attachment.htm 