Job error handling
We have greatly improved the retry process. Each job now has its own retry count and we added a "max retries" to the UI. This value defaults to five. We also have a retry frequency to specify how long to wait between attempts.
We have seen customer systems where jobs have continually retried, without anyone realizing, for as long as five months. Others reported they had enough jobs retrying that it prevented new jobs from processing.
Job reprint
- Added “reprint” notification to the job pump, which means if RPM reprints jobs for any reason, the effect is immediate and not potentially delayed up to ten seconds
- When the user reprints a job, RPM will reset the “retry count” for that job. This way if you attempt to fix whatever is causing the job to fail, reprinting will give you a new set of retries for that job.
- If one or more actions are disabled for a job, and you reprinted it, it would appear to keep printing forever. This is fixed.
Job retention
Jobs with “REMOVE_AT” set are removed by RPM on startup, when that time is in the past; in other words, RPM was not running when the job was scheduled to be removed normally. This is part of the job retention system.