Hi Murali, Thanks for the KIP!
I'm not familiar with Streams so I'll pose a general question, open for anyone to answer: The configs that are being changed don't currently accept in-place overwrites in the code, so the "default.*" prefix doesn't make sense. Could there be a KIP to accept in-place overwrites in the future, such that the "default.*" prefix would make sense? If so, this KIP would make that other KIP harder to implement, as we would have already recommended everyone to move off of the "default.* prefix. Or to put it another way, this KIP closes doors rather than opening them. Or at least that's how it looks to a Streams outsider. I'm happy to defer to the experts in this case :) Thanks, Greg On Mon, Jun 10, 2024 at 3:47 PM Matthias J. Sax <mj...@apache.org> wrote: > Thanks for the KIP Murali, > > Overall LGTM. A few comments. > > > > 100: Config names are part of the public interface, and the KIP should > not say "none" in this section, but call out which configs are > deprecated and which ones are newly added. > > > 101: Nit. In "Propose Changes" there is the template placeholder text > > > Describe the new thing you want to do in appropriate detail. This may be > fairly extensive and have large subsections of its own. Or it may be a few > sentences. Use judgement based on the scope of the change. > > Similarly in "Test Plan" section > > Please remove both :) > > > 102: The "Deprecation" section should explain the behavior if both, old > and new configs, are set. > > > Thanks a lot! > > > -Matthias > > > On 6/9/24 9:30 PM, Muralidhar Basani wrote: > > Hello all, > > > > With this KIP > > < > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1056%3A+Remove+%60default.%60+prefix+for+exception+handler+StreamsConfig > >, > > I would like to mention that a couple of exception handler configs in > > StreamsConfig are defined as default configs, despite having no > alternative > > values. Hence would propose to deprecate them and introduce new configs > > without the 'default.' prefix. > > > > This KIP is briefly discussed here in the jira KAFKA-16853 > > <https://issues.apache.org/jira/browse/KAFKA-16863> too. > > > > I would appreciate any feedback or suggestions you might have. > > > > Thanks, > > Murali > > >
