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! > > >
