Decision criteria | Decision |
|---|
Job duration | Status |
|---|
| colour | Blue |
|---|
| title | Introduced in 22.3 |
|---|
|
| Job are catalogued as either SHORT or LONG SHORT or LONG jobs are processed by separate worker daemons
This criterium ensures SHORT jobs are not affected by very LONG running jobs
|
Chained jobs If another job belonging to the same workfow is already in the queue it’s priority is increased. | Status |
|---|
| colour | Blue |
|---|
| title | IMPROVED in 23.2 |
|---|
|
| If the first step of the workflow is already completed, then jobs from this workflow are prioritized This criterium ensures already active workflows are completed first 23.2 Chained is only applied after the first LONG job
|
User priority | Each workflow is configured with a priority based on how quickly a user expects it to be processed. The following levels exist, from highest to lowest: HIGH: a user interaction triggered this process (UI change is triggered by this process) ex. series_evaluation, media_evaluation
NORMAL: propagation
LOW: ingest and processes triggered by external systems
BACKGROUND: migrations and timers
|
Organization fairness | Status |
|---|
| colour | Blue |
|---|
| title | Introduced in 22222.2 |
|---|
|
| Organizations are prioritized in a round-robin based fashion. For example, if a job was processed for organization A, the priority for jobs belonging to org B are increased. The upside for this is that organizations with higher loads don’t suppress jobs of other organisations |
