I currently have a Windows Service which continually runs throughout the day. It has multiple threads which kick off:
tasks daily to update cache
tasks weekly to do cleanup
24/7 task to import XML into SQL Server
tasks which run for around 12 hours per day kicking off a console application to manage ETL
The tasks are not the important part of this question but it gives you the idea that this Windows service has grown to be a monster. It manages the imports of somewhere in the region of 300 million records per day.
It is hectic, but it works.
This iteration of development is giving me a chance to review the service and possibly break it down so that it is more manageable. It is thought that this could be multiple services with one manager service - ideal if a component needs to be updated then the whole thing does not need to grind to a hault.
Does anyone have any experience with this? I am keen to hear about your approach because it is new territory for me.
I have read this SO post which touches on the topic.
Cheers.
Your description sounds a lot like the thing I wrote about 2 years ago. A windows service which hosts addins and runs them in multithreaded environment. The architecture used is the .NET addin pipeline introduced in .NET 3.5 (System.AddIn-namespace). It works like a charm as I also integrated live/hot updates. It's so easy to implement new addins and just plug them in whenever I like. So I really recommend using this addin stuff.
See http://msdn.microsoft.com/en-us/library/cc175292.aspx for a quickstart.
I've done something similar for our background services, there's basically a ServiceHost and "Servlets" which are loaded via appdomains so they don't impact each other.
Why a service? Pretty much none of the things you do- except the 24/7 task for imports - are something I would do as a service.
I would use:
Either command line programs that get regularly scheduled, especially on the daily / weekly tasks
Or use SSIS and SQL Scheduler to schedule something.
The only thing that may justify a service is the 24/7 XML import - unless you can get away starting it, for example, every 5 minutes.
Related
I need to write a windows service which performs several operations as follows:
Fetching data from api and dump it to db - to be performed every hour
Consolidation - to be performed every 6 hours
Summary - to be performed once a day at 01:00
I don't want to use multiple timers or no timer at all. Please suggest best way to schedule these tasks.
There are multiple ways to do this. If you insist on using a windows service, you could look into Hangfire. The cost for using this is that you'll need to add a database that can store the information about the jobs.
Check the following link for Hangfire: https://www.hangfire.io/
You can also use the native Windows Scheduler for scheduling jobs.
Instead of creating a windows service you'll create a console app or something similar and use the Windows Scheduler for when it should execute.
If you don't want to use the native functionality I recommend using a nuget package like this one; https://www.quartz-scheduler.net/
All the above was found with a little bit of google magic and knowing the windows operating system..
I have a web app that I'm writing right now that is supposed to have "periodical events". For instance, at midnight, the web app should calculate "scores" for all users. I want this done only once during the day.
Is there a way that I can automate this, so it runs automatically at midnight (or whatever hour I choose)?
I don't like the idea of creating a separate script (VBS) to do this, as the calculation would depend on a lot of business logic of the app. I was thinking to put it into a separate Class Library, so it can use the web app logic (which is also in a class library), but is this the best way to go about it?
I also don't like the idea of using the Session_Start() event in the Global.asax to trigger the event by checking the hour manually. There must be some easier way - especially because down the road I expect there will be a lot more of periodical events - some may have to be triggered every fifteen minutes, for example ...
Thanks a lot for any help you can give me.
You should not do this in the web app itself. You are correct to put the business logic in a separate library. Once you have done this, you can use the business logic from anywhere, and therefore, a good solution would be to create a console application that does the nightly jobs, and invoke the console application from Windows Task Scheduler. IIS is not suitable as a host for periodical events.
I guess you are missing the point of separation of concern. Whatever you are asking is a job of a service. You need to develop a separate application as Windows Service that will do all your calculation and to be triggered by any scheduler even Windows Task Scheduler would do. This is what basically done on large scale applications.
Yeah... again awesome "change your architecture and hosting environment so that my answer can be relevant" responses.
Doing what you ask is actually quite easy, take a look at this article: http://www.codeproject.com/Articles/12117/Simulate-a-Windows-Service-using-ASP-NET-to-run-sc
This is a job for a windows service or scheduled task. A web application responds to HTTP requests. Essentially the service's job would be to wake up, run the appropriate calculations and write back to the database. Once in the database, your web application can use the newly calculated values.
Here is some information on windows services: http://msdn.microsoft.com/en-us/library/d56de412.aspx
How do I send email on daily, weekly and monthly bases using c#.net?
I was thinking of creating a windows service application but I don't know how to do it and if it's the right way to take.
Your thoughts are greatly appreciated.
A windows service is probably the best option.
In your service have a timer that fires with whatever resolution you need (every minute/hour/day etc) and on the timer tick even send your emails.
There are many tutorials for creating windows services with .NET.
A Windows service will do the trick. A good benefit of a Windows service is that it starts up when Windows starts up (or can be set to, anyway). So the machine can be left fairly unattended (as a good server should) and doesn't need anybody logged into it for the service to run. So if that's an important consideration for your scenario then perhaps a Windows service would be the way to go.
If you just want to create a console application instead (which can generally be easier to create/test/debug) then you can schedule it with the native Windows task scheduler. However, unless I'm mistaken, I think a user needs to be logged in to the machine in order for it to run. At least under certain circumstances. So a Windows service is probably your best bet for an unattended task.
As for creating the service, Visual Studio should have a project template for that. The scheduling would be handled with a Timer.
You could also use the Windows Task Scheduler. Quartz.Net seems to be the right tool, too (never used it though).
Windows Service is a good choice.
Remember to save state to disk (file or database) because service restart (for example, due to a reboot) is possible. For example, your next email delivery is a week in the future, you have to save that date to disk. So when your server is down due to a power failure 3 days later and recover after another day, your Windows Service can still set the right timer according to the date saved to disk.
Create a console application, which would be launched from the Windows task scheduler. Creating a windows service is unnecessarily complex, IMO, since you are simply having the program execute in response to time intervals; not other unpredictable external events where you would need a 'listener' type application. KISS!
I have nearly completed a Quartz.NET based Windows Service (using ADO.NET, not RAM jobs). The service copies/moves files to various paths depending upon a schedule. I have some concerns however. It is very important that this service has some sort of detection method/system that will detect when the program has failed for whatever reason - whether it's files failing to be copied, or the whole scheduler crashing . Just wondering what you guys think is the best way to do this? I have a couple of vague ideas but I'm looking to hear some more input.
Here are the methods that we use:
We monitor the windows service itself using the IT monitoring system. We use one of those commercial products that monitors servers, services, databases, etc, but there are open source projects that can do this for you if you don't already have one in place.
We log fatal execeptions to a database table and have a separate service monitoring that table for exceptions.
We also use an ADO.Net store, so we also monitor the Quartz.net tables for things like stuck triggers.
With things like this you can definitely go down the over engineering path. Just keep in mind the cost benefit of adding each of these options and then decide how much work you want to put into monitoring, VS the cost of an outage.
I'm making a small application that is supposed to download info from the web every day at 2am. It will download the information and write the strings to an XML file of my choosing.
Using .NET and C#.
My initial approach was to install a service on the users computer and have that run, but I'm not so sure. I've not even used it so much in the past, only once.
Which is the best (read: time tested :P ) approach to this very common problem.
You can either build your application as a Windows Service, as you mentioned.
Or else it would probably be a better idea to create a normal console application, and launch it automatically at 2.00am with the Windows Task Scheduler.
You can consider both methods as popular and "time-tested".
I would suggest having a console app, which calls data fetching algo in a separate public class (not the main method).
Like Daniel mentioned, run it via Windows Task Scheduler which itself will take care of most scheduling requirements.
This allows the solution to be scaled in the future if need be. E.g. convert into Windows Service, full GUI Winform or even SQL server scheduled tasks etc.