Invalid Monitor Rule Type

What are you passing in for the MonitorRuleType?

Here's the function prototype:

enum MonitorRuleType {
  MONITOR_RULE_TYPE_UNDEFINED,
  MONITOR_RULE_TYPE_NONE,
  MONITOR_RULE_TYPE_SINGLE,
  MONITOR_RULE_TYPE_AND_LIST,
  MONITOR_RULE_TYPE_M_OF_N,
};
struct MonitorRule {
  MonitorRuleType type;
  long quorum;
  String [] monitor_templates;
};
struct MonitorAssociation {
  String pool_name;
  MonitorRule monitor_rule;
};
void LocalLB::Pool::set_monitor_association(
  MonitorAssociation[] monitor_associations
);

If you pass in a value of MONITOR_RULE_TYPE_UNDEFINED, or MONITOR_RULE_TYPE_NONE for the MonitorRuleType value the "Invalid Monitor Rule Type" error message will be returned. Use one of the valid values and you should be all set.

In the future, if you are having issues with the APIs, if you could include in your post the relevant parameters you are using that would help us to help you better. Otherwise, it's all guesswork.

-Joe

Joe,

 

Sorry I didnt mean for it to be guess work.

 

Basically the order of events is this:

 

1.Create a monitor (in this case HTTP type)

 

2. Following is code +psuedocode:

 

LocalLBPoolBindingStub _binding...

 

LocalLBPoolMonitorAssociation monitors[] = new LocalLBPoolMonitorAssociation[1];

 

LocalLBMonitorRule rule = new LocalLBMonitorRule();

 

LocalLBServiceDownAction[] actions = new LocalLBServiceDownAction[1];

 

 

monitorNames[0] = + "_monitor";

 

//the above monitor is an HTTP monitor created successfully

 

rule.setMonitor_templates(monitorNames);

 

monitors[0] = new LocalLBPoolMonitorAssociation();

 

monitors[0].setPool_name(;

 

monitors[0].setMonitor_rule(rule);

 

poolNames[0] = ;

 

actions[0] = LocalLBServiceDownAction.SERVICE_DOWN_ACTION_RESELECT;

 

 

_binding.set_monitor_association(monitors);

 

_binding.set_action_on_service_down(poolNames, actions);

 

 

 

Hope this makes some sense!!

 

You are not initializing the rule variable. You will need to fill in it's type, quorum, and monitor_templates variables to your specifics.

 

 

Type can be one of the following:

 

 

MONITOR_RULE_TYPE_SINGLE - This monitor rule is based on a single monitor.

 

MONITOR_RULE_TYPE_AND_LIST - This monitor rule is based on an ANDed list of monitors, i.e. all monitors must return successfully for the node/member to be considered UP.

 

MONITOR_RULE_TYPE_M_OF_N - This monitor rule is based on a list of N monitors, but at least M of which must return successfully for the node/member to be considered UP.

 

 

If you are just using one monitor, then MONITOR_RULE_TYPE_SINGLE is probably what you want. Pass that in for the type, with a quorum value of 0 (ignored) as well as the name of your HTTP monitor in the monitor_templates list.

 

 

If you want to support chaining multiple monitors to this rule, then you'll have to use MONITOR_RULE_TYPE_AND_LIST if you want require all monitors to succeed to consider it a pass, or MONITOR_RULE_TYPE_M_OF_N if you want say 2 out of 3 passes to consider a success.

 

 

Hope this helps...

 

 

-Joe

Joe,

 

Thank you for the prompt replies. The code below worked well all these days and suddenly now it has given the error. I am also trying to figure out what the configuration on BigIP was for that specific case.

 

My question now is what is the general case scenario if I do not know in advance the number of possible monitors and in what combination they are required to ensure that the node is UP. It seems that the rule was not initialized for that particular reason. By the way, I am doing a bug fix on someone else's code.

 

I see your point regarding the rule not being initialized, but if it was working all these days, then what could have caused the error now?

 

 

I guess I just need to see the entire context.

 

Thanks,

 

Pallavi

Honestly, I have no clue how it has worked. I just looked at the code and if the value of the rule type is not specifically one of MONITOR_RULE_TYPE_SINGLE, MONITOR_RULE_TYPE_AND_LIST, or MONITOR_RULE_TYPE_M_OF_N then this error is thrown. I don't see how your client code could have defaulted to one of these values before and not now. You might want to print out the value of the rule type from the uninitialized value and see what it shows. It probably defaults to the first possible value of MONITOR_RULE_TYPE_UNDEFINED which equates to zero in the enum.

 

 

I guess I don't understand your question about not knowing the number of monitors. You will have to know at least one or why would you be calling the set_monitor_associations() method in the first place? If at a later time, you need to add other monitors to the rule, you would call set_monitor_associations() again with the updated list of monitors. As for an ordering, I'm not sure if there is an enforced ordering in the monitor list. I believe they are just all executed and their successes are combined.

 

 

-Joe

The mystery of how it worked before will never be really solved I guess. Thank you for the input on the other aspects.

 

-Pallavi

Anytime...

 

 

-Joe