RPM Remote Print Manager® ("RPM") relies heavily on the database since all jobs, configuration, and logs are stored there. Following are the updates in database processing since the last release.
- The message log now adds log entries in a separate thread, so that logging will not slow down the other processing substantially. You can even turn on high detail with a far lower performance penalty. Much of course depends on your computing environment.
- We tracked a substantial memory leak to the message log code and eliminated a third party library to resolve the problem.
After a customer sent us their database file, we discovered that the PRIORITIES table had literally thousands of entries for queues and devices which no longer exist. We added cleanup for the PRIORITIES table in RPM startup and added handlers for whenever a queue or device is removed.
We discovered that the QUEUESEQ table was not being properly updated after an RPM upgrade from a previous version. The symptom was that the system was unable to generate a job ID when creating new jobs. This is a fairly serious show-stopper error. We added code to check the QUEUESEQ table on startup and ensure that it was error free.
We found some database transactions which invoked an error in the database which we were not recovering from. We found a way to report these errors safely. They are currently being reported in the RPM events log.
Dbmigrate will now migrate the database if the file exists in the default location, even if we are not upgrading RPM.