[rabbitmq-discuss] badarg in dict, fetch problem on basic.consume_ok (or not)

Wed Jan 15 11:56:32 GMT 2014

Well. If cause of badarg error was found (but look at our source still
not given me a reason), how about management_plugin hang on - it also
can leak and be factor of big memory consumption.
HTTP hangs after authorization, rabbitmqadmin - on any method requires
HTTP access. Both methods serves only request to /api/users,
parameters and policies.

2014/1/15 Blake-R <blake-r at mail.ru>:
> No, all queues was created on same channel which closed with
> connection, with exclusive=true. And...
>
> $ rabbitmqctl list_queues -p poker name messages_ready
> messages_unacknowledged messages consumers
>
> shows that there are no queues with messages or without consumer.
>
> At this night whiout sleep I'm downgrade erlang (from
> erlang-solutions.com R16B to native Ubuntu R14B) and now management
> plugin hangs more quickly, but there are no errors in log at all, and
> about badarg too.  Memory grow, but for a while can't qualify reason -
> may be R14B have other allocations (because number of clients now also
> grow). At least it grow not so quickly as prior to.
>
> Oleg.
>
> 2014/1/15 Matthias Radestock <matthias at rabbitmq.com>:
>> On 15/01/14 10:53, Blake-R wrote:
>>>
>>> OK. But as I'm wrote with graphics server still serve other requests -
>>> just with memory grow. I'm looked at list connections/queues and
>>> others with rabbitmqctl - it all in good values, not overflow (I'm
>>> already has bug with non-closing channels and fix them).
>>
>>
>> The illegal command sequence will result in the Erlang process representing
>> the AMQP channel dying - which is what the error report you posted
>> indicates. That in turn will cause the associated connection to be closed,
>> which too is shown in the error report.
>>
>> Other than that rabbit will continue to function normally. The memory growth
>> you are seeing is presumably due to messages accumulating in queues since
>> their consuming channels have crashed due to the above problem.
>>
>> Matthias.