This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 697699

Summary: Firefox and Chrome pegs CPU at 100% for > 20 seconds
Product: [Other] RHQ Project Reporter: Mike Foley <mfoley>
Component: Core ServerAssignee: John Mazzitelli <mazz>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: urgent    
Version: 4.0.0.Beta2CC: asantos, hrupp, mazz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
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:
Bug Depends On:    
Bug Blocks: 585306    
Attachments:
Description Flags
Video that shows the resizing (use vlc to view)
none
snapshot.png none

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.