CODEWITHSUNDEEP
rabbitmqcluster-computingload-balancingnservicebushigh-availability
devopsfanatic
devopsfanatic

Reputation: 51

Configuring RabbitMQ cluster with NServiceBus

Given the following scenario:

I have two servers, each of them has RabbitMQ queuing installed and they form a cluster. I have configured them for HA queues using mirroring.

We use NServiceBus as messaging framework. We have a Service A (load balanced WCF service) which should publish messages to RabbitMQ exchange and Service B (clustered) which should dequeue messages and process them. The problem is how should I configure NServicebus on both nodes. I cannot specify single host names for connectionstring like this:

<connectionStrings>
  <add name="NServiceBus/Transport" connectionString="host=nodeA, nodeB" />
</connectionStrings>

This is because the feature has been deprecated in current NServiceBus release. It makes sense. I cannot specify cluster name either.

<connectionStrings>
  <add name="NServiceBus/Transport" connectionString="host=clustername" />
</connectionStrings>

This option does not work.

I tried also localhost which works for Node A, but not for Node B (which has the slave queue).

What should I define as host to make it work (on both services, A and B)? What it is needed for Node B to dequeue messages from master queue?

There might be things I do not understand but help me out, please.

Upvotes: 0

Views: 568

Answers (2)

devopsfanatic
devopsfanatic

Reputation: 51

You need to put localhost in the connectionstring like this:

<connectionStrings>
   <add name="NServiceBus/Transport" connectionString=" host=localhost" />
</connectionStrings>

Then it works :)

Upvotes: 1

melkio
melkio

Reputation: 101

RabbitMQ docs gives advice about connecting to a cluster from client: it's not a RabbitMQ concern but you have to use other technologies like a load balancer.

Generally, it's not advisable to bake in node hostnames or IP addresses into client applications: this introduces inflexibility and will require client applications to be edited, recompiled and redeployed should the configuration of the cluster change or the number of nodes in the cluster change. Instead, we recommend a more abstracted approach: this could be a dynamic DNS service which has a very short TTL configuration, or a plain TCP load balancer, or some sort of mobile IP achieved with pacemaker or similar technologies.

NServiceBus follows this suggestion: v 3.x of RabbitMQ transport drops the facility to specify multiple hostnames in the connection string as detailed here

Upvotes: 1

Related Questions