+++ This bug was initially created as a clone of Bug #1135603 +++ Description of problem: I introduced the metrics_cache table in RHQ 4.12 as a way to reduce queries required during metrics data aggregation. This was intended as a performance optimization. It is described at https://docs.jboss.org/author/display/RHQ/Aggregation+Schema+Changes. I have learned in part from community feedback (i.e., Elias Ross), that the gains are often minimal because there are not tight groupings of schedule ids. More importantly the new table causes higher heap usage which can result in lots of alert notifications especially for default installations. This could be problematic for a lot of users who run only a single, co-located storage node along side the server. We are better of dropping the table. I think rhq-metrics would be a more appropriate place to explore changes like this. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Note that the metrics_cache table is not in JON. It was first introduced in RHQ 4.12. We need this bug though because code changes are needed in the release/jon3.3.x branch.
The work for this is covered by bug 1135629. Moving to MODIFIED.
Moving to ON_QA as available for test with the following brew build: https://brewweb.devel.redhat.com//buildinfo?buildID=385149
For verification we need to make sure that there are no regressions with new installations as well as with upgrades. The metrics_cache table should not existing in the rhq keyspace. This can be checked from cqlsh with the following command, DESCRIBE KEYSPACE rhq
Verified on JON 3.3 ER03 with new installation and upgrade. The metrics_cache table does not exist in rhq keyspace.