I have inherited an azure service bus solution - C#, Web Api with Singleton service implementing the queue. Running locally on my PC, I can publish a message to my Dev queue and see that event consumed by my service bus receiver. No problem.
In our staging environment however my receiver is not firing so my code never processes the messages. I found an instance where a different environment was pointing to the staging queue purely by luck which makes me think "what else is using this queue". We have no application logging (useless I know) of when events are published or consumed so I wondered, is there a way from within Azure to see either
What is consuming the events published to the queue, or
What is currently connected to the queue so I can validate each connection and make sure a dev in a far flung office isn't running test programs using the queue.
Thanks
Create application insights instance
Connect your web app in azure to the created AI
after some time you will be able to see requests to other systems sent by your app (in application map you'll see fancy diagram of requests, in logs you can query requests to service bus)
Drop the AI instance if you don't need it anymore
Related
I'm developing ASP.NET Web API services and placing these onto an Azure Service Bus queue to be processed. The Web API services are hosted on Azure.
I need to implement an application that listens for these messages and processes them when they are received.
I'd like this to be hosted on Azure but not sure of the best way to approach this.
Can you implement such a listener service and host it on Azure?
What is the best way to approach implementing such an application / service?
There are several things you can do.
You could use ASB's OnMessage API which allows you to register your callback and handle incoming messages with concurrency and auto-completion.
On Azure you have several options: Cloud Services (worker roles), Azure Web Jobs, Azure Functions (if your processing is fast, otherwise I'd not recommend it), Service Fabric (might be a bit of an overkill if system is small), and plain VMs if needs to be.
Warning about functions - if you do intense work, Functions are not ideal as you'll pay for time/memory you execute.
A couple options for workers that listen to a queue are:
Functions
Web Jobs
You can see an example of using a Function here: https://learn.microsoft.com/en-us/azure/azure-functions/functions-create-an-event-processing-function.
An example of using Web Jobs is here: https://learn.microsoft.com/en-us/azure/app-service-web/websites-dotnet-webjobs-sdk-service-bus.
Both allow you to create background jobs that consume messages from a queue. Both support Storage and Service Bus queues. The main difference is that Web Jobs require an App Service Plan with some amount of instances, while Functions can run on a Dynamic plan, which scales completely automatically.
You should note that Functions are not meant for really long-running jobs (more than 5-15 minutes), though neither are Web Jobs.
Why not trying to run a linux process (daemon) in docker.
I just want to find out if this is possible or whether I'm over complicating it.
I have a web application (Let's call it central) that needs to interact with a WCF service that's running on multiple workstations. i.e. The user will select the workstations to send messages to and the web application will need to do a call to each of the workstations. These workstations won't be online all the time and in the worst case there can be just over 600 workstations that messages will need to be sent to at a single time.
I'm thinking of having a separate WCF service running on the central machine that will function as a sort of "proxy" between the web app (central) and the workstations. The web app will then make a single call to this service with a list of messages, the service will then process this list and add the messages to a queue.
From what I've read so far, the workstations will need to poll this central queue for messages but this seems like it will increase overhead quite a bit. Is it possible to push the messages down to the workstation as they are added to the queue?
I've never used MSMQ before and I'm fairly new to WCF as well so if there's a simpler way of achieving this do tell.
I'm thinking of having a separate WCF service running on the central machine that will function as a sort of "proxy" between the web app (central) and the workstations
I don't see any problem with you using an additional service to act as a "proxy".
the workstations will need to poll this central queue for messages
I would probably advise that you have a central "inbox" of messages to process on the central server. The "proxy" then locally processes the inbox. Have the web site send the jobs to the proxy.
Push model
For the workstations, rather than having them read from the server, have the server send the messages to the workstations. Have a unique queue for each workstation and that queue be situated on the workstation itself. Have the service send the message targeted for the workstation to the workstation's queue. As each message from the central queue/inbox is processed by the proxy, the proxy removes said message from the queue and moves onto the next one.
MSMQ Performance
Generally in MSMQ it's better to do network writes than network reads for scaling reasons. A multitude of computers all reading from the same queue is hurtful to performance. In other words, have the "central" service write to the remote queues (MSMQ will take care of transmitting the message when the machine is available).
the workstations will need to poll this central queue for messages but this seems like it will increase overhead quite a bit
Correct. Use BeginRead. Polling is hurtful to CPU and/or a waste of a good thread.
I have created a ServiceBus listener, and it works fine; the problem is deciding where to put it. It's now located in one of my APIs, but when the API is not in use the listener stops listening. I assume that's because of the application lifetime, and that the API is not running when it's not in use.
Can you provide me guidance on how and where to place the Azure ServiceBus listener so that it runs all the time and never goes down?
Sounds like you need a Worker Role running in a Cloud Service. A Worker Role is basically a VM wrapped around your code.
.NET Multi-Tier Application Using Service Bus Queues should get you going.
I am creating a client application that downloads and displays market data from Yahoo! for a university project, but that also sends out notifications to mobiles (so far using Google cloud messaging). So far it's a WPF client and the "server" is a class library - so far working. What I was wondering, is can you mix this server with a WCF service - the WCF service I was planning on using for registering devices, as well as accepting and parsing commands.
So I would call .Start() on my server object, and it will be constantly running in the background, while a WCF REST service runs alongside it - or would I be better simply having a thread running on the server that can accept input... sorry if this is confusing, but just wondering if it can, or has been done before or any advice. :)
Just to explain a bit better
The client front end and the "server" are running on the same machine - I was calling it a server because it is not only updating the front end, but sending out GCM notifications at the same time. I was wondering if maybe a WCF service could be added to make it simpler to handle adding devices to a database ("server" reads a list of device reg ids from a database, sends notifications to these) by allowing an android app to details via REST or something similiar
I would explore wrapping the class library in a Windows Service (which is essentially a process that runs continuously, and can be stopped/started/paused) and keep your WCF service as a web service for client communication.
How the WCF client service communicates with the Windows service is up to you - whether you store the data in a shared database, keep it in memory and have another WCF layer communicating between the two, etc. A shared database would be the most straightforward, especially if you want to persist the data for use by other apps/services as well.
WCF Service would be useful if you had one notification service on your server with multiple WPF client application connecting to it. If you have just one application running on the same server then not sure if it will be worth the overhead.
The usual pattern is to host WCF service in IIS, that way it always starts whenever first request is received. WCF is very flexible though, therefore you can host in in Windows Service, Console Application, etc.
I read that Signalr on Azure requires a service bus implementation (e.g. https://github.com/SignalR/SignalR/wiki/Azure-service-bus) for scalability purpose.
However, my server only makes callbacks to a single client (the caller):
// Invoke a method on the calling client
Caller.addMessage(data);
If don't need Signalr's broadcasting functionality, is an underlaying service bus still necessary?
The Service Bus dependency is not something specific to Azure. Any time you have multiple servers in play, some of your signalR clients will have created their connection to a specific server. If you want to keep multiple servers in sync something needs to handle the server to server real time communication. The pub-sub model of service bus lines up with this requirement quite well.
dfowleR lists a specific case of this in the comments. Make sure you read down that far!
If you are running on a single server (without the sla on Azure) signalR will work just fine on a Cloud Service Web Role as well as the new Azure Web Sites. I did a screencast on this simple scenario that does not take on a service bus dependency, but only runs on a single server.
In order to support the load balance scenario, is it possible to enstablish a "server to server" SignalR PersistConnection between multiple instances (ie on Azure) ?
If so, we can use a SQL Azure Table where all instances register at startup, so newest can connect to previous ones.