[rabbitmq-discuss] Durable queues & bindings

[Matthias Radestock]

Levi,

Levi Greenspan wrote:
> I have the following settings in /etc/rabbitmq/rabbitmq.conf
> 
> RABBITMQ_NODE_IP_ADDRESS=127.0.0.1
> RABBITMQ_LOG_BASE=/opt/logs/rabbitmq
> RABBITMQ_MNESIA_BASE=/opt/otp/mnesia
> RABBITMQ_PIDS_FILE=/opt/otp/pids
> 
> and in /etc/rabbitmq/rabbitmq_cluster.conf:
> 
> [rabbit at localhost].

The default location of the cluster config file is 
/etc/rabbitmq/cluster.config. The docs say 
/etc/rabbitmq/rabbitmq_cluster.config, which is wrong.

Did you change that setting to point to /etc/rabbitmq/rabbitmq_cluster.conf?

If not that would explain why getKnownHosts returns one node only, 
though it doesn't explain why it would only do that for 1.5.4 and not 
1.5.3. Perhaps your config changed?

To check whether the clustering is set up correctly, run "rabbitmqctl 
status". That should show both nodes as running.

>>> I upgraded to version 1.5.4 and now I see the queues and bindings after
>>> > > the node is running again. However in 1.5.3 it didn't work for me.
> [...]
> I have attached a small Java test client and a transcript which shows
> the different behavior between version 1.5.3 and 1.5.4. Maybe you can
> reproduce it.

I can indeed reproduce your findings: bindings to durable queues 
residing on nodes in a cluster are not restored when the queues' nodes 
restart. Thanks for reporting this; I have filed a bug.

This happens for me in both 1.5.3 and 1.5.4; the reason that it works 
for you in 1.5.4 is probably the same reason that getKnownHosts returns 
just one node, namely that the clustering was not set up correctly when 
you ran that test.


Regards,

Matthias.