Retry limits and FIFO queueing

[Michael Sweet]

Anonymous wrote:
> A couple of years ago, we upgraded our print server and the Linux
> distro we were using switched from lprng to cups.
> 
> At that time, we had to scrap cups because of its lack of
> customization especially in two areas.
> 
> When I look at the current documentation, I still don't see any means
> of configuring them.  I'm hoping the features are there, and just an
> oversight in the documentation.  Since every Linux distro is making
> cups the default it would be nice to just be able to use it, instead
> of fighting and ripping it out, and putting lpr in place.
> 
> The two critical show stoppers for us are retry limits for a print
> job and making sure the queue is first job in, first job out.
> 
> What we were experiencing is that if the remote print box was
> unreachable, or its queue was full, cups would retry a few times, and
> then give up on the job and the user would have to reprint it.
> 
> Worse is if the remote queue is full and tells cups to retry later,
> cups would take that job, and put it at the end of the queue, and try
> the next item in the queue, so you would get jobs printed out of
> order.
> 
> Please tell me I'm just missing the config file options.  If not,
> then someone needs to really consider making more things customizable
> via options for highly demanding enterprise printing.

The behavior you were seeing should never happen.  A CUPS client will
retry a remote job indefinitely, holding up all other jobs for that
queue on the same client.

That said, classes and multiple client configurations can produce
the illusion of out-of-order jobs.  For example, if you submit a
job to a class and then a job to a printer that is part of that
class, it is possible that the job sent to the printer will print
before the job sent to the class.  There is no "fix" for this, as
it is a side-effect of how jobs are scheduled when printing to a
class.

In the case of multiple clients, it is possible for a multi-file
job from one client to be "interrupted" by a job from another
client that is submitted at the same time, such that the jobs
come out in the order A1 B A2.  This particular issue is resolved
in the upcoming CUPS 1.2 release, as 1.2 clients will queue all
files in a job in a single connection to the server rather than
sending the files as separate server jobs.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com