Bug 545062 - Alerts based on events start fire after an unknown delay
Summary: Alerts based on events start fire after an unknown delay
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Alerts
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Joseph Marques
QA Contact: Sudhir D
URL:
Whiteboard:
Depends On:
Blocks: rhq_spearhead jon-sprint9-bugs
TreeView+ depends on / blocked
 
Reported: 2009-12-07 13:26 UTC by Jaroslaw Kijanowski
Modified: 2010-08-12 16:57 UTC (History)
3 users (show)

Fixed In Version: 2.4
Clone Of:
Environment:
Last Closed: 2010-08-12 16:57:50 UTC
Embargoed:


Attachments (Terms of Use)

Description Jaroslaw Kijanowski 2009-12-07 13:26:07 UTC
Description of problem:
I've enabled event logging and set up alerts to fire when a WARN message shows up.

When the app server displays a WARN message, no alerts fire immediately. I have to wait an unknown amount of time, sometimes it is 15 minutes, sometimes 50. Then I have to force the app server to display a WARN message *again* to trigger an alert. After that every WARN message triggers an alert and all looks good.

Version-Release number of selected component (if applicable):
JON 2.3.0 GA

How reproducible:


Steps to Reproduce:
1. Enable event logging, set up alert on WARN messages
2. Deploy an app that displays messages at the WARN level
3. Go to ALERT view and verify alerts show up as expected
  
Actual results:
Alerts show up after an unknown amount of time.

Expected results:
Alerts show up immediately after they have been set up.

Additional info:

Comment 1 Jaroslaw Kijanowski 2010-02-12 19:12:59 UTC
IMHO the problem here is more critical, since before the whole alerts mechanism kicks in (which may take 15 minutes, 50 minutes, but in general an *unknown* amount of time) all JON Alerts *get lost* - they will never show up. The WARN messages from the SOA-P server console however will be displayed in the EVENTS view.

Comment 2 wes hayutin 2010-02-16 16:57:30 UTC
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

keyword:
new = Tracking + FutureFeature + SubBug

Comment 3 wes hayutin 2010-02-16 17:02:32 UTC
making sure we're not missing any bugs in rhq_triage

Comment 4 wes hayutin 2010-02-17 13:36:11 UTC
moving any remaining Alert related bugs to rhq_chainsaw

Comment 5 wes hayutin 2010-02-18 14:49:57 UTC
This bug has now been triaged by Chainsaw on 2/18. The expectation is the bug to be addressed by the end of sprint06 roughly 3/10/10.

Comment 7 Joseph Marques 2010-04-30 15:25:41 UTC
commit 546f7dbcc30ecb0666f49958f275baac3c640151

fix for newly created event/measurement-based alerts not firing
    
* was previously trying to set agent status bit by alert definition id via pure JPQL
* however, at the time the JPQL is executed, the alert definition hasn't been persisted yet
* fix was to correlate the cache reload to resourceId instead, which is only required in the CREATE case
* added new method to StatusManagerBean called updateByResource to handle this new path
* updated logic in notifyAlertConditionCacheManager to switch on the AlertDefinitionEvent appropriately
* added more debug-level logging

Comment 8 Sudhir D 2010-06-13 14:17:09 UTC
I verified this against Build# 210. Alerts were fired immediately. Marking this bug as verified.

Comment 9 Corey Welton 2010-08-12 16:57:50 UTC
Mass-closure of verified bugs against JON.


Note You need to log in before you can comment on or make changes to this bug.