There's an open issue: http://jira.opensymphony.com/browse/QRTZNET-40
, which is about console but could be a service as well. I'm not sure
whether it should be a separate Cookbook page on the website with
these commonly needed things on a copy-paste form. Introducing two new
visual studio projects for couple of small code files doesn't seem
right to me.
I'm open to all ideas,
-Marko
On Jan 31, 2008 10:57 AM, christo...@gmail.com
* add a Windows service based on the Quartz.NET library to the project
* provide it as a separate binary download w install instructions (or
setup) for those that need a .NET based scheduler service
* make it so that it can be installed with different service names (so
project A can ship its preconfigured scheduler, project B do the same
and both operate in separate process spaces). That way installation
and usage is painless.
What you get from this is additional visibility for the project
because lots of people are looking for easy scheduling solutions, and
having a supported service built by the library team surely builds
credibility for the solution.
Chris
(I am the PM of SharpDevelop, however, this inquiry is unrelated to our project)
* Quartz
* Examples
* Tests
For most of people this is naturally common sense as this structure is
being used in many projects. In examples directory we can have the old
Quartz.Examples and add Quartz.WindowsService which will contain the
needed functionality. I'm not sure whether we need command line
version. If Windows service will come in compiled form in distribution
I think that will solve the issue. Examples and service will come part
of a new solution file and we'll then have Quartz.sln (all projects),
Quartz.Core.sln (just Quartz and tests) and Quartz.Examples.sln.
Hopefully we will have Quartz web app console (ASP.NET MVC) also like
Java Quartz doe in Quartz.Web.sln some day.
Opinions?
-Marko
Chris
Chris thanks for your input on the matter!
-Marko
CS has a nice way of specifying jobs (I stripped the configuration
down to make it more readable):
<Tasks>
<Modules>
<add name="CSTaskModule"
type="CommunityServer.Components.CSTaskModule,
CommunityServer.Components" />
</Modules>
<Threads>
<Thread minutes="15">
<task name = "SiteStatisticsUpdates" type =
"CommunityServer.Components.SiteStatisticsJob,
CommunityServer.Components" enabled = "true" enableShutDown = "false"
/>
</Thread>
<Thread minutes="5">
<task name = "Emails" type =
"CommunityServer.MailRoom.Components.EmailJob,
CommunityServer.MailGateway.MailRoom" enabled = "true" enableShutDown
= "false" failureInterval = "1" numberOfTries = "10" />
</Thread>
<Thread minutes="15">
<task name = "FeedUpdater" type =
"CommunityServer.Reader.Components.FeedUpdater,
CommunityServer.Reader" enabled = "true" enableShutDown = "true" />
</Thread>
</Threads>
</Tasks>
Jobs are grouped by times they need to be run, which is (for my
purposes) a very good way of organizing repeating tasks (as compared
to having a start time & repeat interval on the job).
Chris
I've also fixed a small issue,
http://jira.opensymphony.com/browse/QRTZNET-90 (you can argue whether
it's an improvement or a bug fix). You don't restate the job name and
group in trigger anymore (I think this is old burden from Java
version's Digester based implementation, should have examined it more
carefully). So now you can have your "every five minutes" trigger
described as "short" as:
<job>
<job-detail>
<name>noOp</name>
<group>noOpGroup</group>
<job-type>Quartz.Job.NoOpJob, Quartz</job-type>
</job-detail>
<trigger>
<cron>
<name>everyFiveMinutes</name>
<group>cronTriggers</group>
<cron-expression>* 0/5 * * * ?</cron-expression>
</cron>
</trigger>
</job>
If you are not using latest from the trunk, you also need to set
jobName and jobGrop for the trigger. Yes, it is verbose, too verbose
:-)
-Marko
I've committed first version of the scheduler service / console server
to Quartz.NET Subversion trunk. It would be super helpful if someone
on the list would have some time to give it a whirl. Currently I think
that I have already created solution that removes the need for repeat
the basic server coding process but solution is still really bare
bones. So what features would you expect from this server besides the
basic XML based configuration?
Cheers,
-Marko
So a very useful would be that the schedulersvc.exe "learns" its
service name from schedulersvc.exe.config. That way it would be
super-easy to have multiple schedulers from multiple applications on
the same machine without clashes.
Chris
CCNET ships with a service exe as well as a cmd line exe for the build
agent. The former is the "real" service, the latter is a command line
application for interactively debugging the build configuration. I
think this feature would be very valuable to copy.
Chris
easiest way to administer a running scheduler is to export it via
remoting. Current Subversion trunk exports it (see the App.config).
-Marko