What is 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 Remote Print Manager® (“RPM”) includes a spooler, which is built around that priority order, in that sequence.
The Microsoft Print Spooler
The Microsoft Print Spooler is one that many of us are probably familiar with, even if you don’t ever think about it. Your user community can work on documents all day long and print when ready. No one needs to “wait for the printer to be available” because everyone’s print job is likely to be handled correctly, without your pages being interleaved with someone else’s. Not only that, but your print jobs come out on the printer you selected, and not randomly on some other printer.
With RPM, our paradigm of printing is different than Microsoft’s because we use a variety of output actions to define printing, including but beyond sending data to a conventional print device. However, the concept of spooling applies equally across all our actions.
Receiving Comes First
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.
What you would use one for
Spooling is the plumbing; it is rarely why anyone installs a print server. The reasons people actually do are more specific: getting a PDF out of a host that only knows how to print, putting one invoice on four colors of paper, filing every job for compliance, or handing print data to a program that does something else with it entirely. What people do with RPM is that list.
Please contact our sales and technical support if you are interested in more information about RPM.