Bug 697699 - Firefox and Chrome pegs CPU at 100% for > 20 seconds
Firefox and Chrome pegs CPU at 100% for > 20 seconds
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
4.0.0.Beta2
Unspecified Linux
urgent Severity medium (vote)
: ---
: ---
Assigned To: John Mazzitelli
Mike Foley
:
Depends On:
Blocks: rhq4
  Show dependency treegraph
 
Reported: 2011-04-18 19:26 EDT by Mike Foley
Modified: 2013-09-02 03:19 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-02 03:19:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Video that shows the resizing (use vlc to view) (251.00 KB, video/quicktime)
2011-04-21 08:08 EDT, Heiko W. Rupp
no flags Details
snapshot.png (19.69 KB, image/jpeg)
2011-04-26 12:58 EDT, John Mazzitelli
no flags Details

  None (edit)
Description Mike Foley 2011-04-18 19:26:55 EDT
Description of problem:

Firefox pegs CPU at 100% for > 20 seconds

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


How reproducible:
2-3 times per day

Steps to Reproduce:
1.  FF using RHQ ....
2.
3.
  
Actual results:

CPU pegs at 100%

Expected results:

FF does not become unusable due to high CPU usuage

Additional info:
Comment 1 Charles Crouch 2011-04-18 19:29:14 EDT
Needs triage. The only other time I've seen this was on browser resizing
Comment 2 Mike Foley 2011-04-18 19:32:10 EDT
FF version 3.6.16
OS = Fedora 14
Comment 3 Alan Santos 2011-04-19 10:38:27 EDT
Same issue here:

Firefox 4, osx and linux.
No FF extensions were running at the time.
Comment 4 Mike Foley 2011-04-19 17:16:13 EDT
1 specific location where this type of hang occurred is:  mixed group, summary view, adding portlets
Comment 5 John Mazzitelli 2011-04-20 18:04:28 EDT
i'm seeing this on chrome as well. I spent several hours with speedtracer in chrome and xul profiler in FF to debug this, this is what I saw:

1) it was easier to replicate on chrome
2) in FF, the resource : alerts portlet listgrid danced (column resized continually) and was a sign of CPU getting pegged
3) in chrome, I used speedtracer to see that when CPU pegged, there was a lot of timer triggers happening that looked to be refreshing the listgrid.
4) in chrome, the CPU issue was never seen if the list grid was *NOT* empty. If I deleted all the empty portlets, CPU went back to normal. 
5) Alert>History uses the same view/table/datasource as the portal and I saw CPU issues there too
6) I changed the list grid widths so that one had "*" width - didn't help
7) I changed the list grid widths so they all were hardcoded (no "*" and no percentages) - didn't help
Comment 6 Heiko W. Rupp 2011-04-21 08:08:00 EDT
I saw this now too:

- removing the empty recent alert portlet did not help, so I removed the mashup 
portlet and cpu usage went down

- I added the recent alert portlet again (which was added to the narrower left 
column). This was constantly trying to find to optimal size for the columns.
Comment 7 Heiko W. Rupp 2011-04-21 08:08:41 EDT
Created attachment 493806 [details]
Video that shows the resizing (use vlc to view)
Comment 8 Heiko W. Rupp 2011-04-21 09:40:06 EDT
Additional data points:
- putting the recent ops portlet to the left has no issues, it puts a big horizontal scrollbar at the bottom and is ok.
- the recent alert portlet on the left does not put a big scrollbar at the bottom, but tries to find the optimal size (which fails, see above)
Comment 9 Charles Crouch 2011-04-25 10:40:17 EDT
With mazz to determine the width incantations which don't cause a CPU spike.
Will consider turning off setWidth() calls, and therefore equalizing all column widths, but will probably need to store column width preferences for users too then.
Comment 10 John Mazzitelli 2011-04-26 12:45:01 EDT
Looks like this problem stems from a single setting on the list grid. In the Table class, if I comment out the setting of setAutoFitData, I didn't see the CPU problem:

        if (flexRowDisplay) {
            //listGrid.setAutoFitData(Autofit.HORIZONTAL); // do NOT set this - smartgwt appears to have a problem that causes it to eat CPU
            listGrid.setWrapCells(true);
            listGrid.setFixedRecordHeights(false);
        }
Comment 11 John Mazzitelli 2011-04-26 12:58:27 EDT
Created attachment 494995 [details]
snapshot.png

commit 62875f0

one thing that this change now does, is it appears that the listgrid sometimes doesn't resize itself to full 100% width of its parent component (I don't see how this could be related, but this started happening after this commit).

The listGrid does have setWidth100() called, as well as its parent, so I don't know why this happens. See the attached image.
Comment 12 John Mazzitelli 2011-04-26 16:03:51 EDT
several things to test - do these on both Firefox and Chrome:

1) go to a resource's Summary>Activity page where there are no alerts or operations in the recent alerts/operations portlets
2) shrink the height of the browser window so it cuts in half the size of the right-top portlet
3) hit F5

Make sure the CPU doesn't max out (use "top" or some other tool to do this).

4) Now resize the browser back to a normal size. Hit F5 to refresh the entire app again.
5) Go to the recent alerts and recent operations portlets and increase the width of one or more columns so the entire width of all columns is greater than the width of the listgrid itself.

Make sure the CPU doesn't max out.
Comment 13 Mike Foley 2011-06-07 09:12:10 EDT
this was verified as part of rhq 4.0 and 4.0.1 community releases
Comment 14 Heiko W. Rupp 2013-09-02 03:19:33 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.

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