how to run different tasks in different process?
in my case I will have 2 tasks one runs every 1 mint the other will run every 10 mints
the point is each one is totally independent from the other
how to make them work within the same program?
The way I'd do it is to create a Windows Service that contains a Timer. The Timer checks at regular intervals if it is time to run each process, and when it is time to run starts each process using either
The ThreadPool class (if that's what I think you meant by different processes)
A new Process itself. You will have to have each function that needs to run compiled into a seperate executable and then you simply start it using this class.
Hope that helps!
Related
In current project, I'm using task scheduler to run a console application to perform some daily operations. Now, I am thinking to use the same console application for another operation that needed to be run every 15 minutes. To identify the operation in same console application, I'm planning to use different arguments. e.g.
MyProject.Services.exe "RunDailyTask"
MyProject.Services.exe "RunEvery15MinutesTask"
So, both schedulers will call the same exe but with different arguments to peform different operations.
My question is, will this be a good idea? Can one operation affect the other as both are sharing the same exe?
My question is, will this be a good idea? Can one operation affect the
other as both are sharing the same exe?
No, Console exe is executed in separate process. when you run multiple instances of the same exe application each of these instances are executed in it's on process.
If an instance fails, only that process is affected; applications in other processes continue to perform. Of course, because memory addresses in one process have no meaning in another process
You could simple test this by manually running two instances of your console application(by hard coding RunDailyTask and RunEvery15MinutesTask in each exe)
Also instead of passing string arguments to console it would be preferable to use number flags(1,2) within the executable you could use enumerations with meaningful values if needed.
enum OperationType
{
RunDailyTask = 1,
RunEvery15MinutesTask = 2
}
yes. good idea.
no. Can one operation affect the other as both are sharing the same exe?
windows run your applications by different instance (thread). of course you must be sure when RunEvery15MinutesTask must be finish its job before start RunDailyTask.
I have a console application which should periodically listen remote database,
if there is a new value then do some stuff.
Normally I create windows task scheduler job to run this console app every 2 minutes.
Another option I think, in console app I will have a code like;
while(true)
{
ConnectDatabaseAndProcess();
System.Threading.Thread.Sleep(120000);
}
So I assume console app will be always open, and will wait 2 minutes for every process and continue.
In performance matter will it make any difference?
Unless your computer is so overloaded that the time to create a process every two minutes is a huge drain on resources, there's no benefit to having your program sitting in a loop waiting for two minutes, just so that it can poll the database.
The benefit of using scheduled tasks is that you can change the scheduled task frequency (make it once every five minutes, or once an hour, or whatever) without having to modify the program. Sure, you could use an application configuration file, but why? Why duplicate functionality that already exists in the operating system, and is more flexible.
Also, with a scheduled task, you know that the program will start the polling operation again the next time the computer is rebooted. If you depend on the program to provide that delay, you have to either remember to start it every time, or put it in the startup task list.
Also, when the program is sitting there idle, it's occupying memory that could be used by other processes.
All told, using scheduled tasks is a much more flexible and robust solution. Any marginal performance gain (and we're talking, at most, one second) from having the program always running is far outweighed by the disadvantages.
I need to import different feeds at different times, and my plan is to set up separate scheduled tasks, i.e. one that runs weekly, one monthly and so on, with different arguments depending on which feeds should be run. My question is what the best practice is when doing that - should I check if the exe is still running for example? I know you can set up the scheduled task to queue up an instance if it's already running, but that only applies to the task and not the exe. I don't think it will be too process heavy, so it should be fine if several instances were running at the same time, but I'd just like to check in case I'm missing some obvious pitfalls.
Thanks,
Annelie
There won't be any issues with Task Scheduler. You can run the same executable in different tasks concurrently with no trouble.
There are potential issues in your application, of course. You'll want each separate instance to be writing to a different output file, or if they're using the same output file you'll need to synchronize access. Unless you're writing to a database, which will typically handle that synchronization for you.
One way to control a single instance of your application running is to use a Mutex. However, there shouldn't be any problem with just using the Task Scheduler for doing what you want - of course, this is all dependent on what your program is doing. You will have to handle synchronization depending on your program logic.
This question has some relevant information about using a Mutex for enforcing a single instance.
My issue is pretty simple.
I have an application that should be executed automatically once a day. I have no prior experience with this kind of scenario (some time ago I worked with IBM Control-M but guess that it is way more complete, complex and expensive =))
I thought about two possible solutions:
Creating a Task inside Windows Task Scheduler, which would execute the application;
Implement the application as a Window Service which would run 24/7, but only would perform the needed actions depending on the current time.
Which are the advantages/disadvantages of each approach?
Is there another way to do this?
Thanks in advance.
If it only executes once a day (or so) then just do it as a regular command line app that is executed by the windows task scheduler. Task scheduler already has all of the UI necessary to determine when to kick off the program, pass in parameters and anything else related to the scheduling of the task.
The only real reason to do this type of function as a windows service is if it needs higher execution resolution than once a minute. However, the main downside to a windows service is that you would have to manage the logic for how often/when to kick it off. Another one is that the app is always running, which leaves open the possibility for leaked memory if your code has issues.
On Unix/Linux you would use a cron job schedule a task to be executed. MS Windows' version is called the Task Scheduler and it is already a service that run 24/7 and performs the needed actions depending on the time.
Create a repeating task with the Task Scheduler to run your application. Creating, installing and configuring a service application is not exactly trivial. It's a much more involved process than creating a standard Forms or command line app and you don't need to do it anyway.
http://msdn.microsoft.com/en-us/magazine/cc164015.aspx
http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-csharp/70633/Waitable-Timer-in-C
Another library that might be of interest is Quartz.NET
This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
windows service vs scheduled task
Windows Service Vs Simple Program
I'm trying to create a program that runs periodically (say every 5 minutes), or have the program running and have it execute the function within it (every 5 minutes).
The program is to obtain data from a database when it's executed and then write this to (for now) say info.txt file (no sensitive stuff is contained in here). each time it writes to the file it should overwrite the existing info within the file.
The program should also be started automatically at windows start up. (thus no need to login on the machine and to execute the .exe [if it's a normal program and not a service])
In between the periods that it executes the program would have nothing to do.
Therefore, should I run this program as a Windows Service, or should I use the Task Scheduler to periodically start the program to do this?
My goal is for this program to run as smooth as possible without clogging up resources. (eg. it shouldn't need more than 5% of the cpu)
I hope my question was clear enough.
I would go with application that is triggered by task scheduler. Only thing that you need to worry about is to run single instance of your application.
You can set task to run under specific user account and to run even if user is not logged on. There are number of events that can trigger task star like "Windows start", "System Idle"...
Other advantage is: If something crashes you can set task scheduler to send you an email or alert you in number of ways. You can control "exit code" of your application and signal to task scheduler what's going on and what to do.
There are a lot of positive features that task scheduler offers but not many people are using them.
I would suggest a Windows Service for this. Might be a good idea to create both and compare what the resource usage is like anyway?
I would actually recommend going for both depending on the requirements of the task you wish to run. I generally build most functionality for scheduled services into a single class library and then wrap it in a console application to start with and for debugging. When satisfied I wrap it in a windows service and forget about it.
Considerations of using a console app:
Make sure you run it under system account if possible or you can put in a specific login under Run as in scheduler. This will ensure an interactive login is not required.
If having 2 instances of it running at the same time is a problem, make sure you name it clearly and check for an instance of it running in your main method and exit if it is. A windows service will avoid this issue.
Considerations of using a window service
Make sure you're educated on thread usage. Windows services will use less resources if managed properly, but can be tricky if it's new to you and end up leaking memory in timer based tasks.
..there's a lot more to consider, but code it right and you can start with one and move to the 2nd when you're confident about it.