Looks good. I prefer option #2. - Dave
On 10/13/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
I already got the new clustered tasks code committed and working, but one other thing I want to do before considering this finished is to update the way tasks are configured to provide greater flexibility. Right now we only have "tasks.daily" and "tasks.hourly" and that mostly suits our needs, but what I would like to do is replace those with something like this ... task.<taskname>.<prop>=<value> so that like the caching config, any number of properties could be configured to be provided to a given task. the properties that would then be expected/built-in would be ... class=org.apache.roller.MyTask startTime=immediate|startOfHour|startOfDay interval=60 (minutes between runs) leaseTime=10 (minutes task can be leased for) this should provide a semi-cron like ability to have more control over how tasks are started and run. this way not only can a user tweak how a certain task is run if needed, but they can also easily define their own custom tasks and plug them in if they want to. i think all of this is pretty straight forward, but the one part that could use some opinions is how to determine which tasks should be started based on the configuration. i see 2 options ... 1. just start any task that is configured. i.e. find all properties that start with task.*.class and try to instantiate and schedule them to run. this is easy to do, but means that to disable a class you need to comment out its properties. 2. provide a config prop which controls which tasks are enabled, like "tasks.enabled=<taskname>,<taskname>". this way the tasks are basically started by parsing that list and looking for props for each taskname, then trying to instantiate and schedule the task. this is kind of nice because you can leave the configs for tasks alone and just enable/disable them easily, however it could also be more confusing because you have to do 2 things to setup a task. any opinions? -- Allen
