Bug 1066947 - Alert being triggered twice if the Operation Execution has the status set to In Progress
Summary: Alert being triggered twice if the Operation Execution has the status set to ...
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: UI
Version: JON 3.2.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: ER03
: JON 3.3.0
Assignee: Thomas Segismont
QA Contact: Mike Foley
Depends On: 919516
TreeView+ depends on / blocked
Reported: 2014-02-19 11:06 UTC by Sunil Kondkar
Modified: 2014-12-11 14:02 UTC (History)
7 users (show)

Clone Of: 919516
Last Closed: 2014-12-11 14:02:38 UTC

Attachments (Terms of Use)

Description Sunil Kondkar 2014-02-19 11:06:48 UTC
+++ This bug was initially created as a clone of Bug #919516 +++

Description of problem:
If an alert has a condition of type "Operation Execution" and the status field is set to "In Progress", then the alert get triggered twice if I the op. is run

Version-Release number of selected component:

How reproducible:

Steps to Reproduce:
1. create an alert on "RHQ Agent" resource

2. add a new condition of type Operation Execution, select the op. "Execute Availability Scan" (for instance) and set the status to "In Progress"

3. schedule the selected operation ("Execute Availability Scan" in our case) on the RHQ Agent resource

4. observe the alerts/history tab

Actual results:
the alert is there twice

Expected results:
the alert is there only once

--- Additional comment from Jirka Kremser on 2013-12-04 12:00:40 EST ---

it's working in master

Comment 1 Sunil Kondkar 2014-02-19 11:09:12 UTC
Added a test for alert in progress condition:

To run the test:
git clone https://github.com/RedHatQE/jon-tests.git
cd jon-tests/alerts
nosetests -a "single,control"

Comment 4 Sunil Kondkar 2014-08-28 08:18:11 UTC
The test fails on JON 3.3 ER01 build.

Link to the test run:

Also tested manually on Version :3.3.0.ER01 Build Number :23b3476:f3aa7e7
The history tab displays two alerts for In Progress alert condition when the operation is executed.

Comment 5 Thomas Segismont 2014-08-28 11:54:18 UTC
I could reproduce as well on a 3.3 branch build. Here's the issue.

When the operation is scheduled an operation history entity is persisted, because the operation entity needs it. The first alert is fired at this moment.

Later, a quartz job remotely invokes the operation on the agent. When the job starts, it updates the operation history to indicate the actual start time. Then the second alert is fired.

I can see two ways to improve the situation.

1. Given that the alert condition editor says "Specify the result that must occur when the selected operation is executed in order to trigger the condition.", we could simply remove the "In progress" status from the expected value combo box. "In progress" is not an operation *result*, it's just an operation execution status.

The drawback is that users won't be able to be alerted on operations being started any more.

2. Change the wording of the alert condition editor to indicate that he's going to monitor an operation status change. And change the alert condition evaluation code so that only changing status fires an alert.

I tend to prefer the second solution but I'd like to hear Larry's input.

Comment 6 Jirka Kremser 2014-08-28 13:24:46 UTC
I like 2) better. Removing "In progress" (option 1) would break the existing alerts on existing JON installations.

Comment 7 Thomas Segismont 2014-09-03 11:47:48 UTC
Fixed in master

commit c09e9440f19b97dd6b3a353fc3880afefd4d3222
Author: Thomas Segismont <tsegismo@redhat.com>
Date:   Wed Sep 3 13:46:21 2014 +0200
    Changed the wording of the alert condition editor to indicate the user is going to monitor an operation status change.
    Call #notifyAlertConditionCacheManager only if the operation history status has changed.

Comment 8 Jay Shaughnessy 2014-09-11 18:32:38 UTC
This fix looks good to me.

release/jon3.3.x commit b013ec236ba523462bfcaca7de08d470300ae372
Author: Thomas Segismont <tsegismo@redhat.com>
Date:   Wed Sep 3 13:46:21 2014 +0200

    (cherry picked from commit c09e9440f19b97dd6b3a353fc3880afefd4d3222)
    Signed-off-by: Jay Shaughnessy <jshaughn@redhat.com>

Comment 9 Simeon Pinder 2014-09-17 02:49:29 UTC
Moving to ON_QA as available for test with the following brew build:

Comment 10 Sunil Kondkar 2014-09-17 11:11:09 UTC
Verified on version : 3.3.0.ER03 build number : 4aefe39:44e33a4

The test is passed on JON 3.3 ER03 build.

Link to the test run:


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