Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Client side exception generated when viewing empty compatible group|
|Product:||[Other] RHQ Project||Reporter:||John Sanda <jsanda>|
|Component:||Core UI||Assignee:||Jay Shaughnessy <jshaughn>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike Foley <mfoley>|
|Version:||4.2||CC:||hrupp, jshaughn, skondkar|
|Target Release:||RHQ 4.3.0|
|Fixed In Version:||4.3||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-08-31 06:16:07 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description John Sanda 2011-12-01 10:11:01 EST
Comment 1 Jay Shaughnessy 2011-12-01 11:03:39 EST
I reproduced this pretty quickly. 1) Create new empty group - No problems, note that it is a mixed group 2) Add a member (I used an RHQAgent resource) - No problems, note that it is now compatible and has the type assigned 3) Uninventory the resource 4) Nav to All Groups - note that the type is still assigned and the group is still compat 5) Drill down and generate the exception I'm not sure it's wrong to have an empty compatible group. In fact it may be preferable, or even required, to resetting the group back to mixed just because it is empty. So that may be ok but possibly we should be resetting it. The problem actually seems to be generated by one of the resource portlets, so it may not really be a problem with the group being empty and compatible. It may just be a false assumption in the portlet code that a group isn't empty: [INFO] (RPCTracker.java:82) 2011-12-01 10:58:26,155 [TRACE] RPCTracker queue depth is 6 [ERROR] (MessageCenter.java:92) 2011-12-01 10:58:26,251 [ERROR] At [Thu Dec 01 10:58:26 EST 2011] MessageCenter received: Globally uncaught exception [INFO] (ErrorHandler.java:60) 2011-12-01 10:58:26,269 [WARN ] Globally uncaught exception [INFO] java.lang.ArrayIndexOutOfBoundsException: [INFO] 0 [INFO] at org.rhq.enterprise.gui.coregui.client.inventory.groups.detail.summary.ActivityView$4.onSuccess(ActivityView.java:232) [INFO] at org.rhq.enterprise.gui.coregui.client.inventory.groups.detail.summary.ActivityView$4.onSuccess(ActivityView.java:1) I'll look into it...
Comment 3 Jay Shaughnessy 2011-12-01 12:39:51 EST
master commit 81960e013533ee848aacc7716bf4bc254df93b2d This turns out to be something of a happy accident. The offending code made an assumption that the group would not be empty. But looking more closely it seems to me that the entire code block is unnecessary. Moreover, it added a round trip to the DB when displaying the group level dashboard. It was trying to determine whether to render the bundle deployment portlet. From what I can see, this can be determined already by looking at the group's type's facets. And in fact the code was already in place. So: - removing unnecessary db round-trip code (was even being done for mixed groups) - keeping the existing facet-based code, which seems to do the right thing - fixing a secondary problem that wrongly displayed the bundle deployment portlet for mixed groups. So, Three fixes for the price of one! Resource level code seems to work fine and does not have an analogous issue. Test Notes: - use the repro steps to try this for the empty compat groups, for types both supporting and not supporting bundles. - try populated compat groups, for types both supporting and not supporting bundles. tip: you can use autogroups for this to save time. - try mixed groups(should not have the bundle deployment portlet)
Comment 4 Sunil Kondkar 2011-12-09 07:09:32 EST
Verified in master build#825 (Version: 4.3.0-SNAPSHOT Build Number: e8db9a1) Verified with repro steps for empty and populated compatible groups, for types both supporting and not supporting bundles (EAP5 servers and RHQAgent for example) Verified on mixed groups. No exception is observed.
Comment 5 Heiko W. Rupp 2013-08-31 06:16:07 EDT
Bulk close of old bugs in VERIFIED state.