How to host a Windows Service in IIS and keep that service runing like it is running on Windows?
Could I use some feature from WCF service?
I've not access to the Windows itself, only to IIS. Inside that service I'll create a thread which at scheduled time will process some data.
In short, you can't.
A more detailed answer is that there are 2 problems:
IIS worker processes are launched only when a HTTP request comes in. This means you can't start your service with the system.
IIS worker processes are recycled (i.e. restarted) on several conditions. For example, a worker process is restarted if no HTTP request comes in for a long time. This means you can't control when your service is shut down, unless you have access to application pool recycling configuration. Keep in mind that the recycling logic only ensures that all pending HTTP requests are complete, but does not await all background threads to complete.
You can come with a partial solution this way:
Create a WCF service method that checks if your long-running thread is alive and if not, starts it.
Create a very simple windows service that periodically (once in 5 seconds) calls that method. Deploy the service somewhere, e.g. on your own machine.
The only question that remains is: do you really need to avoid windows services? Could you find a place to host the service? There are some use cases when a windows service is the best or even the only way.
You cant, in a nut shell.
However you can make use of the health monitoring API specifically the heartbeat functionality. see:
http://msdn.microsoft.com/en-us/library/system.web.management.webheartbeatevent.aspx
for details on the class you will need to implement to be called when there is work to do
also this answer on SO might help
Understanding heartbeat in ASP.NET health monitoring
Once you have implemented a webheartbeatevent derived class you can check your db or what ever you want to check if there is work to do.
A better solution IMHO is to scrap the service entirely and redesign the system to be 100% web based, as services become a deployment and maintenance nightmare. as i assume you are now finding out...
Related
If I create a web application and host it on a Windows Server, then as I understand it, IIS handles the initial request and routes it to the appropriate website or application. I'm under the impression that a w3wp.exe (worker process) instance is created for each application. IIS works with the worker process, which in turn works with the web application.
What happens if the application gets twenty requests per second? Will the worker process create twenty instances of the application to handle each request, or will it queue the requests passing them to a single instance of the application as and when?
I suspect it's the latter. If that is the case then am I right to think that the worker process will keep an application alive whilst it is getting requests?
I'm trying to fully understand what a web application does when it handles many con-current requests. I've tried asking this question before but struggled with the wording, so hopefully this makes sense.
EDIT:
Thanks to Mason I realised that the answer was right in front of me! Web applications use DLLs, which can't run by themselves. It's the w3wp.exe (worker process) which call the DLLs to handle the requests.
The number of worker processes per web site is controlled in the application pool advanced settings (in IIS management console).
The configuration of number of concurrent requests each of the workers can handle depends on the IIS version. In IIS 7 was in the same place, for more recent versions you will have to check your machine.config (looking for maxWorkerThreads)
Okay, so let's say I have a web application that absolutely has to perform some kind of startup and has to remain running indefinitely regardless of the communication it receives from the clients (as it's a push based system)
Now for testing I have been hosting this as a windows service, which is great because it allows for me to have a hard entry point to the application where I can do my bootstrapping and get the service up and running
Next, I'm trying to move this into the IIS world instead so I can face this service to the outside world...and I've hit a snag...I don't have any hard entry point where I can bootstrap the application except for global.asax, which as I understand it is only invoked when the clients make a call to the server
Is there a better area I can put an entrance to the application and get it bootstrapped without waiting for a client to connect to it? And is this area only called once or is it going to be called periodically as the application falls out of scope (so to speak)? Like I said, the app has to remain running at all times
Is there a better area I can put an entrance to the application and get it bootstrapped without waiting for a client to connect to it?
Yes, there is. You can warm up IIS.
And is this area only called once or is it going to be called periodically as the application falls out of scope (so to speak)?
It depends which method in Global.asax you use. Application_Start runs once per app start.
Like I said, the app has to remain running at all times
Beware, dragons here. This depends how critical it is. If you need utter reliability, you must use load balancer and have at least one other duplicate service. Other things to consider, app pool needs to be recycled from time to time. IIS, OS, your application have bugs, updates needs to be installed, network device fails, power outages do happen and so on.
We want to synchronize the data in our application with the data of an external service. (Such as accountancy software. This synchronization should be executed every night and when the customer wants to.
I am aware that long running threads don't belong in web applications and this synchronization should be executed within an external windows service. But the downside of this method is, that is becomes harder to deploy / maintain, since the application can be installed on the customer's webserver too.
Is it possible to completely integrate this synchronization with just the use of a class library project withing my solution, which will start up at the Application_Start event?
Since your application is hosted on IIS, it's maintained by the application pool process. If you create additional module for your task, it will be running within context of the same process. You have to be sure this process is still working in the middle of the night, when application is not used, in order to perform the synchronization you want. You can use Quartz.NET to schedule your sync task.
But still, I think much better idea is to perform the synchronization from windows service. Service should communicate with the application for example by using database, where it logs its current activity. It gives you the possibility to monitor of the service state from the web by connecting to such database. I know service forces some additional administration effort, but it will be much more reliable and secure. You can also add service starting possibility from your web application (if pool process user has access rights to windows service) to overcome (or at least minimize) administration effort connecting with restarting your service after some failure.
I've written such functionality, so just to give you an overall look of what I mean by web monitoring of such external service, check the screen below. It can be written with the ajax support to achieve more responsiveness (pooling mechanism), which will be convenient for the end user.
I have seen examples, sample codes etc for self hosting WCF services within a console app, windows service etc.
My question is, how will this work in production? Will it be efficient? Will it scale?
I m not sure, how it will work, so other question is, will that be single threaded? multi threaded? do i need to manage the multi threading? appdomains?
I prefer hosting with command line, windows service for application related reasons.
My question is,
Will it be efficient? Will it scale?
Yes and yes. But for really large scale apps you should still consider IIS (+WAS).
so other question is, will that be single threaded? multi threaded?
That is determined by the configuration.
Will it be efficient?
It depends on the service implementation, on the maximum number of requests it is able to manage within a specific time-frame. Efficiency is a relative measure: let's assume your service is able to process 20 messages/sec, if your requirement is to be able to process 10 messages/sec, then your service is efficient. But if the requirement is 30, then it is not.
Will it scale?
Once again, it is not related to hosting. Are your services stateless? if not then, they probably won't scale much since load balancing is not possible.
Will it be manageable ?
Probably not:
- you need to have a user logged on the server to run the app
- it does not auto-start with the server
- it cannot auto-restart on failure
- it does not create instances of the service pro-actively
- it does not provide (without custom code) a way to check the service health
Single instance ? Multiple threads ?
If your service does not maintain state between calls per client, then configure it as "one instance per call and no multithreading" -> No concurrency, high throughput
If your service does maintain state, then configure it as "one instance per session and multithreading" to allow a client to perform concurrent calls. Be careful about concurrency issues and protect your resources.
If your service does not maintain state per client but keeps some global data stored for all calls, consider the "single instance per service and multithreading". Keep in mind the possible concurrency issues. In that you might as well use "one instance per call" and keep the global storage out the service.
A Windows service hosting a WCF endpoint is fine for small services that aren't going to be hit often; you don't have to mess with IIS (which can be a REAL pain IMO). However, there will only be one listener listening, so it's not recommended for a service that is likely to be hit from several places at once (use IIS for that; it sets up an app pool that can handle many simultaneous requests). This model is good for one-on-one interop between two machines; you might set up the service host on a "set and forget" box living out in a warehouse somewhere, and call it to perform simple but custom tasks like rebooting, log dumps, etc.
Avoid having any user app (console or otherwise) host a service endpoint, except for initial proof-of-concept testing. In addition to the single-listener drawback, a user app MUST be run in the context of a logged-in user (not the service users, which are "logged in" as part of Windows startup), and must have custom "keepalive" monitoring; with a service, Windows can be told to simply restart it if it crashes, while it doesn't give a toss about a user app crashing other than to prevent that program taking down the whole OS (and to ask the user if they want to report the crash).
Scenario: A WCF service receives an XDocument from clients, processes it and inserts a row in an MS SQL Table.
Multiple clients could be calling the WCF service simultaneously. The call usually doesn't take long (a few secs).
Now I need something to poll the SQL Table and run another set of processes in an asynchronous way.
The 2nd process doesn't have to callback anything nor is related to the WCF in any way. It just needs to read the table and perform a series of methods and maybe a Web Service call (if there are records of course), but that's all.
The WCF service clients consuming the above mentioned service have no idea of this and don't care about it.
I've read about this question in StackOverflow and I also know that a Windows Service would be ideal, but this WCF Service will be hosted on a Shared Hosting (discountasp or similar) and therefore, installing a Windows Service will not be an option (as far as I know).
Given that the architecture is fixed (I.E.: I cannot change the table, it comes from a legacy format, nor change the mechanism of the WCF Service), what would be your suggestion to poll/process this table?
I'd say I need it to check every 10 minutes or so. It doesn't need to be instant.
Thanks.
Cheat. Expose this process as another WCF service and fire a go command from a box under your control at a scheduled time.
Whilst you can fire up background threads in WCF, or use cache expiry as a poor man's scheduler those will stop when your app pool recycles until the next hit on your web site and the app pool spins up again. At least firing the request from a machine you control means you know the app pool will come back up every 10 minutes or so because you've sent a request in its direction.
A web application is not suited at all to be running something at a fixed interval. If there are no requests coming in, there is no code running in the application, and if the application is inactive for a while the IIS can decide to shut it down completely until the next request comes in.
For some applications it isn't at all important that something is run at a specific interval, only that it has been run recently. If that is the case for your application then you could just keep track of when the table was last polled, and for every request check if enough time has passed for the table to be polled again.
If you have access to administer the database, there is a scheduler in SQL Server. It can run queries, stored procedures, and even start processes if you have permission (which is very unlikely on a shared hosting, though).
If you need the code on a specific interval, and you can't access the server to schedule it or run it as a service, or can't use the SQL Server scheduler, it's simply not doable.
Make you application pool "always active" and do whatever you want with your threads.