[rabbitmq-discuss] memory leak rabbitmq 3.1.5

Thu Sep 26 15:42:17 BST 2013

Ah, thank you. Sounds like the cause. I'll file a bug; in the mean time 
I suggest you only use 5672 for keepalived.

Cheers, Simon

On 26/09/2013 3:27PM, Santi Nuñez-Cacho wrote:
> 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 <mailto: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
>     <mailto: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>
>             <mailto: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
>
>
>

-- 
Simon MacMullen
RabbitMQ, Pivotal