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.
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 am looking to write a Windows Service that will start various "jobs".
Each "job" will:
be distinct in what it accomplishes
run for the lifetime of the Service, so "long running". Typically, a job will get 10 tasks from the database and process them, then sleep, and then repeat this cycle again and again.
Share the same "context". The application will be loosely coupled and call an IoC to get classes. It will also store some data on this context too
I need each job to be able to run in parallel and effectively run as separate programs.
My first thought was to create one thread per job. This is okay but has the drawback that a ManualResetEvent stops the thread in its tracks, and the Abort doesn't allow much chance for the Thread to exit in a graceful manner.
I then explored some of the new async framework in .NET 4.5 and boy does it seem to simplify coding.
However, whilst some of the data held on the context may be freely shared between each job, some can not: so each job requires it's own copy of certain data.
I attempted to solve this using ThreadLocal<T> properties. However, whilst this works fine for a specific thread that I've created, this doesn't work for the async methods. The thread that starts an async method is often not the thread that finishes the method, particularly when the method uses "await".
So, what is the preferred pattern for what I am attempting to accomplish?
FYI: Albahari's posting was a great help.
I currently have an application which is basically a wrapper for ~10 "LongRunning" Tasks. Each thread should keep running indefinitely, but sometimes they lock up or crash, and sometimes the wrapper app spontaneously exits (I haven't been able to track that down yet). Additionally, the wrapper application can currently only be running for one user, and that user has to be the one to restart the threads or relaunch the whole app.
I currently have a monitor utility to let me know when the threads stop doing work so that they can be manually restarted, but I'd like to automatically restart them instead. I'd also like the wrapper to be available to everyone to check the status of the threads, and for the threads to be running even when the wrapper isn't.
Based on these goals, I think I want to separate the threads into a Windows Service, and convert the wrapper into something which can just connect to the service to check its status and manipulate it.
How would I go about doing this? Is this a reasonable architecture? Should I turn each thread into a separate service, or should I have a single multi-threaded service?
Edit: All the tasks log to the same set of output files (via a TextWriter.Synchronized(StreamWriter)), and I would want to maintain that behavior.
They also all currently share the same database connection, which means I need to get them all to agree to close the connection at the same time when it's necessary. However, if they were split up they could each use their own database connection, and I wouldn't need to worry about synchronizing that. I actually suspect that this step is one of the current failure points, so splitting it up would be a Good Thing.
I would suggest you to stay inside one multithreading service if possible. Just make sure that threads are handled correctly when Service Stop is triggered. Put brake flags inside blocks of code that will take a lot of time to execute. This way you will make your service responsive on Stop event. Log any exceptions and make sure to wait for all threads to exit until service is finally stopped. This will prevent you to run same "task" in multiple threads.
Maintaining one service is in the end easier then multiple services.
Splitting to multiple services would be reasonable if you require some separate functionalities that can run or not beside each other.
I don't think moving the threads to a Windows Service removes any of the problems. The service will still crash randomly and the threads will still exit randomly.
I assume that your long-running tasks implement a kind of worker loop. Wrap the body of that loop in a try-catch and log all exceptions. Don't rethrow them so that the task does not ever exit. Examine the logs to find the bugs.
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
I'm creating a win service that monitors ftp logs, when a file has been uploaded I want to start an external application, like a powershell script, to do stuff with the file. my Question is do i want to spin this off into another thread when i do it or should I just wait until it finishes before moving on.
This process is already going to be in a thread (the service is going to be monitoring multiple servers) and the idea of threads starting threads worries me. Is this something to be worried about or is this a case of too much tinfoil in my hat.
Well, code it in a modular fashion and don't worry about threads. If, down the road, you find that your application will benefit from a multi-threaded approach then address it then. If you have build your components orthogonally then the threading part will fit more naturally.
Addressing threading concerns at the very beginning of an application always feel like premature optimization to me. Build the components first and worry about how to thread them later.
[Edit] I am in no way advising you to not think about threading at all. Every component needs to be build with the potential for use by multiple threads - this is a defensive and intelligent practice in all applications. What I meant was don't worry so much about how the application will handle threads and how to set up the thread management of the application first.
I think the more important question is what do you get out of spawning another thread? If you don't need to have the code execute in parallel, then don't do it. If you do, there should be no problem. If you are concerned with the child thread creating its own thread, then delegate the thread creation to the ThreadPool.
The primary question: do you need to know the outcome of that process? If you can fire and forget, then do that - it's easier. If you need the outcome, then wait for it.
Also, have you considered using the FileSystemWatcher? It works remotely.
Although somewhat off-topic, since you mentioned that you'll be launching a powershell script, I wanted to point out the option to run the script in-process via a powershell "runspace". Here's a minimal example:
using System.Management.Automation;
static class PoshExec
{
static void Exec(string scriptFilePath)
{
(new RunspaceInvoke()).Invoke("& " + scriptFilePath);
}
}
add a reference to
c:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0\System.Management.Automation.dll