RPM As a Print Spooler
A print spooler has one real job, broken into three parts:
- receive jobs as fast as they’re sent
- store them safely
- finally, process them out-of-band.
RPM is built around that priority order, in that sequence.
Receiving Comes First
RPM Remote Print Manager® (“RPM”) gives top priority to accepting incoming network traffic and responding immediately. When testing with tens of thousands of jobs sent in a burst, you can watch thousands of jobs pile into a queue in the RPM user interface while earlier jobs are still processing — the network thread never blocks waiting on processing to catch up. RPM maintains a temporary storage area for files while jobs are being written to the database, so nothing is at risk during that window either.
In short: loss prevention comes first, and everything else is optimization on top of that.
How a Job Actually Gets Spooled
Under the hood, an incoming job moves through a few concrete steps:
- The protocol layer writes the job data to a folder. Every queue has its own folder, so data from different queues never mixes. RPM knows which queue to use because LPD jobs specify the queue directly, and every other protocol has its own queue configuration.
- Job metadata is written to a separate “jobs” folder. Each protocol uses its own naming convention here — LPD jobs are tagged distinctly from Telnet jobs, and so on — so metadata can be traced back to its source.
- A dedicated thread per protocol scans that jobs folder, finds newly staged jobs, and registers them in the database.
- The scheduler later searches the database for the next eligible job to process — a separate concern from spooling, and one covered in depth on its own page.
The practical effect of this design: receiving and processing are genuinely decoupled. A slow or backed-up action (like a printer that’s offline) never causes RPM to fall behind on accepting new jobs.
Why This Matters
Most environments don’t need to think about spooler internals — until the day a printer goes offline mid-batch, or a burst of a few thousand jobs arrives at once. RPM’s separation between “accept fast” and “process safely” means those situations degrade gracefully: jobs queue up, nothing gets lost, and processing catches up once the printer (or downstream system) is available again.
Please contact our sales and technical support if you are interested in more information about RPM.