Hi Jun, the "send empty response instead of disconnect on unsupported protocol" was actually a sub-proposal and was never meant as an alternative to the proper feature detection proposed by KIP-35.
I've added it back to the list of rejected alternatives on the wiki page, thanks for pointing this out. There's an example and motivation on there too. /Magnus 2016-04-09 1:20 GMT+02:00 Jun Rao <j...@confluent.io>: > Magnus, > > A while back, we had another proposal for the broker to just send the > correlation id and an empty payload if it receives an unsupported version > of the request. I didn't see that in the rejected section. It seems simpler > than the current proposal where the client has to issue an > ApiVersionRequest on every connection. Could you document the reason why we > rejected it? > > Thanks, > > Jun > > On Tue, Apr 5, 2016 at 1:47 PM, Ashish Singh <asi...@cloudera.com> wrote: > > > On Fri, Apr 1, 2016 at 1:32 AM, Ismael Juma <ism...@juma.me.uk> wrote: > > > > > Two more things: > > > > > > 3. We talk about backporting of new request versions to stable branches > > in > > > the KIP. In practice, we can't do that until the Java client is changed > > so > > > that it doesn't blindly use the latest protocol version. Otherwise, if > > new > > > request versions were added to 0.9.0.2, the client would break when > > talking > > > to a 0.9.0.1 broker (given Jason's proposal, it would fail a bit more > > > gracefully, but that's still not good enough for a stable branch). It > may > > > be worth making this clear in the KIP (yes, it is a bit orthogonal and > > > doesn't prevent the KIP from being adopted, but good to avoid > confusion). > > > > > Good point. Adding this note and also adding a note that Kafka has not > > backported an api version so far. > > > > > > > > 4. The paragraph below is a bit confusing. It starts talking about > 0.9.0 > > > and trunk and then switches to 0.9.1. Is that intentional? > > > > > Yes. > > > > > > > > "Deprecation of a protocol version will be done by marking a protocol > > > version as deprecated in protocol documentation. Documentation shall > also > > > be used to indicate a protocol version that must not be used, or for > any > > > such information.For instance, say 0.9.0 had protocol versions [0] for > > api > > > key 1. On trunk, version 1 of the api key was added. Users running off > > > trunk started using version 1 of the api and found out a major bug. To > > > rectify that version 2 of the api is added to trunk. For some reason, > it > > is > > > now deemed important to have version 2 of the api in 0.9.1 as well. To > do > > > so, version 1 and version 2 both of the api will be backported to the > > 0.9.1 > > > branch. 0.9.1 broker will return 0 as min supported version for the api > > and > > > 2 for the max supported version for the api. However, the version 1 > > should > > > be clearly marked as deprecated on its documentation. It will be > client's > > > responsibility to make sure they are not using any such deprecated > > version > > > to the best knowledge of the client at the time of development (or > > > alternatively by configuration)." > > > > > > Ismael > > > > > > > > > > > > On Fri, Apr 1, 2016 at 9:22 AM, Ismael Juma <ism...@juma.me.uk> wrote: > > > > > > > A couple of questions: > > > > > > > > 1. The KIP says "Specific version may be deprecated through protocol > > > > documentation but must still be supported (although it is fair to > > return > > > an > > > > error code if the specific API supports it).". It may be worth > > expanding > > > > this a little more. For example, what does it mean to support the > API? > > I > > > > guess this means that the broker must not disconnect the client and > the > > > > broker must return a valid protocol response. Given that it says that > > it > > > is > > > > "fair" (I would probably replace "fair" with "valid") to return an > > error > > > > code if the specific API supports it, it sounds like we are saying > that > > > we > > > > don't have to maintain the semantic behaviour (i.e. we could _always_ > > > > return an error for a deprecated API?). Is this true? > > > > > > > > 2. ApiVersionQueryRequest seems a bit verbose, why not > > ApiVersionRequest? > > > > > > > > Ismael > > > > > > > > > > > > > > > -- > > > > Regards, > > Ashish > > >
