+1 (non-binding) On Wed, May 25, 2016 at 8:20 AM, Ben Stopford <b...@confluent.io> wrote:
> +1 (non-binding) > > > On 25 May 2016, at 14:07, Ismael Juma <ism...@juma.me.uk> wrote: > > > > +1 (binding) > > > > I also think `log.cleaner.compaction.delay.ms` is clearer. As an aside, > I > > did notice that the topic level config for `log.segment.delete.delay.ms` > > (mentioned by Ewen) is `file.delete.delay.ms`, which seems a bit > > inconsistent. > > > > Ismael > > > > On Wed, May 25, 2016 at 4:43 AM, Ewen Cheslack-Postava < > e...@confluent.io> > > wrote: > > > >> +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 > >> > > -- Grant Henke Software Engineer | Cloudera gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
