[rabbitmq-discuss] Clustered server doesn't permit local connections

Wed May 23 17:50:38 BST 2012

Damn, this is a bug :( I've replicated it.

It occurs when you bring up a new node in an existing cluster, and that 
node is sufficiently short of memory or disc space that the memory or 
disc space alarm goes off immediately. It does not occur when an alarm 
goes off after the node has started.

I believe it should only manifest on the new node. Certainly that's what 
I'm seeing. But the node never recovers. And a running node should not 
be able to get into this state.

The workaround is to ensure your nodes have enough memory and disc space 
when they start.

Needless to say, we will fix this in a new release soon.

Cheers, Simon

On 23/05/12 17:05, Glade Diviney wrote:
> I'm running 2.8.2 on both machines. Version lines in "rabbitmqctl
> status" match on both.
>
> I installed from .deb, from the "testing" repo as instructed by
> http://www.rabbitmq.com/install-debian.html.
>
> I tried disabling the cluster, and was able to bring up the singleton
> rabbitmq instance and use it successfully. As soon as I brought up the
> other instance, everything fails again.
>
> Thanks for the troubleshooting you've done so far...any other advise?
>
> -Glade
>
> On Wed, May 23, 2012 at 8:37 AM, Simon MacMullen <simon at rabbitmq.com
> <mailto:simon at rabbitmq.com>> wrote:
>
>     On 23/05/12 16:24, Glade Diviney wrote:
>
>         Hi Simon,
>
>         Your instinct may be right on alarms. I did service rabbitmq stop,
>         cleared the logs, the service rabbitmq start and saw this in
>         rabbit.log:
>
>
>     <snip>
>
>
>         ** Reason == {'function not exported',
>
>           [{rabbit_alarm,remote___conserve_resources,[<2894.58.__0>,true]},
>                            {rabbit_alarm,internal___register,3},
>                            {rabbit_alarm,handle_event,2},
>                            {gen_event,server_update,4},
>                            {gen_event,server_notify,4},
>                            {gen_event,handle_msg,5},
>                            {proc_lib,init_p_do_apply,3}]}
>
>         What's the prognosis, doc?
>
>
>     Aha!
>
>     That function was renamed in 2.8.2. Are you by any chance running a
>     cluster with mixed RabbitMQ versions?
>
>     That is very likely to lead to random breakage - like this.
>
>     Future versions of RabbitMQ will probably refuse to start instead.
>
>
>     Cheers, Simon
>
>     --
>     Simon MacMullen
>     RabbitMQ, VMware
>
>

-- 
Simon MacMullen
RabbitMQ, VMware