How RPM Processes a Job
Every job in RPM lives inside a queue, and every queue carries three independent settings that determine whether a given job is eligible to run right now.
Queue States
- Enabled — By default, true. If you disable a queue, RPM stops accepting jobs for it entirely, as if the queue didn’t exist.
- Suspended — By default, false. A suspended queue still accepts jobs all day long, but nothing in it runs until you lift the suspension. This is a clean way to batch up a set of jobs and release them all at once.
- Holding — By default, false. When a job is added to a queue, it inherits whatever hold setting the queue currently has. This means you can resume a queue (not suspended) and still have jobs sit there until you manually clear the hold on each one — a manual but precise way to control exactly which jobs run, and in what order.
A queue only processes jobs when it is enabled, not suspended, and the individual job is not held.
Queues Can Appear on the Fly
When a print client sends a job to RPM over LPR, the queue name travels with the job. If RPM doesn’t recognize that queue name, it can create the queue automatically — which is genuinely useful when you’re standing up a new RPM instance and want queues to simply appear as jobs arrive, so you can decide processing rules after the fact.
The tradeoff: in environments with active security scanners, this same behavior means RPM can end up creating queues from random scanner traffic. We generally recommend turning off automatic queue creation once your initial setup is done.
What Happens Inside a Queue
A job is always processed in the context of its queue — meaning whatever transforms and actions that queue defines are the ones that apply, and no others.
If the queue has transforms configured:
- The job file’s contents are handed to the first transform.
- That transform’s output becomes the input to the next transform.
- This repeats until every transform in the sequence has run.
- The final action (or actions) receives either the transformed output, or the original job file contents if no transforms were configured.
Single action: if a queue has one or more transforms and one action, RPM pipes the data straight through the transforms into that action.
Multiple actions: if a queue has transforms and multiple actions, RPM first resolves the transforms into a temporary file, then hands that same temp file to each action as the scheduler selects the job — so every action sees identical input.
The Scheduler: Picking the “Next Eligible Job”
RPM runs a configurable number of job-processing threads (adjustable in RPM Elite) that continuously look for the next eligible job — meaning the job isn’t held, its queue isn’t suspended, and its queue is enabled.
Among eligible jobs, RPM selects using one of four scheduling paradigms:
- Received order — based on the timestamp when the client first contacted RPM.
- Available order — based on when the job finished transferring completely. Large jobs can take noticeably longer to arrive than small ones, so this paradigm cares about the end of transmission, not the start.
- Balanced order — spreads processing evenly across queues and devices rather than favoring whichever queue happens to be busiest.
- Priority system — you assign numerical priority values to queues, devices, and actions directly, and RPM honors that ranking.
Reprint on Failure
If an attempt to process a job fails — a printer that’s temporarily offline is the common case — RPM can reprint it: mark the job eligible again so the scheduler picks it up on the next pass, or after a configurable wait period. You control both the interval between reprint attempts and the maximum number of retries, so a transient outage doesn’t require anyone to intervene manually.