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

[Glade Diviney]

Also note: I rebooted both machines and the problem does not happen. From
experience, I expect it to occur again though.

On Wed, May 23, 2012 at 9:05 AM, Glade Diviney <gladed at gmail.com> 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>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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120523/d27feceb/attachment.htm>