I'm in the process of reworking the scheduler service. In doing so, I'm
looking at
the need to run each scheduled job in it's own thread.
Under the current design, a job is rescheduled to run based upon the
reoccuring time it's scheduled to run and the time it takes to complete.
The run queue is sorted and prioritized by this factor. The possible
problem
with this is that a long running task can force other jobs to run late
waiting on
a job to complete.
If I change this to run each job in it's own thread, then the queue will
be independent
of the time it takes an individual task to run. So, a task is scheduled
to run again regardless
of the time it takes to complete and the scheduler can (in theory) run
each job on time.
However by doing this, it makes the scheduler function more complex.
Because now the
service needs some type of a callback to update the queue and it would
be possible for
the scheduler to launch the task to run again even it's not finished
from it's previous
execution. For example, in the case that a run again time < time to
complete. This can
be solved by setting some type of state check or priority on the job but
this adds complexity
to the service.
So my question is: What's more important to you? Can we live with a job
(possibly)
running a little late; or is the importance of this service worth the
complexity of seperate thread
per job?
I'm open to suggestions.
dave
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
