[cups.general] Best practice for setting "ErrorPolicyretry-job"on all defined print queues?

Michael Sweet msweet at apple.com
Tue Aug 4 08:20:27 PDT 2009


On Aug 4, 2009, at 1:03 AM, Johannes Meixner wrote:
>> ...
>> Nope.  In fact, classes only support the "retry-job" policy...
>
> I didn't find a descripion of the ErrorPolicy behaviour for classes at
> http://www.cups.org/documentation.php?VERSION=1.4
> (but I may have missed it somewhere).

Technically, classes *have no error policy*, and never have. As a  
matter of consistency, we report a printer-error-policy of retry-job,  
but you can't set the policy to anything else because there is no  
policy for classes.

> Even if there is only one (hardcoded) ErrorPolicy behaviour for  
> classes,
> it would help to have it described.

There is no error policy.  Classes have always (and this is  
documented) printed jobs on the next available printer in the class.   
If a printer errors out (server crashes, printer goes down, etc.),  
then the job is retried on the next printer in the class.

> But what would happen if job fails also on the queue "that"?
> Would the "retry-job for a class" with two queues then toggle
> infinitely between "this" and "that"?
> Or would it do an infinite "round robin" if there is a class
> with several queues but all queues fail continuously?

Yes to both.  For a class with 1 printer, we just retry that one  
printer indefinitely. For two or more we cycle through the available  
printers, trying each in turn until the job can be printed successfully.

If no printers are available (idle and accepting jobs), then the job  
is held indefinitely (there is a feature request to offer a "cancel  
job after holding for a given time period...)

___________________________________________________
Michael Sweet, Senior Printing System Engineer







More information about the cups mailing list