When many jobs start at the same time -- for example, a batch of daily jobs all triggering at midnight -- the scheduling backend can become overloaded. SchedulerX provides application-level throttling to prevent this by limiting how many jobs run simultaneously. Jobs that exceed the concurrency limit wait in a queue instead of being discarded. You can also assign priorities to queued jobs so that higher-priority jobs run first when a slot becomes available.
Job priority settings apply only within a single application. They do not affect scheduling in other applications.
When to use application-level throttling
Use application-level throttling when your workload has burst peaks -- for example, hundreds of daily jobs with the same start time. The queue mechanism spaces out job execution to prevent the backend from being overwhelmed.
| Scenario | Recommendation |
|---|---|
| Burst peaks (many jobs start at the same time) | Use application-level throttling with or without priority queues |
| Sustained high-frequency load (minute-level jobs) | Use client-side throttling or scale the client's processing capacity instead |
Throttling and priority queues are designed for burst-peak scenarios. A queue under sustained load leads to buildup rather than smooth execution.
Set up concurrency throttling
Concurrency throttling limits the number of jobs that run at the same time for an application. When the limit is reached, new jobs enter a waiting queue.
Step 1: Enable flow control
In the SchedulerX console, create or edit an application group. For details, see Create an application group.
In the Advanced Configuration section, turn on Flow Control. This toggle is off by default.
Set Number of concurrent task instances to the maximum number of jobs that can run simultaneously.
Step 2: Verify the queue behavior
Create three jobs in the application group (for example, hello_jobA, hello_jobB, and hello_jobC).
Click Run once in the Operation column for each job to trigger them.
In the left-side navigation pane, click Instances. On the Task instance List tab, verify that:
hello_jobA is running.
hello_jobB and hello_jobC are waiting in the pool.
After hello_jobA completes, hello_jobB enters the execution queue.
The concurrency limit is enforced: excess jobs queue up rather than running simultaneously or being dropped.
Add priority-based preemption
Priority-based preemption builds on concurrency throttling. Each job gets a priority level (high, medium, or low). When a queue slot opens, the highest-priority waiting job runs next, regardless of submission order.
The concept is similar to how Yet Another Resource Negotiator (YARN) isolates resources for jobs with different priorities:
Step 1: Assign priorities to jobs
When creating or editing a job, set the priority level to high, medium, or low.
Step 2: Test preemption behavior
To observe how priority preemption works, enable throttling for the application (for example, dts-all.hxm) and set Number of concurrent task instances to 1 so that only one job runs at a time. Then create three jobs with different priorities:
| Job | Priority |
|---|---|
| Job A | Medium |
| Job B | Low |
| Job C | High |
Trigger the jobs in this order: medium, low, high.
Expected result:
Job A (medium) starts immediately because no other job is running.
Job B (low) and Job C (high) enter the queue.
After Job A completes, one slot opens. Job C (high) runs next because it has higher priority than Job B (low).
Job B (low) runs last.
When a slot opens, the highest-priority job runs next -- not the one submitted first.
Constraints and behavior
| Constraint | Detail |
|---|---|
| Priority scope | Priorities apply within a single application only. Setting a high priority on your jobs does not cause them to run before jobs in other applications. |
| Queue behavior under sustained load | The queue mechanism works for burst peaks. For sustained high-frequency workloads, the queue builds up faster than it drains. Use client-side throttling or scale the client's processing capacity for minute-level jobs. |
FAQ
Can I use job priorities to run my jobs before jobs in other applications?
No. Job priorities are scoped to a single application. A high-priority job in your application does not affect scheduling in other applications.
Should I use throttling for minute-level jobs?
Throttling and queue-based scheduling work for burst peaks where many jobs start at the same time. For minute-level jobs with sustained high throughput, the queue can back up faster than it drains. In that case, throttle on the client side or scale up the client's processing capacity.