Bug 480369

Summary:	[fix available] OOo apps are polling cups server several times a second creating load problems
Product:	Red Hat Enterprise Linux 5	Reporter:	Paul Raines <raines>
Component:	openoffice.org	Assignee:	Caolan McNamara <caolanm>
Status:	CLOSED ERRATA	QA Contact:	desktop-bugs <desktop-bugs>
Severity:	medium	Docs Contact:
Priority:	low
Version:	5.2	CC:	llim, mshao
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-09-02 09:09:10 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Paul Raines 2009-01-16 17:52:32 UTC

Description of problem:

Open office programs (Write, Calc, ...) constantly poll the cups server
several times a second creating load problems on the cups server.

Version-Release number of selected component (if applicable):

openoffice.org 2.0.4-5.4.17.3

How reproducible:

100% reproducible (at least with my setup)

Steps to Reproduce:

On a workstation client, set ServerName in /etc/cups/client.conf to your 
cups print server.  Start up an open office app.  Do a 'tail -f /var/log/cups/access.log' on your server and watch the polls come in from that 
client many times a second.  You can also log into the client, find
the process id of the open office app and run something like

  strace -p OOAPPPID# 2>&1 | grep IP_of_server

With our center having over 200 clients and 10's of people running
openoffice at any one time I always see cupsd on the server running
at 100% CPU even when no printing is going on because of all the 
polling going on.

Actual results:

CUPS server is loaded down by all the client polling going on

Expected results:

CUPS server should not be loaded down

Additional info:

Comment 1 Paul Raines 2009-01-16 17:55:06 UTC

I should add our cups server has about 100 printers defined (2 defs for each real printer: one raw / one with appropriate driver)

Comment 2 Caolan McNamara 2009-01-19 13:31:02 UTC

This might be the gtk print dialog. 

As a random dev-level thought, making the instance non-static might have an effect.

Comment 3 Caolan McNamara 2009-01-23 15:41:56 UTC

This is really the gnome print dialog. It does when it is active. Its particularly a problem for OOo though in that once the dialog has been used, its kept around, even though not visible, after a "print" or a "cancel" and so the constant pinging that would otherwise only happen while it is open continues.

We need to de-instantiate it after showing it to alleviate the problem.

Comment 4 Caolan McNamara 2009-02-05 23:25:54 UTC

fix should be straightforward in making dialog non static post instantiation

Comment 5 Caolan McNamara 2009-03-12 11:25:32 UTC

committed for >= 2.3.0-6.11

Should only poll while the dialog is open, i.e. be equivalent to evince in how it hammers cups and not more so.

Comment 7 Yewei Shao 2009-06-02 06:32:33 UTC

mshao->raines, could you please help us to do this bug verify using openoffice.org-2.3.0.6.11.el5 in your center to see whether this bug is still exist or it has been fixed and give us your results? The reason is that we do not have the environment that contains over 200 clients and 10's of people running openoffice at any one time and thanks.

Comment 8 Caolan McNamara 2009-06-02 08:54:12 UTC

should be possible with
tail -f /var/log/cups/access.log
on the machine running cups to see no activity until the print dialog appears. In an older OOo when the dialog goes away the activity should continue until OOo shuts down, while in a new one activity should stop when the dialog goes away (IIRC)

Comment 11 errata-xmlrpc 2009-09-02 09:09:10 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1248.html