Branch: refs/heads/jshaughn/1125439 Home: https://github.com/rhq-project/rhq Commit: 20815ab04ab1692ed8f4dd1912de7dfcb7aa9f6b https://github.com/rhq-project/rhq/commit/20815ab04ab1692ed8f4dd1912de7dfcb7... Author: Jay Shaughnessy jshaughn@redhat.com Date: 2014-08-06 (Wed, 06 Aug 2014)
Changed paths: M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/AlertManagerBean.java
Log Message: ----------- [1126853] Alert does not trigger if defined with 'disable when fired' 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.
Commit: e7fd7c1c9ce5268c6ee2a314c57e344b65a5b494 https://github.com/rhq-project/rhq/commit/e7fd7c1c9ce5268c6ee2a314c57e344b65... Author: Jay Shaughnessy jshaughn@redhat.com Date: 2014-08-12 (Tue, 12 Aug 2014)
Changed paths: M modules/core/dbutils/src/main/scripts/dbupgrade/db-upgrade.xml
Log Message: ----------- [1125439] Duplicate baselines metric entries Add Larry's suggested table repair. Remove duplicate table entries prior to recreating the index as uniquue.
Compare: https://github.com/rhq-project/rhq/compare/368668667dbb...e7fd7c1c9ce5