Re: Review request for KAFKA-3600

I am open to any forum for design discussions. I had run this by Jason and gotten some feedback, four months back. I have addressed those feedbacks, and I believe not much have changed since then in the design. I would love to have more feedback. - do we want to modify the state machine?

Re: Review request for KAFKA-3600

In general, I believe it is good to have design discussions in the mailing list (do we want to modify the state machine? do we need to maintain version per connection? which layer is responsible for the API check)? PR works well with tactical issues (class / object / method level) but less so for

Re: Review request for KAFKA-3600

Hello Dana, Thanks for the feedback. Kafka-3600 is not intended to address backwards compatibility of clients. Backwards compatibility of clients is a lengthier discussion and it will be better to take it on a separate KIP. We initiated that discussion on KIP-35's discuss thread and it was hard t

Re: Review request for KAFKA-3600

I think one of the hard parts is that while we agree that a call to ApiVersions is required, I don't think there is agreement on how to use the response. In kafka-python, for example, to support backwards compatibility we set a single "api" configuration value during the client constructor. This v

Re: Review request for KAFKA-3600

Most of the work in the patch is to enhance NetworkClient to maintain api versions supported by brokers it has connections to. When a broker disconnects, its api versions info is removed and when it reconnects that info is fetched again. In short, with these changes Network Client at any given poin

Re: Review request for KAFKA-3600

I am 100% pro smart Java clients that support KIP-35 and can use it to work with newer brokers. If this JIRA makes sense as a step in that direction, I think its great and remove my objection. I didn't see anything that looked like a plan toward full forward-backward compatibility, which is why I

Re: Review request for KAFKA-3600

Hey Gwen, I think this was more than a verification step, it was a building step towards a backwards compatible clients or for clients that can select feature based on brokers it is talking to. Are we now against the idea of having smarter clients? This adds complexity to enable clients to inform

Re: Review request for KAFKA-3600

I hate doing this, because Ashish has really been good about following up on the PR, but I'm questioning the usefulness of this patch. It adds non-trivial complexity to the client... with not much return on the investment, as far as I can see? When I first suggested it, it was before KIP-35 was me

Re: Review request for KAFKA-3600

Provided wrong link to PR, here is the PR for KAFKA-3600. On Tue, Aug 9, 2016 at 9:45 AM, Ashish Singh wrote: > Hey Guys, > > KAFKA-3600 was part of > KIP-35's proposal. KAFKA-3307 >

Review request for KAFKA-3600

Hey Guys, KAFKA-3600 was part of KIP-35's proposal. KAFKA-3307 , adding ApiVersionsRequest/Response, was committed to 0.10.0.0, but KAFKA-3600, enhancing java clients, is still under review. Here i