We posted update 220.127.116.115 for RPM Remote Print Manager® ("RPM") on October 2, 2018. All the details are in the RPM roadmap. Here we have a summary of the top items of interest.
If you have seen ENOUGH of those “boost::filesystem” errors ...
The biggest single thing in this update is our latest attempt to address the ”missing file” problem.
Here is a sample of the kind of log message you might see:
standard exception: boost::filesystem::file_size: The system cannot find the file specified:
This would be followed usually by a path in the spool folder, although it could be a file in a working directory when RPM was running a program on your behalf (the filter action).
Our usual suspect was the antivirus software on your system. We would ask people to exclude the RPM spool and temp folders from their antivirus scan. We even have a recent blog post called “Escaping the grip of antivirus” [/escaping-grip-antivirus]
Often this would work, but at times people would assure us they had no antivirus software.
The basic problem is this. When we create a file, either receiving a print job or at some stage in processing, we often need to use that file right away, within milliseconds or sooner. Sometimes Windows or the disk just doesn’t keep up. The file Windows reports missing is really there and it’s really not empty.
You can run your same RPM configuration on a different computer and never see this. It’s a baffling and frustrating problem.
What we’ve done is add a component that will wait for the file to exist, up to ten seconds, checking frequently but less frequently as time goes by. That should be plenty of time for Windows and the disk and who knows what to catch up.
We discovered that when RPM received an “lpq” or “lpstat” command, it logged a socket exception in the event log. However, the caller got all their job status data, and there was no real problem. We were able to clear this up.
When does my queue start to process?
RPM receives jobs in queues, as the LPD protocol describes. We don’t have a “default” action we use to process your jobs so we normally wait for the user to set up the queue. This includes adding at least one action.
When we create the queue we “suspend” it, that is we turn the suspend setting “on”. That way we don’t try to process jobs until you have a chance to configure the queue the way you want.
What we’ve done is add some logic to the user interface so that you add one or more actions to a queue that had none, we offer to toggle off the “suspend” setting for you so that jobs will start to process immediately.
It’s one more thing you don’t have to think about. I’ve wondered more than once why nothing was happening on a new queue, only to notice after a minute that it was still suspended.
Moving the database, local moves only
Having moved interstate in the last year, I can tell you it's a lot of work. Moving the RPM database is much easier.
You can move the database in the user interface. Go to Configure / General Settings for this dialog.
Note that we’ve stretched the form a little wider, left to right, so you can see the entire default database path.
One good reason for moving the database path is to exclude it from your antivirus software as we talked about in “Escaping the grip of antivirus”. Another is to put it where your system software can back it up. You should not be running RPM when you back up because the database file will be open.
However, you can’t put the database on a network share. Why? Because the software that manages the database, Firebird SQL, doesn’t support that.
There are a few other changes that may interest you. Please check out the RPM roadmap for more information. And leave us a comment if you like. Thanks!