Using Azure Service Bus in local

Question

I am working with Azure Service Bus Topics and Subscriptions. It's being used to send control messages across the application. The message listeners (subscribers) are running in a worker role and they are picking up the messages and processing the request. Each message in the bus can be picked up by only once, even if there are multiple listeners running simultaneously.

There is no issue in using the Service Bus; however we are facing some issues while debugging/testing the application in local. We have 2 service bus, one for the cloud and one for local debugging. Now if multiple people are debugging the application simultaneously, the message is being picked by only one of the system (at random). This is the intended behavior, but it's causing a nuisance while debugging.

Is there any way how I can use a local emulator for the Service Bus? I did some research but I couldn't find any reliable solution for this. Is there any way how we debug the application in isolation?

Casillas

Answer 1

Unfortunately, there is no Azure SB local emulator. That was asked before, and you can try to use Service Bus for Windows Server but it is slightly behind the cloud service in terms of features support/functionality, etc. Still, it supports Azure SDK, for example. MSDN link for SB for WS.

Mervin

Thanks Alex, not sure if its the exact thing we are looking for. Still will give it a try. Is there any future roadmap where such a functionality might be available? – Casillas

To be honest - i don't know (to be more honest - i think no). You may want to try to up the ask on the feedback site ("that was asked before" link) with that question - product group is monitoring that site. – Mervin

geekswithblogs.net is not available anymore. Archive link: web.archive.org/web/20191230115935/http://geekswithblogs.net/… – Getraer

Answer 2

Azure Service Bus is a broker with competing consumers. Having multiple developers debugging using the same namespace will be be tough (message lock duration expired and another developer that happened to be debugging got that message). I would suggest to look into a namespace per developer. With MSDN license you're given enough Azure credit to have each developer work in a "sandboxed" namespace. As to how to get it working, you can read from a configuration file, environment variable, etc.

On the ASB for Windows Server - currently it's on version 1.1 where Azure SB is on 3+. Hosted version will be always ahead of the on-premises. Something to consider.

Abib

Answer 3

The problem should probably be solved by abstracting the service bus implementation so that it can be swapped for something that you actually can run locally (or in memory). I would suggest not to re-invent that wheel though and choose a library like Masstransit https://masstransit-project.com.

Microanalysis

Answer 4

We ended up using a different topic name for each developer while debugging which is working pretty good.

Rattle

Exactly what we did – Casillas

Answer 5

We use the devlopers machine name in the path for alot of dev things. for example a queueName like "TheEventMessageQueue" can be "TheEventMessageQueue-Machine123" and we use a dev subscription so we dont make a mess :)

By using the machine name its easy to se who the que belongs to if its going out of control

Bertolde