I'm not sure if this is the only way to get this to happen, but changing the portlet refresh period leaves portlets in the background, making refresh queries, even when navigating away from the dash. I've also noticed that the first time the dash is visited it seems to be rendered twice. I'm not sure if this is a related problem.
master commit a4b6506d915ea2ef26ff92005c46f0d6947eee7c There were a few issues here. First, whenever the dash was re-built (when the refresh period changed or a portlet was deleted, and maybe other scenarios) old portlets may have been left with stale references, leaving them around, undrawn, but for auto-refresh portlets, still querying the server at their refresh intervals. Note that this happens *even when* proper destroy() calls have been made. Second, we had protection in place not to refresh hidden portlets, but undrawn/visible portlets (like the ones in this scenario) still refreshed. So, I beefed up that check just to block backend queries in a similar situation. Third, we shouldn't even have been rebuilding the dash when changing the refresh interval, the refresh period update was already being applied to the existing portlets. So, stopped that from happening. This may have actually solved a different problem I've noticed, a double-rendering of the dash on he very first login for a user. I think because we set the refresh period for the first time. Test Notes: A little tricky to verify but try this. - log in and render the dashboard - delete the message or mashup portlet - in edit mode change the refresh rate to 5 minutes * you should not see a full rebuild of the dash here - change it back to 1 minute - navigate to Administration and just sit there - Bring up the stats window (Ctrl-SH-S) - Delete all previous server call stats - wait for a few minutes and refresh the stats window * you should not see calls to the server for recent alerts or operations or anything portlet related.
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.