Update Broker service configuration dynamically - #186
Conversation
e7ba703 to
206ba5d
Compare
merlimat
left a comment
There was a problem hiding this comment.
Change looks good. A couple of comments:
-
We should make very clear that the configuration in ZK overrides whatever is on the host config file. Eg: when we startup we should printing info log of what config we found on ZK
-
We should have 2 way of using dynamic fields
- Either we keep reading the value from ServiceConfiguration and thus at some point we pick up the updated value. We don't need mutexes, since there's no strict requirement on change visibility.
- Or we register the listener
There was a problem hiding this comment.
Typo in updateServiecConfiguration
There was a problem hiding this comment.
Instead of doing the reflection check on each request, could we doing just once (at startup) and keep a Set<> of keys that are dynamically updatable?
There was a problem hiding this comment.
I'd leave this PR to implement the "mechanism" and then we can make the actual variables dynamic in subsequent PRs.
There was a problem hiding this comment.
Yes, but in order to write test-cases and perform testing of this feature I take one of this simple attribute in this PR. It helps to write e2e testcases for this feature.
There was a problem hiding this comment.
can abbreviate into a lambda here
There was a problem hiding this comment.
Actually, for this example, we shouldn't even need to register for notification, right?
We should make sure that the value ServiceConfiguration instance is updated, and then always read it from there, instead of caching it in a variable.
There was a problem hiding this comment.
Actually, for this example, we shouldn't even need to register for notification, right?
Actually, we are not updating ServiceConfiguration instance's field value but we are calling registered listener for this field and it's registered-listener's responsibility to update the value and take appropriate action.
Because in case of #181 : Only when lookupRequestPermits field-value changes we want to take certain action such as update Semaphore's permits. Now, we have watch on entire dynamicConfigMap and listener can be triggered on every configKey-value change. So, registered listener can compare existing value and new value, and if it's changed then it can take appropriate action and update ServiceConfiguration.
There was a problem hiding this comment.
addressed it on commit can you please take a look of it.
There was a problem hiding this comment.
Can we make the listener to be working for string, ints, longs? (Maybe leveraging the FieldParser)
There was a problem hiding this comment.
yes, but we can have non-primitive ParameterizedTypes also for which we have to pass Field to parse the value. So, made appropriate change.
There was a problem hiding this comment.
We should print a info log line, for all the overridden variables
There was a problem hiding this comment.
we've been using - as separator in other commands. eg: update-config
3593728 to
f4adac9
Compare
|
@merlimat : addressed all the changes, added one more change: |
merlimat
left a comment
There was a problem hiding this comment.
Change looks very good, just a couple of minor comments
There was a problem hiding this comment.
Can we also add a command to get the list of "updatable" config fields?
There was a problem hiding this comment.
Also, it would be useful to have command to print all the config that are stored in ZK. To know what is being overridden.
There was a problem hiding this comment.
added both commands:
- getUpdatableConfigName
- getAllConfigurations to get key,value for all configs
There was a problem hiding this comment.
Instead of "updating" configuration, in this case we would be effectively "overriding" the local broker configuration with a "more important" configuration stored in ZK
There was a problem hiding this comment.
so, you mean we should rename the method to overrideDynamicConfiguration or we want to make any functionality change?
There was a problem hiding this comment.
Just renaming. I'm not 100% sure about the name, just wanted to make clear that it doesn't update the config in a broker, rather it writes config in ZK that supersedes whatever all the brokers have locally.
There was a problem hiding this comment.
updateDynamicConfigurationInZk, persistDynamicConfigValue, storeDynamicConfigValue ?
There was a problem hiding this comment.
I have updated the document to call it out clearly and also renamed it as updateDynamicConfiguration. Do you think if we rename it to something else.?
There was a problem hiding this comment.
The notification from ZK might be delayed in the background thread. In addition since we're doing "dirty" reads (avoid synchronization), it might take a bit more after the new value is visible on the getter method. We should have a retry loop here in the test to give a bit of time.
There was a problem hiding this comment.
I have added this logic in testUpdateDynamicConfigurationWithZkWatch.
This test-case directly triggers registerListener because pulsarService started when znode was not created and can't set the watch if node is not exist. so, in this testcase it explicitly triggers registerListener call.
There was a problem hiding this comment.
Ok, tough is there also the other test that work with the zk watch and verifies we apply the change?
There was a problem hiding this comment.
yes, testUpdateDynamicConfigurationWithZkWatch first creates znode and any further config change happens by zk-watch. I have added retry loop there to wait for refreshed value.
There was a problem hiding this comment.
Can we verify that shutdown time is != 10 in the initial config?
224004d to
67a124e
Compare
691ccb0 to
012a47b
Compare
* Expose EventTime consistently as a non-pointer * Expanded docs
Motivation
as discussed at #184 : sometime it requires to update Broker-serviceConfiguration dynamically with the help of generic api.
Modifications
Result
Broker can update serviceConfiguration dynamically and can execute appropriate action on configuration-value change.