Support Migration Notice: To update migrated JIRA cases click here to open a new case use www.vmware.com/go/sr | vFabric Hyperic 5.7.0 is Now Available

Hyperic HQ

Mysql Stats plugin getting wrong values if same table name exists on multiple databases

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Deferred
  • Affects Version/s: 4.6
  • Fix Version/s: None
  • Component/s: Plugins
  • Case Links:
    none
  • Regression:
    No

Description

When MySQL Stats 5.1.x server resource is created all tables are discovered using 'tableRegex' config option on a server level. Service resources(tables) are mapped to correct instance using 'table' and 'database' config options.

I have a multiple databases(catalogs) per mysql. Basically one database per HQ version(e.g. HQ45, HQ46, HQ4601, etc). Below table service resources will be created:
'db stats HQ45/HQ_METRIC_DATA_0D_0S'
'db stats HQ46/HQ_METRIC_DATA_0D_0S'
'db stats HQ4601/HQ_METRIC_DATA_0D_0S'

org.hyperic.hq.plugin.mysql_stats.MySqlStatsMeasurementPlugin.getTableMetric(Metric) is using _tableStatusCacheMap to cache queries. Local cache key contains jdbcurl postfixed by a table name:

final String table = metric.getObjectProperty("table");
final String dbname = metric.getObjectProperty("database");
final String cacheKey = jdbcUrl "-" table;
JDBCQueryCache tableCache = (JDBCQueryCache)_tableStatusCacheMap.get(cacheKey);

When metrics are collected per table resource there's only one instance of MySqlStatsMeasurementPlugin created. Just to make this clear, this is going to be a shared instance, no separate instances(MySqlStatsMeasurementPlugin Object) are used. This is a normal logic how MeasurementPlugin works with same type of services under a server resource.

I believe this local caching would work if cache key would be postfixed with table name and database name. Something like:
final String cacheKey = jdbcUrl "-" table + dbname;

Activity

Hide
Idan Hod added a comment -

As part of our continuous effort to improve product quality, The Hyperic product team has decided to implement a "zero bug policy" methodology.

Following this methodology, only defects that are planned to be handled in the near future will remain open. Any other defect will be deferred, with the option to be reevaluated if the need arises, or if changes to the Hyperic road-map make such defect a candidate for a fix.

We believe this new process will help create clarity and focus in the Hyperic road-map and ultimately benefit our customer base.

This bug has been deferred as part of the new policy.

We appreciate your cooperation and continues contribution to the improvement of Hyperic.

Show
Idan Hod added a comment - As part of our continuous effort to improve product quality, The Hyperic product team has decided to implement a "zero bug policy" methodology. Following this methodology, only defects that are planned to be handled in the near future will remain open. Any other defect will be deferred, with the option to be reevaluated if the need arises, or if changes to the Hyperic road-map make such defect a candidate for a fix. We believe this new process will help create clarity and focus in the Hyperic road-map and ultimately benefit our customer base. This bug has been deferred as part of the new policy. We appreciate your cooperation and continues contribution to the improvement of Hyperic.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
    Last comment:
    40 weeks, 5 days ago