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 >
