[rabbitmq-discuss] RabbitMQ hangs, does not accept connections

[maulik thaker]

Hello Dimitri Minaev,

         Thanks for the reply.

          Finally we got the issue, there was a connection leakage in other
module that caused problem in our module.

Thanks,
Maulik


On Fri, Jan 24, 2014 at 6:36 PM, Dimitri Minaev <minaev at gmail.com> wrote:

> Hello, Maulik,
>
> I believe, your problem is a different one, because the bug was gone since
> we had upgraded to 2.8.7. The final message from the support service was:
>
> > The Erlang/OTP team believe that the problem was due to a bug in their
> code. A small change introduced in RabbitMQ 2.8.7 had the coincidental
> fortunate effect of bypassing the bug, so the problem should not occur in
> 2.8.7 or later versions of RabbitMQ.
>
> Good luck!
>
>
>
> On 22 January 2014 17:29, maulik thaker <maulik.mihir at gmail.com> wrote:
>
>>
>> Hi Dmitri Minaev,
>>
>>         I am facing same problem with rabbitmq 3.2.2 ( I have gone
>> through this thread and already checked memory and number of
>> file-descriptors are not causing the problem). If you have solved that
>> problem then please share the solution.
>>
>> Thanks,
>> Maulik
>>
>>
>> On Monday, 26 March 2012 11:15:45 UTC+5:30, Dmitri Minaev wrote:
>>>
>>> On 9 March 2012 16:37, Simon MacMullen <si... at rabbitmq.com> wrote:
>>> > On 09/03/12 07:57, Dmitri Minaev wrote:
>>>
>>> >> If I understand correctly, the number of file descriptors used by
>>> >> RabbitMQ in normal situation is roughly equal to the number of
>>> >> `rabbitmqctl list_connections` + some constant (~30)? In case of that
>>> >> hanging server, the number of AMQP connections never was close to the
>>> >> FD limit (ulimit -n is 1024, fs.file-max = 1605698). The graph
>>> >> reflecting  the number of open AMQP connections is attached to this
>>> >> message.
>>> >
>>> >
>>> > It's not really a constant, but to a first approximation, yes.
>>> >
>>> > Ultimately, the error I saw being passed up from the OS was ENFILE -
>>> that's
>>> > pretty unambiguous :)
>>> >
>>> > It's possible that if you're churning connections then "closed"
>>> connections
>>> > in FIN_WAIT2 could account for the majority of the used FDs. In 2.8.0
>>> we'll
>>> > set SO_LINGER to 0 to prevent this.
>>>
>>> I am still not sure about the role of the file descriptors in this
>>> event. Last Friday, our Rabbit died again. Until the very last moment
>>> the number of open file descriptors as reported by the management
>>> plugin was 143 out of the total available number of 32765. It was
>>> RabbitMQ v.2.7.0. On that same day I have upgraded to 2.8.1. Will
>>> report on its behaviour later.
>>>
>>> --
>>> With best regards,
>>> Dmitri Minaev
>>> _______________________________________________
>>> rabbitmq-discuss mailing list
>>> rabbitmq... at lists.rabbitmq.com
>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>>
>>>
>
>
> --
> With best regards,
> Dimitri Minaev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140129/39fe3d66/attachment.html>