+1 (binding) Agreed that the log.cleaner.compaction.delay.ms is probably a better name, and consistent with log.segment.delete.delay.ms. Checked configs for other suffixes that seemed reasonable and despite only appearing in that one broker config, it seems the best match.
-Ewen On Tue, May 24, 2016 at 8:16 PM, Jay Kreps <j...@confluent.io> wrote: > I'm +1 on the concept. > > As with others I think the core challenge is to express this in an > intuitive way, and carry the same terminology across the docs, the configs, > and docstrings for the configs. Pictures would help. > > -Jay > > On Tue, May 24, 2016 at 6:54 PM, James Cheng <wushuja...@gmail.com> wrote: > > > I'm not sure what are the rules for who is allowed to vote, but I'm: > > > > +1 (non-binding) on the proposal > > > > I agree that the "log.cleaner.min.compaction.lag.ms" name is a little > > confusing. > > > > I like Becket's "log.cleaner.compaction.delay.ms", or something similar. > > > > The KIP describes it as the portion of the topic "that will remain > > uncompacted", so if you're open to alternate names: > > > > "log.cleaner.uncompacted.range.ms" > > "log.cleaner.uncompacted.head.ms" (Except that I always get "log tail" > > and "log head" mixed up...) > > "log.cleaner.uncompacted.retention.ms" (Will it be confusing to have the > > word "retention" in non-time-based topics?) > > > > I just thought of something: what happens to the value of " > > log.cleaner.delete.retention.ms"? Does it still have the same meaning as > > before? Does the timer start when log compaction happens (as it currently > > does), so in reality, tombstones will only be removed from the log some > > time after (log.cleaner.min.compaction.lag.ms + > > log.cleaner.delete.retention.ms)? > > > > -James > > > > > On May 24, 2016, at 5:46 PM, Becket Qin <becket....@gmail.com> wrote: > > > > > > +1 (non-binding) on the proposal. Just a minor suggestion. > > > > > > I am wondering should we change the config name to " > > > log.cleaner.compaction.delay.ms"? The first glance at the > configuration > > > name is a little confusing. I was thinking do we have a "max" lag? And > is > > > this "lag" a bad thing? > > > > > > Thanks, > > > > > > Jiangjie (Becket) Qin > > > > > > > > > On Tue, May 24, 2016 at 4:21 PM, Gwen Shapira <g...@confluent.io> > wrote: > > > > > >> +1 (binding) > > >> > > >> Thanks for responding to all my original concerns in the discussion > > thread. > > >> > > >> On Tue, May 24, 2016 at 1:37 PM, Eric Wasserman < > > eric.wasser...@gmail.com> > > >> wrote: > > >> > > >>> Hi, > > >>> > > >>> I would like to begin voting on KIP-58 - Make Log Compaction Point > > >>> Configurable > > >>> > > >>> KIP-58 is here: < > > >>> > > >>> > > >> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-58+-+Make+Log+Compaction+Point+Configurable > > >>>> > > >>> > > >>> The Jira ticket KAFKA-1981 Make log compaction point configurable > > >>> is here: <https://issues.apache.org/jira/browse/KAFKA-1981> > > >>> > > >>> The original pull request is here: < > > >>> https://github.com/apache/kafka/pull/1168> > > >>> (this includes configurations for size and message count lags that > will > > >> be > > >>> removed per discussion of KIP-58). > > >>> > > >>> The vote will run for 72 hours. > > >>> > > >> > > > > > -- Thanks, Ewen
