kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luis Cabral <luis_cab...@yahoo.com.INVALID>
Subject Re: [VOTE] KIP-280: Enhanced log compaction
Date Fri, 15 Jun 2018 08:40:59 GMT
Hi,

bq. Can the value be determined now ? My thinking is that what if there is a third compaction
strategy proposed in the future ? We should guard against user unknowingly choosing the 'future'
strategy.

The idea is that the header name to use is flexible, which protects current clients that may
want to use this from having to adapt their already existing header names (they can just specify
a new name).

bq. Shouldn't the selection in header have higher precedence over the configuration ?

Not sure what you mean here, could you clarify?

bq. Please create JIRA if you haven't already.

Done: https://issues.apache.org/jira/browse/KAFKA-7061

Cheers,
Luís 

> On 11 Jun 2018, at 01:50, Ted Yu <yuzhihong@gmail.com> wrote:
> 
> bq. When this configuration is set to anything other than "*offset*" or "
> *timestamp*", then the record headers are scanned for a key matching this
> value.
> 
> Can the value be determined now ? My thinking is that what if there is a
> third compaction strategy proposed in the future ? We should guard against
> user unknowingly choosing the 'future' strategy.
> 
> bq. If this header is found
> 
> Shouldn't the selection in header have higher precedence over the configuration
> ?
> 
> Please create JIRA if you haven't already.
> 
> Thanks
> 
> On Sat, Jun 9, 2018 at 12:39 AM, Luís Cabral <Luis_Cabral@yahoo.com.invalid>
> wrote:
> 
>> Hi all,
>> 
>> Any takers on having a look at this KIP and voting on it?
>> 
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
>> 280%3A+Enhanced+log+compaction
>> 
>> Cheers,
>> Luis
>> 


Mime
View raw message