speaking of pending KIPs, what's the status on this one?
On Fri, Mar 18, 2016 at 9:47 PM, Ashish Singh <asi...@cloudera.com> wrote: > Hey Jay, > > Answers inline. > > On Fri, Mar 18, 2016 at 10:45 AM, Jay Kreps <j...@confluent.io> wrote: > > Hey Ashish, > > > > Couple quick things: > > > > 1. You list as a rejected alternative "making the documentation the > > source of truth for the protocol", but I think what you actually > > describe in that section is global versioning, which of those two > > things are we voting to reject? I think this is a philosophical point > > but an important one... > > > One of the major differences between Option 3 and other options discussed > on KIP is that Option 3 is documentation oriented and it is that what I > wanted to capture in the title. I am happy to change it to global > versioning. > > > > 2. Can you describe the changes necessary and classes we'd have to > > update in the java clients to make use of this feature? What would > > that look like? One concern I have is just the complexity necessary to > > do the per-connection protocol version check and really handle all the > > cases. I assume you've thought through what that looks like, can you > > sketch that out for people? > > > I would imagine any client, even Java client, would follow the steps > mentioned here > < > https://cwiki.apache.org/confluence/display/KAFKA/KIP-35+-+Retrieving+protocol+version#KIP-35-Retrievingprotocolversion-Aclientdeveloperwantstoaddsupportforanewfeature.1 > >. > Below are my thoughts on how java client can maintain api versions > supported by various brokers in cluster. > > 1. ClusterConnectionStates can provide info on whether api versions have > been retrieved for a connection or not. > 2. NetworkClient.handleConnections can send ApiVersionQueryRequest to > newly connected nodes. > 3. NetworkClient can be enhanced to handle ApiVersionQueryResponse and > set ClusterConnectionStates to indicate api versions have been retrieved > for the node. > 4. NetworkClient maintains mapping Node -> [(api_key, min_ver, > max_ver)], brokerApiVersions, cached. > 5. NetworkClient.processDisconnection can remove entry for a node from > brokerApiVersions cache. > 6. NetworkClient.canSendRequest can have an added condition on node to > have api versions available. > > With the above changes, at any given point of time NetworkClient will be > aware of api versions supported by each of the connected nodes. I am not > sure if the above changes are the best way to do it, people are welcome to > pitch in. Does it help? > > > > -Jay > > > > On Mon, Mar 14, 2016 at 3:54 PM, Ashish Singh <asi...@cloudera.com> > wrote: > > > Hey Guys, > > > > > > I would like to start voting process for *KIP-35: Retrieving protocol > > > version*. The KIP is available here > > > < > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-35+-+Retrieving+protocol+version > > >. > > > Here > > > < > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-35+-+Retrieving+protocol+version#KIP-35-Retrievingprotocolversion-SummaryofthechangesproposedaspartofthisKIP > > > > > > is a brief summary of the KIP. > > > > > > The vote will run for 72 hours. > > > > > > -- > > > > > > Regards, > > > Ashish > > > > -- > > Regards, > Ashish >
