Hi Ying, The actual reasons are important so that people can evaluate the KIP (and vote). :) Thanks for providing a few more:
(1) force users to check pointing in Kafka instead of zookeeper (2) forbid an old go (sarama) client library which is known to have some serious bugs (3) force kafka 1.x clients with the ability to roll back if there's an issue (unlike a message format upgrade) Relying on min.version seems like a pretty clunky way to achieve the above list. The challenge is that it's pretty difficult to do it in a way that works for clients across languages. They each add support for new protocol versions independently (it could even happen in a bug fix release). So, if you tried to block Sarama in #2, you may block Java clients too. For #3, it seems simplest to have a config that requires clients to support a given message format version (or higher). For #2, it seems like you'd want clients to advertise their versions. That would be useful for multiple reasons. Ismael On Fri, Apr 12, 2019 at 8:42 PM Ying Zheng <yi...@uber.com.invalid> wrote: > Hi Ismael, > > Those are just examples. I think the administrators should be able to block > certain client libraries for whatever reason. Some other possible reasons > include, force users to check pointing in Kafka instead of zookeeper, > forbid an old go (sarama) client library which is known to have some > serious bugs. > > message.downconversion.enable does not solve our problems. We are now > planning to upgrade to message format V3, and force users to upgrade to > Kafka 1.x clients. With the proposed min.api.version setting, in case of > there is anything wrong, we can roll back the setting. If we upgrade the > file format, there is no way to rollback (Kafka doesn't support downgrading > message format). > > On Thu, Apr 11, 2019 at 7:05 PM Ismael Juma <ism...@juma.me.uk> wrote: > > > Hi Ying, > > > > It looks to me that all the examples given in the KIP can be handled with > > the existing "message.downconversion.enable" config and by configuring > the > > message format to be the latest: > > > > 1. Kafka 8 / 9 / 10 consumer hangs when the message contains message > header > > > ( KAFKA-6739 - Down-conversion fails for records with headers > RESOLVED ) > > > 2. LZ4 is not correctly handled in Kafka 8 and Kafka 9 ( KAFKA-3160 - > > > Kafka LZ4 framing code miscalculates header checksum RESOLVED ) > > > 3. Performance penalty of converting message format from V3 to V1 or V2 > > > for the old consumers (KIP-31 - Move to relative offsets in compressed > > > message sets) > > > > > > Am I missing something? Are there other examples that are not related to > > message conversion? > > > > Ismael > > > > On Thu, Apr 11, 2019 at 11:53 PM Ying Zheng <yi...@uber.com.invalid> > > wrote: > > > > > Hi here, > > > > > > Please vote for > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-433%3A+Block+old+clients+on+brokers > > > > > > Thank you! > > > > > >
