-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SAI-4731 : supporting feature flag in solr #180
base: fs/branch_9_3
Are you sure you want to change the base?
Conversation
@noblepaul looks like host level support is not there yet? |
per node properties ar implemented |
(Map<String, Object>) | ||
Utils.fromJSONString( | ||
"{\n" | ||
+ " \"watched-node-properties\" :{\n" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What all way we can define this?
- Can we differentiate between two components? (say, component-x, component-y)
- Can we define prop for component-x (node-level, otherwise-all, just-for-all) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not per component, it's just a property per node. May be we can prefix a component name in the property key
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need three cases here
- One can define properties at component level. While registering watch take
component-name
, if same exists then through the exception. - Component will register default value, which we can update through ZK (or maybe later nice solr api)
2.1. We can update component1-prop in ZK with node name, saying apply this value for that node. Then we should call listener for that component on that node only.
Side node, recently we introduced this behavior in prod, where we updated max-basic-queries limit on one solr-node. We watched that node for ~4/5 weeks and now we ready to update this limit on all the nodes. This solution require whole cluster restart, that's why we are looking for this feature in solr. Hope this will help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for example , if there is a property component-a.property-x
that component may watch that property explicitly at load time. if no other component has registered a watch on that property, then no callbacks are given to other components. Am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
f there is a property component-a.property-x that component may watch that property explicitly at load time.
As long as component is registered, it should get callback. do you think it should register property as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is no concept of a "component" is Solr. So, the system would not know whom to give a callback if it does not explicitly register for a callback
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just name
if we need to use feature flag. watch("test1", listener)
for (String k : newData.keySet()) { | ||
if (knownData.containsKey(k)) continue; | ||
isModified = true; | ||
invokeListener(k, newData.get(k), propertiesListeners); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if prop is set for node1, then we need to invoke listener on that node only
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that is what it does. You register the watcher from within a node and listeners are fired for the properties of that node only
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will happens we update the property in ZK, will that cause listener-update-event on each node or all node?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you mean by each node and all node?
everyone who registered a listener should get a callback
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For example I want these property value for this node only
{
component: "basiclimit", host:solr-1,property-x:value-y
}
Then this should be invoked on host solr-1 only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when the property is defined for solr-1
, you get a calback on solr-1
only.
It would look something like this. Inside a node, you can only watch properties of that node
{
"watched-node-properties" :{
"solr-1" : {
"basiclimit.property-x":"value-y"
}
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, let's give demo on this in Monday's sync. thanks!
…to both global and node property. if the same property is present in global and node values, global value is ignored
@noblepaul let's plan for updated demo on Monday's sync |
sample code