5

I've been using a single scheduler to handle all my scheduled tasks (Quartz.Net). I'm starting to rethink how this operates because if I need to update 1 task, I have to stop the entire process, release the update, and start it back up.

My Question: Is it better to have many Windows Services running individual tasks (or groups of similar tasks) or 1 Service running all of the tasks (my current set up)?

Improve this question
4
  • The only reason not to, other than clarity and ease of code maintenance into the future, would be that if any kind of conflict can arise from your 1..N schedulers all running their tasks simultaneously then you should not.
    – Patrick Hughes
    Commented Aug 2, 2013 at 17:19
  • I assume you mean "The only reason not to run as a single scheduler..."?
    – MattB
    Commented Aug 2, 2013 at 18:02
  • Is there any specific reason that you don't want to use the scheduler built into the server? It has become consistenly better with every NT/WServer release. msdn.microsoft.com/en-us/library/windows/desktop/…
    – TimG
    Commented Aug 19, 2013 at 12:36
  • Based on what I've read about the built in scheduler, I don't have the granularity of exactly when I want to run something (once a minute, etc.)
    – MattB
    Commented Aug 26, 2013 at 16:40

2 Answers 2

Reset to default
1

I've spent a bit of time recently with Quartz.NET, and I can share some of the experiences we had. My scenario covered a single process (windows service) that was responsible for updating the existing schedule (using details downloaded as XML from a server). The service process also covered most of the functionality that could be triggered.

I think the key factor here is what you mean by "updating" a task. Do you mean simply altering scheduling details (what tasks to run, when to run them etc), or the actual binaries involved in executing the task? If you're expecting frequent updates to binaries and features, then a single monolithic model is probably not right for you. If you are only expecting frequent updates to when and what task should run, then it's worth centralizing the management of the tasks and scheduling.

Trigger groups work nicely for dividing up and managing various job types. This makes the CRUD against the in memory schedule much cleaner. For example, you can get all the jobs in a group fairly easily

Improve this answer
0

I've never used Quartz.NET, but I thought it was set up to allow you to modify job configurations simply by editing a config file and/or dropping in a new DLL, and changes would be picked up immediately.

If that's not the case, then something like that seems like a good approach to me. For example, you can have a separate DLL for each job, with a class that implements a common interface. When a job is scheduled to fire, dynamically load the DLL, use reflection to retrieve an instance of the job, and execute it. So if you need to change a job, you'd simply drop a new DLL in, and the next time it picks it up, it will be the new code.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.