> > The proposed change relies on a file watch, why not also have a polling > > interval to check the file for changes? > > > > The periodical check could work, the slight downside is that we need > additional configurations to schedule the interval. Do you think the > file-watch approach has any extra overhead than the interval based solution?
I don't think so. The reason I'm asking this is the KIP currently includes: "When the file watch does not work for unknown reason, user could still try to change the store path in an explicit AlterConfig call in the worst case." Having the interval in addition to the file watch could result in a better worst case scenario. I understand it would require introducing at least one new configuration for the interval, so maybe this doesn't have to solved in this KIP. -- Igor On Fri, Dec 4, 2020, at 5:14 PM, Boyang Chen wrote: > Hey Igor, thanks for the feedback. > > On Fri, Dec 4, 2020 at 5:24 AM Igor Soarez <i...@soarez.me> wrote: > > > Hi Boyang, > > > > > > What happens if the file is changed into an invalid store? Does the > > previous store stay in use? > > > > If the reload fails, the previous store should be effective. I will state > that in the KIP. > > > > Thanks, > > > > -- > > Igor > > > > On Fri, Dec 4, 2020, at 1:28 AM, Boyang Chen wrote: > > > Hey there, > > > > > > I would like to start the discussion thread for KIP-687: > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-687%3A+Automatic+Reloading+of+Security+Store > > > > > > This KIP is trying to deprecate the AlterConfigs API support of updating > > > the security store by reloading path in-place, and replace with a > > > file-watch mechanism inside the broker. Let me know what you think. > > > > > > Best, > > > Boyang > > > > > >
