 |
|
|
|
Have you set AllowMixedPriority in restore job resource, too? Does not look like a bug but more like a config isssue. |
|
|
Hello Maik, in the formerly attached config you'll find: (so yes, it is configured) # Standard Restore template, to be changed by Console program Job { Name = "Restore" Type = Restore FileSet = "empty" Client = fsrz-fd Pool = fsrz-DailyPool Messages = Standard Where = /mnt/local AllowMixedPriority = yes Priority = 9 } |
|
|
I suggest to first reproduce this with a minimal configuration to mitigate side effects. It's hard to try to analyse this remotely on a complex environment. This looks more like a support issue to me. |
|
|
The observed behaviour matches the documentation precisely. I'm the author of that patch, and I guess the bug is that I called the option "Allow Mixed Priority" instead of "Single Priority" (with default True to be backwards compatible). I'm sure a patch to implement the desired behaviour would be accepted, although I have no good idea for what to call the new directive. Perhaps an additional value "Allow Mixed Priority = loose" or something? Or perhaps even just change the behaviour - I doubt anyone *really* relies on it. I certainly don't do myself. Here's the documentation for reference: ''' Allow Mixed Priority = <yes|no> (default: no) When set to yes, this job may run even if lower priority jobs are already running. This means a high priority job will not have to wait for other jobs to finish before starting. The scheduler will only mix priorities when all running jobs have this set to true. Note that only higher priority jobs will start early. Suppose the director will allow two concurrent jobs, and that two jobs with priority 10 are running, with two more in the queue. If a job with priority 5 is added to the queue, it will be run as soon as one of the running jobs finishes. However, new priority 10 jobs will not be run until the priority 5 job has finished. ''' |
|
|
As described the behaviour is as expected. I'm closing this issue, but please feel free to write a feature request. |
- Anonymous
