#10 Scheduler behavior is not clearly defined.
IVC-Version : 1.0
Plugin : Scheduler
Plugin Version : 1.0
Problem:
Scheduler has inconsistent/undefined behavior.
Reason:
IVC scheduler spec is vague and does not provide
sufficient detail.
Resolution:
The following changes to the spec are proposed:
Legend:
Current : Current behavior
Change : Modified behavior.
String : Indicates a string value that should appear
exactly as specified in the GUI.
1. Adding new algorithms to scheduler:
Current: Selecting an algorithm from the menu by
default adds it to the scheduler and runs it
immediately. No time is associated with this scheduler.
Change: The scheduler should export a preference that
allows users to choose the default behavior for running
new algorithms. There are two values: 1. Schedule
automatically 2. Schedule manually. The two options
should be mutually exclusive.
1.1 Schedule automatically: (default) If this is
selected, selecting an algorithm from the menu by
default should schedule the algorithm using the current
time of selecting from the menu.
1.2 Schedule manually: If this is selected,
selecting an algorithm brings up the scheduling dialog
box which the user can use to select the exact date and
time for scheduling this algorithm. This preference
should have two sub-preferences that offer a choice of
Default Value: 1. Schedule immediately 2. Schedule
last. These choices are mutually exclusive.
1.2.1 Schedule immediately: (default) If this is
selected, the default date and time in the scheduler
dialog box is set to the date and time at which the
user selected the algorithm.
1.2.2 Schedule last: If this is selected, then the
scheduler picks up the last value in the schedule,
increments it by one second and sets that as the
default value.
2. Max simultaneous algorithms is a hard limit:
Current: Max simultaneous algorithms is a hard limit
and cannot be overridden at runtime.
Change: The scheduler should be allowed to override
this limit if the user so desires.
2.1 No limit: The scheduler needs an additional
preference that allows the user to specify whether the
max simultaneous algorithms is a hard or soft limit.
The No limit preference, when selected allows the
scheduler to run algorithms as they come with no limit
on the number of simultaneously runnable algorithms. A
warning should be shown to the user (using a label, not
a dialog box or anything invasive) that informs the
user that this will cause algorithms to be run as they
come, possibly hogging too much memory and CPU and
making the computer really slow. NOTE: Selecting this
should disable changing the max simultaneous algorithms
preference which means the logic outlined in section 3.
should not come into play.
3. Max simultaneous algorithms cannot be changed at
runtime.
Current: The Maximum simultaneous algorithms
preference cannot be changed at runtime, i.e. it
requires restart whenever changed.
Change: This value should be changeable while the
scheduler is running because there is no reason for
requiring a restart if we assume some simple things:
3.1 Assumptions:
3.1.1 The change of this value can be communicated to
the scheduler in a thread-safe manner.
3.1.2 The scheduler cannot stop running algorithms in
a reliable manner.
3.2 Scenarios: (numCur = number of currently running
algorithms, numMax = max simultaneous algorithms limit)
3.2.1 numMax becomes less than equal to (<=) numCur:
When user brings down numMax below numCur, the
scheduler should continue to run the algorithms that
are already running and not run any new algorithms
until numCur becomes lower than numMax.
3.2.1 numMax becomes higher than (>) numCur: The
scheduler reacts to this change the runs the next
algorithm scheduled to be run, if such an algorithm is
available.
4. Max simultaneous algorithms cannot be less than or
equal to zero.
Current: The Maximum simultaneous algorithms
preference can currently be set to a negative value.
(!!) Also, setting the value to zero gives no
indication of error. Rather, when the IVC is restarted,
it silently sets the value to the default of 4.
Change: This preference cannot be less than 1. Also any
value lower than 1 should be considered invalid and
this should be made apparent to the user. The IVC
should not silently use the default value of 4.
Logged In: YES
user_id=1068192
1.2.1&2 could just as easily be a part of 1.1.. Perhaps it
should go like this:
[_] Schedule automatically
Schedule automatically in this part of the queue:
[[Beginning][End]]
[_] Schedule manually
Fill in schedule tiem from this part of the queue:
[[Beginning][End]]
Probably needs better wording...
Other than that, everything else seems fine.
Logged In: YES
user_id=1061200
Agree. So basically the choices we have are:
- Scheduler Automatically
-- Scheduler First
-- Schedule Last
- Schedule Manually
-- Default:
-- Schedule First
-- Schedule Last
However, all of these are GUI related so I think we should move these
to a different 'bug'.