We need to change the API the UI client uses to get the alert count (the count you see in the bottom right of the UI, where it says "[#] Recent Alerts". right now it ends up calling: org.rhq.enterprise.server.alert.AlertManagerBean.findAlertsByCriteria(Subject, AlertCriteria) which queries and returns much too much data for this usage of it. All we need to do is do a count query and return a single integer. Instead, we are returning all Alert objects, including all conditions sets!
looks like the criteria uses limits the page size to 1 row, so this isn't as bad as it first looked by code inspection. // only get one record from the first page, we only really care about the count alertCriteria.setPaging(0, 1); But we really still don't have to send that much data (remember, this query is periodically called every 1 minute for EVERY user).
commit ec43cd6bf1be52a0a101f85faf654610b27c6df6 Author: Joseph Marques <joseph> Date: Wed Nov 24 18:17:10 2010 -0500 BZ-657107: support querying alert count by criteria (and show in footer)
tested alerts. from an empirical standpoint, i am seeing response time < 10 seconds (arbitrary performance SLA) in the alert area. when alerts are slow, it seems to be related entirely to the UI layer with CPU utilization at 100% attributed to Firefox browser and not the server response time. there is a more full-blown performance effort underway, and fully intend to identify and optimize performance from that perspective.
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.