Bug #31266 | Server cache issue causes seconds behind to be null instead of 0 | ||
---|---|---|---|
Submitted: | 28 Sep 2007 2:57 | Modified: | 16 Jun 2008 19:15 |
Reporter: | Bill Weber | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Enterprise Monitor: Server | Severity: | S3 (Non-critical) |
Version: | 1.2.0.7657 | OS: | Any |
Assigned to: | Eric Herman | CPU Architecture: | Any |
Tags: | mer 121 |
[28 Sep 2007 2:57]
Bill Weber
[2 Oct 2007 21:56]
Darren Oldag
synchronize the discovery of known items, in order to prevent duplicate schedules from being created for certain items. the duplicate schedules resulted in on collect_id being used for actual data collection, while the second collect_id was the one being used for SlaveStatus updates. since the second collect_id was never used for collection, the slave status was never updated. fixed in trunk -- awaiting review for push in into 1.2.x tree(s).
[3 Oct 2007 17:21]
Gary Whizin
Deferring to 1.2.1: it is rare, unlikely unless you start agents near the 5m mark, only a display problem (no rules or graphs affected), no data loss, and goes away on a Tomcat restart Note: found only in some QA tests that fire up agents in scripts; timing issue: adding delay between agent startup makes UI symptom go away
[8 Jan 2008 19:34]
Sloan Childers
This has been "In review" for quite some time now. Was a patch committed?
[14 Jun 2008 1:33]
Bill Weber
have not seen this in many moons
[16 Jun 2008 19:15]
Paul DuBois
No changelog entry needed. Bug report does not note that anything was done.