Bug 1126853 - Alert does not trigger if defined with 'disable when fired'
Summary: Alert does not trigger if defined with 'disable when fired'
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: UI
Version: JON 3.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ER01
: JON 3.3.0
Assignee: Jay Shaughnessy
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-05 12:50 UTC by Sunil Kondkar
Modified: 2014-12-11 14:04 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-12-11 14:04:36 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Sunil Kondkar 2014-08-05 12:50:19 UTC
Description of problem:

If an alert definition is created with Availability DOWN for EAP server, then another for Availability UP with the Recovery Alert "Availability DOWN Alert", the DOWN alert is not triggered. Also when server is up, the UP alert is not triggered.  

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

Version : 3.3.0.DR01 
Build Number :	6468454:dda0a47
Database: Postgres 9.2

How reproducible:

Always

Steps to Reproduce:

1) Create an alert (Ex: testalert1) for 'Availability Goes Down' on EAP6 server with:
 Condition: Availability goes down
 Recovery: Disable when Fired=yes

2) Create a second alert (Ex: testalert2) for 'Availability Goes Up':
 Condition : Availability goes down
 Recovery: Select 'testalert1' in Recover Alert dropdown

3) Stop the EAP6 server
4) Navigate to the Alerts->History tab of EAP6 server
5) No alert is displayed in history
6) The alert definition 'testalert1' is still enabled.
7) Start EAP6 server
8) Navigate to the Alerts->History tab of EAP6 server
9) No alert is displayed in history


Actual results:

Alert does not trigger if defined with 'disable when fired' and the alert definition is still enabled.


Expected results:

Alert gets triggered for DOWN condition and alert definition gets disabled. Second recovery alert should get triggered when EAP server is started and up and then first alert definition should get enabled again.

Additional info:

If the second alert definition (Ex: testalert2) for 'Availability Goes Up' is created without selecting the recovery alert, the avail up alert is sent successfully when EAP server goes up.

Comment 3 Jay Shaughnessy 2014-08-06 16:28:53 UTC
master commit 7362e08cf6b53d2f59909af0013559e7a261157f
Author: Jay Shaughnessy <jshaughn>
Date:   Wed Aug 6 12:19:10 2014 -0400

 This was undetected fallout from the work done in BZ 1110434.  Although,
 it's fallout that doesn't make a lot of sense.  It's either a bug in
 HornetQ/Arjuna/EAP interaction Tx management, or we violated some very
 subtle J2EE/JTA rule.  Basically this is what was happening:
 1) alert condition consumer onMessage is invoked (with default CMT Tx
    semantics)
 2) it invokes a series of nested SLSB calls with various Tx semantics,
    including REQUIRED, REQUIRES_NEW and NOT_SUPPORTED.
 3) The NOT_SUPPORTED method hangs on method return, as such some downstream
    processing commits (due to REQUIRES_NEW semantics) but the upstream calls
    don't complete.  So even though the alerting all worked, it never got
    to commit.
 4) After 10 minutes the Tx reaper comes along and cancels the hanging Tx.

 The fix/workaround is actually easy. Instead of calling the general purpose
 disableAlertDefinitions() method (which supports mass-disable and therefore
 uses the NOT_SUPPORTED semantics to help chunk transactioning) we switch to
 the disableResourceAlertDefinitions() method (which uses REQUIRED) because
 we know we are dealing with a single resource-level alert definition.
 We make an analogous change for enable.  We are basically avoiding the
 issue.


release/jon3.3.x commit 212452c4cdd9c697b6c3ba382d924c358273360d
Author: Jay Shaughnessy <jshaughn>
Date:   Wed Aug 6 12:26:49 2014 -0400

 Cherry-pick master: 7362e08cf6b53d2f59909af0013559e7a261157f

Comment 4 Simeon Pinder 2014-08-19 23:50:26 UTC
Moving to ON_QA as available to test in the following brew build:

https://brewweb.devel.redhat.com//buildinfo?buildID=379025


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