RabbitMQ and Federation

140 views
Skip to first unread message

lorenzo.c...@gmail.com

unread,
Apr 30, 2014, 3:27:20 AM4/30/14
to particula...@googlegroups.com
Hello,

i'm here to ask for advice on NServiceBus over RabbitMQ...

Our as-is scenario is (a bit simplified) something like this:

EndpointA is a publisher and EndpointB is a subscriber, connected over internet to a RabbitMQ central broker. So, in detail: 

  •  EndpointA (located in geographical site A) connected over internet to a single central broker (No RabbitMq cluster, no federation, no shovel)
  •  EndpointB (located in geographical site B) connected over internet to the same single broker
Everything works fine as far as there are no "network problems" (and since we are over internet, full network reliability cannot be guaranteed): when endpoints can't communicate with broker, they start raising exceptions, and if broker doesn't come on line again in a "reasonable" time (1.30/2 mins) they raise a fatal exception and shut down.

Looking at RabbitMQ documentation, it seems that you can avoid this kind of issues with a federation/shovel scenario:

  • EndpointA (located in geographical site A) connected over a reliable network (LAN) to brokerA (let's stay simple: located in same geographical site A)
  • EndpointB (located in geographical site B) connected over a reliable network (LAN) to brokerB ( located in same geographical site B)
  • brokerA and brokerB are connected over internet in a federation/shovel configuration

So my questions are: 

1) Can NServiceBus out-of-the-box handle a federation/shovel scenario like the one described above? I mean, in my simple (one single central broker) scenario, no additional configuration is needed at RabbitMQ administration level; if both endpoints have the same transport connection string,  everything is configured by NServiceBus installers when you install the endpoints: queues, exchanges etc. You configure NServiceBus and then NServiceBus configures the transport layer. Is the same in a federation/shovel scenario? EndpointA has a transport connection string pointing to brokerA, EndpointB has a transport connection string pointing to brokerB, and when installers run, NServiceBus creates federated queues and exchanges. Is this right? I can't find any specific documentation about that...

2) While we are setting up this new scenario, is there a way to handle issues related to an unreliable network? I asked in a previous post (https://groups.google.com/forum/#!topic/particularsoftware/bDxi5-JL4MM), if you can configure the endpoint behavior when broker becomes unavailable, but it seems there is no way to do that...So are there any alternatives? Federation/Shovel is the right path, but in the meantime?

Thank you!

Andreas Öhlund

unread,
May 7, 2014, 5:15:10 AM5/7/14
to particula...@googlegroups.com
>Can NServiceBus out-of-the-box handle a federation/shovel scenario like the one described above? 
NServiceBus doesn't setup the federation/shovel for you but it should work if you set it up your self. And it since its handled within the broker it should just work

>Is the same in a federation/shovel scenario?
See above

>NServiceBus creates federated queues and exchanges. Is this right? I can't find any specific documentation about that...
We don't do anything special in regards to federation so you would have to do that your self

>2) While we are setting up this new scenario, is there a way to handle issues related to an unreliable network? I asked in a previous post (https://groups.google.com/forum/#!topic/particularsoftware/bDxi5-JL4MM), if you can configure the endpoint behavior when broker becomes unavailable, but it seems there is no way to do that...So are there any alternatives?

We're going to expose the settings in an upcoming release but that isn't helping you now. In the meantime you should be able to inject your own connection manager:




 Federation/Shovel is the right path, but in the meantime?

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/2f9c8e76-7c87-4429-9aab-d654f830015f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Andreas Öhlund

unread,
May 7, 2014, 5:16:28 AM5/7/14
to particula...@googlegroups.com
Fatfingered the send:)

Here is the link to how you specify connection manager:


That way you can create your own that is tuned to handled the flaky connections better

Cheers,

Andreas


On Wed, Apr 30, 2014 at 9:27 AM, <lorenzo.c...@gmail.com> wrote:

--

lorenzo.c...@gmail.com

unread,
May 7, 2014, 10:34:16 AM5/7/14
to particula...@googlegroups.com
Thanks for the info,
but creating a custom connection manager sounds "write your own RabbitMq client" to me...and  it's not an effort we can afford right now. Maybe a brute force workaround like a powershell script that restarts stopped endpoints...but the only real solution is Federation/Shovel scenario, hoping it's all handled by the broker, without needing application code change.

Thanks again
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages