Bug 1130788 - Event flooding mechanism takes in account deleted events
Summary: Event flooding mechanism takes in account deleted events
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.5.0
Assignee: Eli Mesika
QA Contact:
Whiteboard: infra
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-17 18:22 UTC by Eli Mesika
Modified: 2016-02-10 19:29 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-08-26 14:21:00 UTC
oVirt Team: Infra
Target Upstream Version:

Attachments (Terms of Use)

Description Eli Mesika 2014-08-17 18:22:26 UTC
Description of problem:
Event flooding mechanism takes in account deleted events.

Starting with 3.5 release we have now an option to remove .Event/Alert from UI. 
Once an Alert is removed, it is marked a "deleted" in the audit_log table and is not returned to the client in next retrivals 

But, to implement the event flooding we use cache mechanism, the removed event is not removed from cache and therefor subsequent event during the event flooding period will not be shown to the user

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

How reproducible:

the problem is 
Steps to Reproduce:
1.Do any action that generates an Event/Alert
2.Dismiss the generated Event/Alert from UI
3.Repeat step 1 withing the flood rate (defined in AuditLogType.java)

Actual results:
The second Event/Alert is suppressed 

Expected results:
The dismissed event should be cleaned from cache and the second generated event from step 3) should be shown 

Additional info:

Comment 1 Oved Ourfali 2014-08-19 06:15:19 UTC
Note that at the moment, only alerts can be dismissed.

Comment 2 Oved Ourfali 2014-08-26 14:21:00 UTC
Discussing it offline with Eli, we agreed that the current behavior is okay.
If, for example, we have an alert with flood rate of 30 seconds, and the flow is as follows:
1. Sec 1: Alert is triggered.
2. Sec 2: Alert is dismissed.
3. Sec 3: Alert is triggered again.

In "3" I wouldn't like to see the alert again, only if it is triggered again after 30 seconds.

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