On Mon, Mar 14, 2016 at 2:12 PM, Ismael Juma <ism...@juma.me.uk> wrote:
> 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.
>
Actually even in this case and the case I mentioned, closing connection
should be fine. Lets think about possible reasons that could lead to this
issue.
1. Client has incorrect mapping of supported protocols for a broker version.
2. Client misread broker version from metadata response.
3. Client constructed unsupported protocol version by mistake.
In all the above cases irrespective of what broker does, client will keep
sending wrong request version.
At this point, I think sending an empty packet instead of closing
connection is a nice to have and not mandatory requirement. Like in the
above case, a client can catch parsing error and be sure that there is
something wrong in the protocol version it is sending. However, a generic
connection close does not really provide any information on probable cause.
What do you guys suggest?
>
> Ismael
>
--
Regards,
Ashish
