Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 657107 - need to make alert query more efficient for "recent alert count" display
Summary: need to make alert query more efficient for "recent alert count" display
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 3.0.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Charles Crouch
QA Contact: Mike Foley
Depends On:
TreeView+ depends on / blocked
Reported: 2010-11-24 22:50 UTC by John Mazzitelli
Modified: 2015-02-01 23:26 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-09-02 07:14:01 UTC

Attachments (Terms of Use)

Description John Mazzitelli 2010-11-24 22:50:17 UTC
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!

Comment 1 John Mazzitelli 2010-11-24 22:54:16 UTC
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).

Comment 2 Joseph Marques 2010-11-24 23:20:07 UTC
commit ec43cd6bf1be52a0a101f85faf654610b27c6df6
Author: Joseph Marques <joseph@redhat.com>
Date:   Wed Nov 24 18:17:10 2010 -0500

    BZ-657107: support querying alert count by criteria (and show in footer)

Comment 6 Mike Foley 2011-06-15 19:29:38 UTC
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.

Comment 7 Heiko W. Rupp 2013-09-02 07:14:01 UTC
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.