[rabbitmq-discuss] channel.flow calls causing code 541 INTERNAL_ERROR

Matthew Sackman matthew at rabbitmq.com
Fri Jul 29 14:51:06 BST 2011


On Fri, Jul 29, 2011 at 02:21:46PM +0100, Cameron Harris wrote:
> I have a process that consumes from a queue with BasicConsume, but if
> there is a problem on the consumer that slows down message processing,
> RabbitMQ will carry on delivering messages until the process runs out
> of memory and crashes. In order to fix this...

...you should just use basic.qos with a non-zero prefetch count.

> I created a second thread
> that watches for too many messages building up in the client and calls
> ChannelFlow(false) on the channel. After the consumer catches up
> again, it ChannelFlow(true) to re-enable the channel flow.
> Unfortunately, since switching the broker to Windows Server 2008 and
> upgrading both the server and client to 2.5.1, the broker is
> occasionally terminating my connection on the ChannelFlow call. The
> exception text from the .NET client is:
>        The AMQP operation was interrupted: AMQP close-reason,
> initiated by Peer, code=541, text="INTERNAL_ERROR", classId=0,
> methodId=0, cause=
> When I was running on RHEL 6 I didn’t experience any problems, but I
> hadn’t tested it thoroughly, so it might just be less likely to occur
> on that setup. The clients are all running on Windows and using the
> .NET client.
>                          none}
> ** Reason for termination ==
> ** {{badmatch,{error,already_present}},
>     [{rabbit_channel_sup,'-start_limiter_fun/1-fun-0-',2},
>      {rabbit_channel,start_limiter,1},

That is odd, and does point to a bug in our code, I think... yes, we're
doing the wrong thing with our limiter.

Anyway, if you do just set a qos prefetch before consuming from the
queue, you'll find that'll solve the problem. I'll file a bug for the
other thing.


More information about the rabbitmq-discuss mailing list