I have requirement where I need to have some tasks to run permanently while some other should just be run on a scheduled basis but I'm not sure what the best way to handle this scenario should be.
For the scheduled jobs, I thought I'd use a Thread Pool and for jobs running permanently, I thought I'd just have an array of threads that would be created and started as my Windows Service starts.
Is that a correct and/or best approach or is there a better way to handle this?
Note that I need to be able to cancel a running job whether it be scheduled and/or permanently running.
Thanks
PS: Please note this question has been totally re-phrased as it was originally too broad. I hope this is a better attempt at it.
UPDATE:
Please note this question is not about a scheduler issue but more on what is the best approach to handle my threads based on my 2 requirements i.e. scheduled vs continuous.
Sorry for any confusion.
Writing your own scheduler is not as trivial as it may seem to be. With that in mind, there are only two reliable options: use Quartz.NET (which is what I personally recommend) or use Windows Scheduler.
Quartz.NET has somewhat of a learning curve (not very steep, though), and Windows Scheduler (if interfaced with using TSMW) has, to my taste, a very cumbersome API.
Related
I did some research on this topic, but I am unable to find the expected answer for this. In my application I have used
ThreadPool.QueueUserWorkItem
Like following way.
ThreadPool.QueueUserWorkItem(o => CaseBll.SendEmailNotificationForCaseUpdate(currentCase, caseUpdate));
My app in asp.net mvc & I have handled all background task which is not required to execute on user operation for faster execution & quick user response.
Now I wants to know that, Is there any bad side of using ThreadPool.QueueUserWorkItem When we have larger audience for application.
No, you should never use it. I can write a lot of reasons why but instead you should read this article from Scott Hansleman who is a genius IMHO
http://www.hanselman.com/blog/ChecklistWhatNOTToDoInASPNET.aspx
Under "Reliability and Performance":
Fire-and-Forget Work - Avoid using ThreadPool.QueueUserWorkItem as your app pool could disappear at any time. Move this work outside or use WebBackgrounder if you must.
So, as recommended, don't use ThreadPool.QueueUserWorkItem. An excellent alternative for this is at:
https://www.asp.net/aspnet/overview/web-development-best-practices/what-not-to-do-in-aspnet-and-what-to-do-instead#fire
Edit: As mentioned by #Scott-Chamberlain, here's a better link:
http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx
It really depends on what you are going to be doing but generally speaking, your likely concerns will be:
Persistence. Threads in the managed pool are background threads. They will die when the application recycles which is generally undesirable. In your case you want to send e-mails. Imagine if your process dies for some reason before the thread executes. Your e-mail will never be sent.
Local storage is shared, which means you need to make sure there are no leftovers from the last thread if using it. Applies to fields marked with ThreadStaticAttribute as well.
I would instead recommend that you implement a job scheme where you schedule the job somewhere and have some other component actually read from this list (e.g. database) and perform the job, then mark it as complete. That way it persists across application unload, there is no memory reuse and you can throttle the performance. You could implement the processing component inside your application or even as a Windows service if you prefer.
I've got a windows service with only two methods - one private method DoWork(), and an exposed method which calls DoWork method. I want to achieve the following:
Windows service runs DoWork() method every 6 hours
An external program can also invoke the exposed method which calls DoWork() method. If the service is already running that method called from the service, DoWork() will again be invoked after the current method ends.
What's the best approach to this problem? Thanks!
An alternative approach would be to make use of a console application which can be scheduled by Windows task scheduler to run every 6 hours. In that case you don't waste resources to keep the Windows service running the entire time but only consume resources when needed.
For your second question: when you take the console app approach you can have it called by making use of Process.Start for example.
If the purpose of your application is only to run a specific task every six hours, you might be better off creating a command line application and creating a scheduled task that Windows runs automatically. Obviously, you could then manually start this application.
If you're still convinced you need a service (and honestly, from what I've seen so far, it sounds like you don't), you should look into using a Timer, but choose your timer carefully and read this article to get a better understanding of the timers built into .NET (Hint: Pay close attention to System.Timers.Timer).
To prevent reentry if another method tries to call DoWork() while the process is in the middle of performing its operation, look into using either a Mutex or a Semaphore.
there are benefits and drawbacks either way. my inclination with those options is to choose the windows service because it makes your deployment easier. scheduling things with the windows task scheduler is scriptable and can be automated for deployment to a new machine/environment, but it's still a little more nonstandard than just deploying and installing a windows service. you also need to make sure with task scheduler it is running under an account that can make the webservice call and that you aren't going to have problems with passwords expiring and your scheduled tasks suddenly not running. with a windows service, though, you need to have some sort of checking in place to make sure it is always running and that if it restarts that you don't lose hte state that lets it know when it should run next.
another option you could consider is using nservicebus sagas. sagas are really intended for more than just scheduling tasks (they persist state for workflow type processes that last for more than the duration of a single request/message), but they have a nice way of handling periodic or time-based processes (which is a big part of long running workflows). in that a saga can request that it get back a message from a timeout manager at a time it requests. using nservicebus is a bigger architectural question and probably well beyond the scope of what you are asking here, but sagas have become how i think about periodic processes and it comes with the added benefit of being able to manage some persistent state for your process (which may or may not be a concern) and gives you a reason to think about some architectural questions that perhaps you haven't considered before.
you can create a console application for your purpose. You can schedule the application to run every 6 hours. The console will have a default method called on application start. you can call your routine from this method. Hope this helps!!
I'm trying to find a very easy easy way to start a simple cron job for my Web Application. What I was thinking about is starting a Task in the Application_Start event. This task will have a while loop and do some action every hour or so like a normal cron job would do.
Is this a good idea or will this give some trouble?
Some of the problems I could think of are the following:
The Task suddenly stops working or hangs. Maybe make some fail over
mechanism that would check if the task is still running and if not
restart it.
Memory leaking if the Task totally goes wrong and I have to restart
the whole application.
No control in changing the Task on the fly but this shouldn't be a
problem for the thing I want to do but for others it might be.
Does someone have any suggestions or experiences with trying this?
Although Darin says that doing cron jobs in a web application is a bad idea (and I agree with him in some way), it may be not so bad, when used wisely and for short running jobs.
Using same Quartz.NET in web application may be quite nice, I'm using in one of my projects like this
http://bugsquash.blogspot.com/2010/06/embeddable-quartznet-web-consoles.html for small jobs and it is running nice - it's easy to monitor (easier than monitoring remote windows process), may be used on shared hosting.
Doing cron jobs in a web application is a bad idea. IIS could recycle the application at any time and your job will stop. I would recommend you performing this in a separate windows service. You could take a look at Quartz.NET. Another possibility is a console application which does the job and which is scheduled within the Windows Scheduler.
I am trying to write a program in C# that will connect to around 400 computers and retrieve some information, lets say it retrieves the list of web services running on each computer.
I am assuming I need a well threaded application to be able to retrieve info from such a huge number of servers really quick. I am pretty blank on how to start working on this, can you guys give me a head start as to how to begin!
Thanks!
I see no reason why you should use threading in your main logic. Use asynchronous APIs and schedule their callback to the main thread. That way you get the benefits of asynchrony, but without most of the difficulty related to threading.
You'll only need multithreading in your logic code if the work you need to do on the data is that expensive. And even then you usually can get aways with parallelizing using side effect free functions.
Take a look at the Task Parallel Library.
Speficically Data Parallelism.
You could also use PLINQ if you wanted.
You should also execute the threads parallely on a multi-core CPU to enhance performance.
My favourite references on the topic are given below -
http://www.albahari.com/threading/
http://www.codeproject.com/KB/Parallel_Programming/NET4ParallelIntro.aspx
Where and how do you get the list of those 400 servers to query?
how often do you need to do this?
you could use a windows service or schedule a task which invoke your software and in it you could do a foreach element in the server list and start a call to such server in a different thread using thread queue/pool, but there is a maximum so you won't start 400 threads all together anyway.
describe a bit better your solution and we see what you can do :)
Take a look at this library: Task Parallel Library. You can make efficient use of your system resources and manage your work easier than managing your threads directly.
There might be considerable impact on the server side when you start query all 400 computers. But you can take a look at Parallel LINQ (PLINQ), where you can limit the degree of parallelism.
You can also use thread pooling for this matter, e.g. a Task class.
Createing manual threads may not be a good idea, as they are not highly reusable and take quite a lot of memory/CPU to be created
I'm writing a small app that needs to be executed once a week.
I could write it as a service that runs constantly but only executes the task that I need it to once a week, but that seems like overkill.
Is there another way of executing an application once every x period of time?
I'm looking for a solution that doesn't involve user interaction.
You can always use Windows Scheduled Tasks. They can be ugly, but effective.
You could use the Windows Task Scheduler. It was designed with this scenario in mind.
You can use Windows Scheduler for planning execute app once a week.
Under windows you can use the at utility.
You can use the Windows Task Scheduler in the Control Panel. Just set up a task to run your application on the specified day. You can even tell it to run as a certain user if you want.
If you need full control on the process (result values, parameters to be provided, etc), I would suggest you to create your own task scheduler, where you can use the cron algorithm to schedule the time you want execute your task.
I know it may sounds overkill to create a service to run once a week, but if you make a generic scheduler, you will be able to reuse your schedule for other purposes.
I created this scheduler in the past, and it has been used for years in production. I implemented the cron algorithm in .Net, based in the open source algorithm that one developer (Artif Aziz) wrote. Check out my blog for more information on this:
CronTab schedule parser algorithm
If you think in a higher level (enterprise level), you could consider buying Control-M, one of the most powerful scheduler tools I have ever used, however it is quite expensive.
Cheers!
Roberto.