Hi Ashish, Comments inline.
On Mon, Mar 14, 2016 at 6:15 PM, Ashish Singh <asi...@cloudera.com> wrote: > I think ApiVersion aims to identify protocol version changes, more than > release change, > > https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/api/ApiVersion.scala#L30 > . > That is something that has changed as part of KIP-31/32 (as I mentioned), it wasn't like that in 0.9.0.x for example: https://github.com/apache/kafka/blob/0.9.0/core/src/main/scala/kafka/api/ApiVersion.scala#L21 > I do agree that having an automated check to ensure this happens will be > really useful. > Great. > My understanding is that this doesn't help clients that support KIP-35 > > since they will know the broker version. And for older clients, they will > > fail with a parsing exception, which is a bit better, but not much > better. > > So, is it really worth doing? In the KIP call we had about this months > ago, > > there was no consensus on this one from what I remember. > > > That is a good point! However, what about a client that wants to support > broker versions that do not provide broker version in metadata and broker > versions that provides version info in metadata. I think having this does > not cost us anything, but enables such clients to be smart. > I don't see how it helps. If the client is communicating with a broker that does not support KIP-35, that broker will simply close the connection. If the broker supports KIP-35, then it will provide the broker version. I don't envisage a scenario where a broker does not support KIP-35, but implements the new behaviour of sending an empty response. Do you? Ismael
