fbpx Major job retry fix / RPM 6.2.0.513 Beta release | Brooksnet

Major job retry fix / RPM 6.2.0.513 Beta release

grocery bag full of good things
A grocery bag full of good things

This post describes the RPM Remote Print managerĀ® 6.2.0.513 "beta" on March 10, 2020. It comes with several features added, compared to the earlier 6.2.0.512 release. The results of this beta release were so good that we didn't see a need to follow up with a release version right away.

Job retry, retried

The most significant upgrade was to the job retry process. A customer reported a situation where they were running RPM under a regular user account (not the system account) but using the RPM install folder as a working directory for a filter program. Every attempt to start the job failed immediately, as you could imagine.

Even though this was a customer issue that should be easy to resolve, the problem we addressed was inconsistencies in how RPM handles job and action errors. Action errors are supposed to be about configuration problems with the action, while job errors are supposed to be about a mismatch between the job data and the configuration.

As part of this, we also added an index to the event log database. The customer provided an events database with 7.8 million records that took a very long time to update with new events. We added an index to the message expiration date and changed the message retention time from 30 days to 7.

Finally, the UI also notifies RPM when the user reprints a job so that RPM can reset the job retries; otherwise, trying to reprint a job that already failed would have no effect.

Dynamic Copy to Queue limitation

You can use Data Extraction with the Copy to Queue action to pull text from a print job and use that to determine which queue receives the print job.

The problem we addressed is where the queue doesn't already exist, and Copy to Queue does not have permission to create it.

Other changes

  • We added exception handling for all RPM shutdown processes
  • We provided a default choice between using pipes versus shared memory for database processing
  • The UI now supports all the diagnostic logs, not just RPM; in fact, the change is so major we entirely rewrote the diagnostic log page