www.cendio.com
Bug 1456 - Prevent queue clogs when thinlocal is transferring large jobs on slow links.
: Prevent queue clogs when thinlocal is transferring large jobs on slow links.
Status: CLOSED FIXED
: ThinLinc
Printing
: trunk
: PC Linux
: P2 Normal
: 4.4.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-08-22 14:21 by
Modified: 2015-05-11 14:20 (History)
Acceptance Criteria:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2005-08-22 14:21:12
Currently, if someone is printing a large job via thinlocal on a slow link, all
other thinlocal jobs will have to wait for the job's completion before they can
start.

This is due to the serial nature of CUPS queues.

We should evaluate a forking model where the backend exits after aquiring
relevant information from the VSM server, and probably also contact with the
other end, so the next job can be started. The backgrounded job can then send
the data to the client without being stressed by other jobs, and that is good,
because we want the  poor process to feel good about its short and rather
useless life.
------- Comment #1 From cendio 2014-11-26 16:10:56 -------
*** Bug 5368 has been marked as a duplicate of this bug. ***
------- Comment #3 From cendio 2015-02-23 09:08:51 -------
Just blindly fork and forget of a cups backend implies short circuit of error
handling from backend to the cups service. Each print job will be successfully
printed even those that fails.

The implementation should definitely do some error handling most obviously one
are if the cups service is available or not at client. One problem here might
be how to identify a disconnected client and a client with print redirection
tuned off.
------- Comment #4 From cendio 2015-02-23 09:34:36 -------
(In reply to comment #3)
> The implementation should definitely do some error handling most obviously one
> are if the cups service is available or not at client. One problem here might
> be how to identify a disconnected client and a client with print redirection
> tuned off.

Found an issue and created bug #5441 which might affect this bug.
------- Comment #5 From cendio 2015-02-23 11:02:56 -------
Some investigation shows that the IPP backend provides a waitjob flag to
control this behavior. If it's turned on IPP backend will wait for job print
finish and report back to cups in a serial chain. If waitjob is turned off IPP
backend will just push jobs to the remote queue and then exit with success.
------- Comment #6 From cendio 2015-02-23 11:15:23 -------
There is also an upstream bug where a delay of 5 seconds are performed.
  http://cups.org/str.php?L3495

This bug affects cups versions <v1.5, and would still affect the ThinLocal
backend queue after we solved this bug. 

Maybe we could make a hack in ThinLocal backend overcome this delay problem by
putting some data on the backend channel so that the wait loop always breaks
out.
------- Comment #7 From cendio 2015-02-26 11:00:10 -------
The lpd client implementation for ThinLocal does try to allocate a privileged
port if available to confirm to lpd protocol spec. If it fails to allocate a
privileged port it will fallback and use unprivileged port. Due to the ThinLinc
printing implementation, we can't handle this privileged port security and
therefor this is code should be removed to make the case clear.
------- Comment #8 From cendio 2015-02-26 12:28:12 -------
It seems that there is no way to log into cups log files from the forked
ThinLocal backend, the communication for backend to scheduler is performed via
stderr.
------- Comment #9 From cendio 2015-02-26 14:21:24 -------
(In reply to comment #7)
> The lpd client implementation for ThinLocal does try to allocate a privileged
> port if available to confirm to lpd protocol spec. If it fails to allocate a
> privileged port it will fallback and use unprivileged port. Due to the ThinLinc
> printing implementation, we can't handle this privileged port security and
> therefor this is code should be removed to make the case clear.

Privileged port binding removed in commit 30049.
------- Comment #10 From cendio 2015-02-26 14:32:06 -------
Commit 30050 forks the sending of job to client to prevent clog of thinlocal
queue.

The forking part lacks logging which needs to be taken care of. The only option
is to create a new logfile for the thinlocal, however /var/log/thinlocal.log is
not perfect. We should probably fix bug #4961 before introducing additional log
files.
------- Comment #11 From cendio 2015-03-03 16:30:42 -------
(In reply to comment #10)
>
> The forking part lacks logging which needs to be taken care of. The only option
> is to create a new logfile for the thinlocal, however /var/log/thinlocal.log is
> not perfect. We should probably fix bug #4961 before introducing additional log
> files.

A decision was made to ignore the logging this release. Added the bug #5457 to
reintroduce it in next release.
------- Comment #12 From cendio 2015-05-07 17:04:18 -------
Here's how I tested this:

 - started tlclient with printer redirection active, logged in to a server
 - stopped tlclient.bin (^Z)
 - printed a text file
 - printer another text file
 - verified that there were one thinlocal process running for each printer job.
 - resumed tlclient.bin (fg)
 - watched the printer jobs get handled and printed by tlclient.bin.

That seems to work fine. I want to test a few more things before I'm content
with closing the bug:

 - feedback for cases where printer redirection is off in the client
 - how long does the thinlocal jobs wait for?
------- Comment #15 From cendio 2015-05-11 14:20:39 -------
(In reply to comment #12)
> Here's how I tested this:
> 
>  - started tlclient with printer redirection active, logged in to a server
>  - stopped tlclient.bin (^Z)
>  - printed a text file
>  - printer another text file
>  - verified that there were one thinlocal process running for each printer job.
>  - resumed tlclient.bin (fg)
>  - watched the printer jobs get handled and printed by tlclient.bin.
> 
> That seems to work fine. I want to test a few more things before I'm content
> with closing the bug:
> 
>  - feedback for cases where printer redirection is off in the client
>  - how long does the thinlocal jobs wait for?

There's no feedback, and given the lpd protocol we're using it's hard to do
things better if we still want to have thinlocal work for more than one user at
the same time.

I've found no other problems.