I was wondering if it's safe to host an NServiceBus endpoint that serves as an event publisher inside IIS?
To clarify, we use an application hosted in IIS as our CRM system (Microsoft Dynamics CRM), and I want to use NServiceBus to publish an event when a contact's information is updated.
MS CRM allows the use of custom plugins to react on a contact update, and I intend to create a plugin that publishes a 'ContactUpdated' event through NServiceBus for that situation. Hence, this will effectively mean that my NServiceBus event publishing endpoint is hosted in IIS.
Now, I know that a self-hosted NServiceBus endpoint will create its own worker thread
to monitor incoming messages (in this case subscription messages) from the queue. Because IIS is free to unload a worker process if there are no more incoming web requests, it's usually not a good idea to use IIS to host long-running processes in.
However, I'd say that the NServiceBus queue monitoring thread does not qualify as a long-running process because it doesn't do any processing and can be stopped at any time: new subscription requests
will then simply be queued until the web application is restarted again.
I'm just wondering if the way IIS cleans up this NServiceBus thread is safe, from an NServiceBus perspective?
(Incidentally, I also found this article, but I have to admit that only the Scaling out argument resonates with me, and that is not relevant in our situation.)
Yes, it is safe to host an NServiceBus publishing endpoint in IIS.
As you said, if IIS were to unload your worker process then any pending subscription requests would be waiting in the queue. This is reasonable - as long as you don't make any assumptions about the order in which a subscription request would be handled and a new event published.
Related
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
I have a WCF service hosted on IIS, where during application initialization it start listening to the RabbitMQ and it subscribed to the Q say Q1, after long run of the service, we are seeing that the service is fetching the messages and it fails to processing it.
But we do have the different windows service which is also interested in the same events which is subscribed to the different Q say Q2, was able to process all the events even after a long run.
Why does the WCF is failing after long run, is there a thread pool sealing which will be imposed on Apppool ? Need help in debugging this.
Note: Both Queues (Q1 and Q2) are subscribing to the same message rout keys which is connected to the exchange.
Well I'm not sure about processing, but by default IIS-hosted anything AppPools recycle/expire after 20 minutes so it's entirely possible your WCF service is no longer running if its service methods have not been invoked.
Try setting your IIS AppPool timeout to 0 to disable timeout.
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 have a bunch of wpf test clients which are self hosted nservicebus endpoints. The test clients are subscribing to several events of another endpoint at startup. Before the test clients are shutting down, I want their subscriptions to be removed. The first idea I came up with, was to use IWantToRunWhenBusStartsAndStops.Stop() where I unsubscribe all events.
The problem with this solution is that when nservicebus invokes IWantToRunWhenBusStartsAndStops.Stop() some objects have already been disposed. e.g. when nservicebus tries to create an object of TransportDefinition to decide if the endpoint has support for centralized pub\sub.
I'm not sure, if the problem only occurs in a self hosted scenario. Are there any suggestions?
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.