MySQL Bugs: #41314: Many binlogs cause mysql::status info to arrive in 2nd discovery packet

Bug #41314	Many binlogs cause mysql::status info to arrive in 2nd discovery packet
Submitted:	9 Dec 2008 0:03	Modified:	14 Jan 2009 11:30
Reporter:	Adam Dixon	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Web	Severity:	S2 (Serious)
Version:	2.0.0.7102	OS:	Any
Assigned to:	MC Brown	CPU Architecture:	Any
Tags:	ChildDoesNotExistException

Description:
An installation with some 420+ master binlogs caused mysql::status graph to not be plotted at all.

- This is causing the mysql::status object to come in the 2nd discovery packet
- Where as it should be in the first,
- The dashboard handles out of order packets, but not if the information is split between them.

How to repeat:
Have many many master binlogs, or potentially many many tables or other objects might cause this too.

Suggested fix:
Handle this at agent or dashboard end correctly.

exclude processlist and masterlog items from list-instances discovery, as we don't and cannot use them.
this will (most likely) reduce the initial discovery packet to a reasonable size so that 
critical server components are reported together.

fix pushed to trunk.  awaiting merge to 2.0 maintenance tree for build.

A large processlist can also cause this same behavior.

Basically, mysql::processlist does the same thing as mysql::masterlog.

From the agent error log ...

<task>
   <taskId>9223372036854775789</taskId>
   <command>list_instances</command>
   <utc>2008-12-08T22:13:16.833Z</utc>
   <types>
    <type>
     <namespace>mysql</namespace>
     <classname>processlist</classname>
     <instances>
      <em2_instance>
       <instancename>7c2397f7-a086-49c3-b550-69c007d84979.2749055</instancename>
       <parent>
        <namespace>mysql</namespace>
        <classname>server</classname>
        <instancename>7c2397f7-a086-49c3-b550-69c007d84979</instancename>
       </parent>
      </em2_instance>

...

Many, many more <em2_instances> with the same uuid continue on ...

The only thing that changes is the number after the decimal point in <instancename>.

I also see the corresponding "ChildDoesNotExistException" entry in the catalina.out/stdout_*.log:

com.mysql.etools.exception.ChildDoesNotExistException: E2101: ChildDoesNotExistException: [{mysql}.{Server}.{7c2397f7-a086-49c3-b550-69c007d84979}, mysql.status, 7c2397f7-a086-49c3-b550-69c007d84979]

Verified fixed on 2.0.1.7125

An entry has been added to the 2.0 changelog:

Having an installation with over 420 master binlogs resulted in the mysql::status graph not being plotted.