Hide Forgot
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.
master commit 7362e08cf6b53d2f59909af0013559e7a261157f Author: Jay Shaughnessy <jshaughn@redhat.com> 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@redhat.com> Date: Wed Aug 6 12:26:49 2014 -0400 Cherry-pick master: 7362e08cf6b53d2f59909af0013559e7a261157f
Moving to ON_QA as available to test in the following brew build: https://brewweb.devel.redhat.com//buildinfo?buildID=379025