allow key deletion to trigger configuration refresh #781
Conversation
|
can somebody approve the initial code check workflow to run? |
|
@spencergibb could you take a look and approve it? |
|
@marcingrzejszczak @ryanjbaxter hi, could you take a look? |
|
Please be patient |
|
I approved the checks, you have checkstyle errors |
|
Hi Ryan, many thanks, I fixed checkstyle errors. BTW, the unit test currently has a minor problem on a slow machines, I also put a comment into the unit test. |
There was a problem hiding this comment.
Looks OK to me. Lets see what @spencergibb thinks once he has a chance to look at it
|
@ryanjbaxter I am working on another PR, similar to this one, there are some checkstyle errors on some classes that I did not touch. I need to fix them even they are unrelated and untouched, right? |
|
I dont see how that would be possible, that would imply that there are checkstyle errors in the code and if that was the case our builds would be failing because of them. I just checked and our builds are all green. |
|
@ryanjbaxter I am thinking exactly the same as you. Anyway, just curious but it's not a big deal, I have fixed them all in another PR. |
|
I also think we are at odds with #223. What would be the difference between a prefix not existing and a key deletion? |
see #780
Adding/changing a key triggers refreshing values for Environment and @value. But deleting a key does not. This is a strange behavior. e.g., you have two paths to watch in Consul: /default/config and /my-service/config, if I add a key to my-service/config I can override the default settings in /default/config, but when I delete the key, nothing happens and I have to restart my app.
Moreover, when I delete a key, in ConfigWatch.watchConfigKeyValues(), the index will stop increasing. Suppose you get an index 16866 previously, then for the deletion event we should increase the current index to the new index in the response, maybe 16914. Currently the watch just stops at 16866 and retry and retry over again. If you set timeout shorter to 3 second you will see this busy loop behavior from log. Without increasing the index, it's a little less efficient and we will waste some resources.
I think the problem is, when 404 with a higher index is returned, it means the key was deleted, and we should publish the RefreshEvent and increase the index. Then the spring config framework should listen to the event and change accordingly, maybe delete the key from ConsulPropertySource.