Okay, since nobody else seems to have an opinion, then what I plan to
commit next is a fix for the time drifting problem with the leasing
process and a custom scheduler. Here's a few details ...
1. To fix the problem with the time drifting in the leasing process I've
changed the logic for the task running so that we keep track of a last
run time for each task and base the next allowed run time on that date.
So effectively, the time involved in the leasing process does not
affect the scheduling for tasks.
2. To fix the problem with tasks mysteriously running at the wrong time
or failing to run for unexplained reasons I've created a custom
scheduler. It's a fairly simple class which gets run on its own thread
and once per minute it wakes up, checks if any tasks need to be
launched, then goes back to sleep until the next minute. It also
contains a couple bits of custom logic which is more unique to our task
running process.
I haven't done anything to push the task configuration and controls into
the db yet, so I am still deciding on that. I still think it's the best
thing to do, it's just a matter if if I have time to do it.
-- Allen
Dave wrote:
On 7/23/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
So that's all the issues and a summary of proposed solutions. My
feeling is that #1 is critical and has to be fixed for 4.0 somehow, #2
is a good thing that I'd like to see but I think we could technically do
without it, #3 is nice but if I could avoid doing it I would, and #4 is
critical and has to be fixed for 4.0.
Thoughts? Comments? Opinions?
I am trying to wrap up 4.0 work ASAP so please respond as soon as
possible because I am already beginning to work on these things.
I wish I could help more, but I'm not familiar enough with the
scheduled task subsystem to really make an intelligent comment at this
time.
If you need to make database and UI changes to address this problem,
I'm +1 -- this is a critical feature for folks using the planet
subsystem.
- Dave
