MySQL Bugs: #51095: Deleting instance fails when OS rules scheduled with no alarms/eval results

Bug #51095	Deleting instance fails when OS rules scheduled with no alarms/eval results
Submitted:	11 Feb 2010 13:54	Modified:	2 Mar 2010 10:54
Reporter:	Mark Leith	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Server	Severity:	S2 (Serious)
Version:	2.1.1.1141	OS:	Any
Assigned to:	Darren Oldag	CPU Architecture:	Any
Tags:	windmill

Description:
If you have a custom rule with OS data within it scheduled for an instance, and then subsequently try and remove that instance, on restart of the dashboard server the instance reappears as "unknown".

How to repeat:
o Create a custom rule, I used:

Name: Custom Rule
Advisor: Custom
Version: 1.0
Expression: %swap_in% > THRESHOLD
Critcal Threshold: 0
Variable: os:mem:swap_page_in Name: %swap_in% Instance: mem
Description: Swapping == %swap_in%

o Schedule this rule against an instance
o Stop the agent
o Delete the server
o Restart the Dashboard server
o The instance will be back as "unknown"

Logs from the app for the delete server - note that no os inventory is removed for the instance

Attachment: delete_server_os_custom_rules.txt (text/plain), 15.24 KiB.

Now verified:

o Start an agent, allow it to check in
o Stop the agent
o Schedule the "Key Buffer Size May Not Be Optimal For System RAM" rule (or any other with OS variables)
o Delete the instance
o Restart tomcat
o Check for the "unknown" server

Darren Oldag writes: 
root cause:  scheduling a variable-less rule made the rule schedule NEVER show up again due to eager inner join fetching.  see commit message below for fix.

fix has been pushed to trunk (2.2 as of this writing).  it is easily ported to 2.1 if we so desire, but i'm leaving the issue alone for now to see if the 'create a variable for the rule' workaround is good enough.

-----------------------------------------------------------------------------------------------

revision-id: oldag@mysql.com-20100216180314-mmcig9qoheqn3jxf
parent: oldag@mysql.com-20100216160708-nbc2mpm7rh15y42t
committer: Darren L. Oldag <oldag@mysql.com>
branch nick: Trunk
timestamp: Tue 2010-02-16 12:03:14 -0600
message:
  the query to find rule schedules was joining against the
  variables, but if no variables existed -- it would return zero results.
  
  so...
  
  when eager fetch joining related collections, you should always
  LEFT JOIN fetch them, so that if the associated collection is empty,
  it doesn't prevent persistent objects from showing up.
  
  there should be a second fix at the business layer to prevent variable-less
  rules from ever existing, but persistence shouldn't really care and should
  be robust anyway.

Darren Oldag writes: 
revision-id: oldag@mysql.com-20100216215744-p0h4ek3oc2fgyto1
parent: merlin@dl380-g5-a.mysql.com-20100209173306-im08it86pzj7rzce
committer: Darren L. Oldag <oldag@mysql.com>
branch nick: Monitor21
timestamp: Tue 2010-02-16 15:57:44 -0600
message:
  merge of trunk fix to left join fetch the rule schedule associations
  so that variable-less (or alarmless, for that matter) rule schedules
  are still returned from persistence.

Keith Russell writes: 
Patch installed in versions => 2.2.0.1628.

Bill Weber writes: 
can't reproduce this with either 2.1.2.1156 or 2.2.0.1633

A note has been added to the 2.1.2 and 2.2.0 changelog