[rabbitmq-discuss] memory leak rabbitmq 3.1.5

[Santi Nuñez-Cacho]

ok, I got keepalived above the cluster. And is balancing 61613 and 5672
could be keepalived opening and not closing something properly?
I undertstand the connections are being close well, but ..


On Thu, Sep 26, 2013 at 4:18 PM, Santi Nuñez-Cacho <brian.santiago at gmail.com
> wrote:

> yes, I do
>
> =INFO REPORT==== 26-Sep-2013::16:12:46 ===
> accepting STOMP connection <0.19254.0> (XX:49217 -> YY:61613)
>
> =INFO REPORT==== 26-Sep-2013::16:12:46 ===
> closing STOMP connection <0.19254.0> (XX:49217 -> YY:61613)
>
>
> On Thu, Sep 26, 2013 at 4:07 PM, Simon MacMullen <simon at rabbitmq.com>wrote:
>
>> Hmm. Something must be establishing short-lived stomp connections though,
>> do you see lines like:
>>
>>   =INFO REPORT==== 26-Sep-2013::15:06:39 ===
>>   accepting STOMP connection <0.376.0> ([::1]:56780 -> [::1]:61613)
>>
>> in the log?
>>
>> Cheers, Simon
>>
>>
>> On 26/09/2013 2:07PM, Santi Nuñez-Cacho wrote:
>>
>>> It was the connetion to the mcollective rabbitmq middleware. ( we 've
>>> got all the machines connected to mcollective )
>>>
>>> I removed the mcollective conection. Disabling it. And restarting the
>>> rabbitmq-server.
>>>
>>> That's we got now
>>>
>>>
>>> [root at rabbit03.bcn rabbitmq]# lsof -i :61613
>>> COMMAND    PID     USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
>>> beam.smp 17472 rabbitmq   21u  IPv6 4652854      0t0  TCP *:61613
>>> (LISTEN)
>>> [root at rabbit03.bcn rabbitmq]#  rabbitmqctl eval
>>> 'length(supervisor:which_**children(rabbit_stomp_client_**sup_sup)).'
>>> 50
>>> ...done.
>>> [root at rabbit03.bcn rabbitmq]#
>>>
>>> And the process growing...
>>>
>>>
>>>
>>>
>>> On Thu, Sep 26, 2013 at 2:57 PM, Simon MacMullen <simon at rabbitmq.com
>>> <mailto:simon at rabbitmq.com>> wrote:
>>>
>>>     On 26/09/2013 1:51PM, Santi Nuñez-Cacho wrote:
>>>
>>>         I expect 0 stomp connetions. The unique one connection on 61613
>>>         should
>>>         be the cluster one.
>>>
>>>
>>>     Port 61613 is not used for clustering, it's just stomp.
>>>
>>>
>>>         [root at rabbit03.bcn ~]#  rabbitmqctl eval
>>>         'length(supervisor:which___**children(rabbit_stomp_client__**
>>> _sup_sup)).'
>>>
>>>         3802
>>>         ...done.
>>>         [root at rabbit03.bcn ~]# lsof -i :61613
>>>         COMMAND    PID     USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
>>>         ruby      5638     root    6u  IPv4   25097      0t0  TCP
>>>         rabbit03.bcn.softonic.lan:__**59851->rabbit:61613 (ESTABLISHED)
>>>
>>>         beam.smp 27183 rabbitmq   21u  IPv6 4521334      0t0  TCP
>>>         *:61613 (LISTEN)
>>>
>>>
>>>     Ah.
>>>
>>>     So you have one connection, from some ruby script. But 3802
>>>     connection processes. So something is somehow leaking. Thank you for
>>>     reporting this bug.
>>>
>>>     But to help get to the bottom of it - what is that ruby script doing?
>>>
>>>
>>>     Cheers, Simon
>>>
>>>     --
>>>     Simon MacMullen
>>>     RabbitMQ, Pivotal
>>>
>>>
>>>
>> --
>> Simon MacMullen
>> RabbitMQ, Pivotal
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130926/92347235/attachment.htm>