Bug 545062

Summary:	Alerts based on events start fire after an unknown delay
Product:	[Other] RHQ Project	Reporter:	Jaroslaw Kijanowski <jkijanow>
Component:	Alerts	Assignee:	Joseph Marques <jmarques>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Sudhir D <sdharane>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	cwelton, fdrabek, mharvey
Target Milestone:	---	Keywords:	SubBug
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	2.4	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-08-12 16:57:50 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	565635, 584435

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.