On Mon, Mar 14, 2016 at 8:45 PM, Gwen Shapira <g...@confluent.io> wrote:
>
> > 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?
> >
> > Are you sure about that? Per KIP-35, the broker supplies the version in
> response to Metadata request, not in response to anything else.
> If the client sends producer request version 42 (accidentally or due to
> premature upgrade) to KIP-35-compactible broker - we want to see an empty
> packet and not a connection close.
> Sending a broker version was deemed impractical IIRC.
>
OK, so this is a different case than the one Ashish described ("client that
wants to support broker versions that do not provide broker version in
metadata and broker versions that provides version info in metadata"). So,
you are suggesting that if a client is communicating with a broker that
implements KIP-35 and it receives an empty response, it will assume that
the broker doesn't support the request version and it won't try to parse
the response? I think it would be good to explain this kind of thing in
detail in the KIP.
Ismael
