Hi Harsha,
Comments inline.
On Fri, Apr 12, 2019 at 8:22 PM Harsha wrote:
> Hi Ismael,
> I meant to say blocking clients based on their API version
> https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/api/ApiVersion.scala#L48
> But If I understand what you are sayi
Hi Gwen & Ismael,
Do you have any feedback on with the proposed approach,
min.api.version allowing users to specify versions for every request.
Thanks,
Harsha
On Fri, Apr 19, 2019, at 10:24 AM, Harsha wrote:
> Thanks Ying for updating the KIP.
> Hi Ismael,
> Give
Thanks Ying for updating the KIP.
Hi Ismael,
Given min.api.version allows admin/users to specifiy min.version
for each request this should address your concerns right?
Thanks,
Harsha
On Wed, Apr 17, 2019, at 2:29 PM, Ying Zheng wrote:
> I have updated the config description in the
I have updated the config description in the KIP, made the example more
clear
The proposed change allows setting different min versions for different
APIs, and the ApiVersionRequest change is already in the KIP.
On Fri, Apr 12, 2019 at 8:22 PM Harsha wrote:
> Hi Ismael,
> I meant to
Hi Ismael,
I meant to say blocking clients based on their API version
https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/api/ApiVersion.scala#L48
But If I understand what you are saying, since each client release can support
different versions for each of fetch, pr
Hi Harsha,
There is no such thing as 1.1 protocol. I encourage you to describe an
example config that achieves what you are suggesting here. It's pretty
complicated because the versions are per API and each client evolves
independently.
Ismael
On Sat, Apr 13, 2019 at 4:09 AM Harsha wrote:
> Hi
Hi,
"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
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 c
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 som
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-conversi
Hi Gwen,
Thank you very much for the feedback! I have updated the KIP.
"reject request" means return an UNSUPPORTED_VERSION (35) error. Client
libraries after 0.10.2 will show the message "The version of API is not
supported." Client libraries before 0.10.2 will treat this error as an
unknown ser
In general, I support this proposal, but I'd like some more details on what
"rejecting API requests" mean? Close the connections? Return some kind of
error? Is there a way for the client to know what happened? Is there a way
for the admin to know how many clients are rejected?
As a nit, the "migra
Hi here,
Please vote for
https://cwiki.apache.org/confluence/display/KAFKA/KIP-433%3A+Block+old+clients+on+brokers
Thank you!
13 matches
Mail list logo
