[cups.development] [RFE] STR #3789: avoid filters stalling print queues

Matt L mattl at google.com
Sun Feb 6 00:59:21 PST 2011


DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

It is not impossible that a filter may either run for an extended period of
time or hang.  In my case, I have witnessed pdftops run for 2+ hours when
processing a single large PDF.  In conversation with the developer
(http://comments.gmane.org/gmane.comp.freedesktop.poppler/4970) it is
acknowledged that there are known and unresolved cases where this may
occur (https://bugs.freedesktop.org/show_bug.cgi?id=13518).  Of course,
this may happen in more cases and with more filters than we are currently
aware of, and bugs may come and go at any time.

While we can write this off as the responsibility of the filter developer,
it would be ideal for cups to be more robust in how it treats such a
scenario.  Currently, if a user prints a document which gets stuck in the
filter, all subsequent jobs to the same queue will be held until the
filter completes or cancels.  If one user submits a 2 hour file, and ten
other users then submit 2 second files, the users of the tiny files will
still not see their jobs print until the 2 hours is up or the long running
job is canceled.

I'm unsure how best to handle this, but I have a few ideas:

First, we might consider an optional config variable similar to
JobKillDelay, but which counts from the start of the job rather than from
the time the job is cancelled.  The downside here is that jobs may be
canceled without explanation (unless the logs are checked by the
administrator).  The positive side is that it should be simple to
implement without making any fundamental changes to the scheduler.

A second option is to allow queues to be serviced in a non-FIFO fashion. 
If multiple jobs can be run at once, fast jobs can simply bypass a delayed
job in the queue.  In essence, this means we would have two queues:
pre-filter and post-filter.  Pre-filter is where all incoming jobs sit. 
They are serviced as resources become available, in as many parallel
processes as the system allows.  As each filter exits, the result is
placed in the post-filter queue.  The post-filter queue remains a FIFO
queue to the hardware.  This optimizes our ability to push jobs out to the
hardware with minimal latency, but is clearly a more invasive solution.

Link: http://www.cups.org/str.php?L3789
Version:  -feature





More information about the cups-devel mailing list