1

NOTE: Following on from the responses I got, it seems that Azure Service Bus is not the right tool for this job. I'm leaving the question here in case it's of use to anyone else.

I want to set up a situation where I have one app that publishes messages, and multiple apps that receive the messages. From what I can see, Azure Service Bus Topics is designed for this. The accepted answer to this question says the same thing.

I have been following the quick start sample to produce two console applications, one to send messages and one to receive them. This works fine when I only have one instance of the receiver app running, but if I start two instances of the receiver, only one of them gets any messages.

I tried removing the call to CompleteAsync in the code that receives the messages, but this didn't make any difference.

The code I'm using is exactly as shown in that article, so no point in posting it all here.

I'm sure I'm just misunderstanding something basic, but I thought the idea was that topics and subscriptions allowed you to have as many receivers as you like.

Anyone able to explain what I'm doing wrong?

Avrohom Yisroel
  • 8,555
  • 8
  • 50
  • 106

2 Answers2

2

You need to have different Subscription Clients in place of different receivers. You should have two Subscriptions under the Topic to receive it in two different places.

In this way, you need to create the Subscription Clients for both the Subscriptions, one in each receiver application. So that you can receive the messages in both the applications simultaneously.

Arunprabhu
  • 1,454
  • 9
  • 15
  • Thanks for the reply. We can't create a new subscription for each user, as these are varying all the time, depending on who installs and uses the application. Looks like this is the wrong technology altogether for us. – Avrohom Yisroel Jan 22 '19 at 16:26
0

Scaled out receiver represents a single logical endpoint. You scale out to process messages faster, not to ensure each instance gets a copy. If you have a need in that, then your receivers must be logically different endpoints, not the same one. Same logical receiver/endpoint should not handle the same message twice.

To sum it up:

  • Use the same receiver and scale out if you want to process messages faster.
  • Use different receivers if you need to ensure each one is guaranteed to receive all messages.
Sean Feldman
  • 23,443
  • 7
  • 55
  • 80
  • Seems like I'm missing a basic point here. My eventual use case is a central server that handles web requests made from a desktop app that is used by many people. I want the server to be able to notify the desktop app that data has changed. How should I handle this? Please remember I'm very new to this (like since this afternoon!), so am not very clear on the technicalities yet. Thanks for the reply – Avrohom Yisroel Jan 21 '19 at 23:47
  • It sounds like every desktop app is a different endpoint that should receive notifications, but I'd not use Azure Service Bus for that. You might be better off with something like [SignalR service](https://azure.microsoft.com/en-ca/services/signalr-service/) for client notifications. If you need more help, I suggest researching a bit more on the web as SO is intended for specific questions rather than "how do I design/build X". Cheers. – Sean Feldman Jan 21 '19 at 23:52
  • Check out Azure Notification Hub. Might be a better fit. – Josh Jan 22 '19 at 00:54
  • @SeanFeldman We tried SignalR, and found it quite flaky and poorly supported. That's why I was looking for other options. Sadly, it looks like SignalR is our only option. I might close this question, as it started out as a specific "how do I do this?" request, and as you say, is turning into a "what's the best technology?" request. Thanks anyway – Avrohom Yisroel Jan 22 '19 at 16:24
  • @Josh Thanks for the suggestion, but we are using WPF, so can't use Azure Notification Hubs. We can't move to UWP, as apart from the huge cost of rewriting, we have a lot of users still on Win7. – Avrohom Yisroel Jan 22 '19 at 16:25
  • Please note there are alternatives to SignalR. Might be worth evaluating those as well. Cheers. – Sean Feldman Jan 22 '19 at 16:26
  • when a receiver get the message, it hide the message to the other receiver (Peek Lock). So just one can take the message for prevent double treatment. You just can make roundrobin (two receiver, if one is busy, the other take the message) but, if I'm rigth, you can't send message to all the receiver. – Paul Jan 23 '19 at 09:54