We were working with a customer running RPM Remote Print Manager® ("RPM") in a large network which included several hospitals. The problem they ran into occurred while their high capacity LPR printers were offline at night. RPM would fail to send the print job, so it would retry the job every so many minutes. This filled their log with "job retry" messages.
The problem of course is that if there were any other problem happening, it would be hard to track down due to the volume of similar messages.
RPM already includes a device tester. We determined that the first step was to improve the procedure for testing the LPR printer. If it's not available, then test periodically until it is available.
How we fixed the problem
First we worked with the LPR testing logic. Instead of merely "pinging" the device to see if we could find it on the network, we now connect to it and send a "print status" request. If we can connect, and send, and get a response, we deem the device "available". Otherwise we'll schedule a new attempt.
Similarly, if you are printing to an IP printer, we try to connect to the printer (usually on port 9100).
Next, we added logic to the job scheduler to handle "device verified" and "device recovered" events. In both cases we search for any jobs which depend on that device, and make them eligible.
We also verified that other device failures are now handled more completely. For instance, let's say you are archiving files to a folder, and for some reason that folder is not available. As soon as the folder is available again RPM schedules the archive jobs automatically. We tested this by renaming the folder and sending print jobs to it. Shortly after we restored the folder name, the jobs started to process.
We also tested printer names, filter action executable paths, and other action types.
Starting with version 220.127.116.110 available April 26, 2017, RPM will process jobs after a device is back online on its own. You might not even be aware the problem ever took place.