My concern is that as soon as you start encoding non-error response information into error codes the next question is what to do if two such codes apply (i.e. you have a replica down and the response is quota'd). I think I am trying to argue that error should mean "why we failed your request", for which there will really only be one reason, and any other useful information we want to send back is just another field in the response.
-Jay On Mon, Mar 16, 2015 at 9:51 PM, Gwen Shapira <gshap...@cloudera.com> wrote: > I think its not too late to reserve a set of error codes (200-299?) > for "non-error" codes. > > It won't be backward compatible (i.e. clients that currently do "else > throw" will throw on non-errors), but perhaps its worthwhile. > > On Mon, Mar 16, 2015 at 9:42 PM, Jay Kreps <jay.kr...@gmail.com> wrote: > > Hey Jun, > > > > I'd really really really like to avoid that. Having just spent a bunch of > > time on the clients, using the error codes to encode other information > > about the response is super dangerous. The error handling is one of the > > hardest parts of the client (Guozhang chime in here). > > > > Generally the error handling looks like > > if(error == none) > > // good, process the request > > else if(error == KNOWN_ERROR_1) > > // handle known error 1 > > else if(error == KNOWN_ERROR_2) > > // handle known error 2 > > else > > throw Errors.forCode(error).exception(); // or some other default > > behavior > > > > This works because we have a convention that and error is something that > > prevented your getting the response so the default handling case is sane > > and forward compatible. It is tempting to use the error code to convey > > information in the success case. For example we could use error codes to > > encode whether quotas were enforced, whether the request was served out > of > > cache, whether the stock market is up today, or whatever. The problem is > > that since these are not errors as far as the client is concerned it > should > > not throw an exception but process the response, but now we created an > > explicit requirement that that error be handled explicitly since it is > > different. I really think that this kind of information is not an error, > it > > is just information, and if we want it in the response we should do the > > right thing and add a new field to the response. > > > > I think you saw the Samza bug that was literally an example of this > > happening and leading to an infinite retry loop. > > > > Further more I really want to emphasize that hitting your quota in the > > design that Adi has proposed is actually not an error condition at all. > It > > is totally reasonable in any bootstrap situation to intentionally want to > > run at the limit the system imposes on you. > > > > -Jay > > > > > > > > On Mon, Mar 16, 2015 at 4:27 PM, Jun Rao <j...@confluent.io> wrote: > > > >> It's probably useful for a client to know whether its requests are > >> throttled or not (e.g., for monitoring and alerting). From that > >> perspective, option B (delay the requests and return an error) seems > >> better. > >> > >> Thanks, > >> > >> Jun > >> > >> On Wed, Mar 4, 2015 at 3:51 PM, Aditya Auradkar < > >> aaurad...@linkedin.com.invalid> wrote: > >> > >> > Posted a KIP for quotas in kafka. > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-13+-+Quotas > >> > > >> > Appreciate any feedback. > >> > > >> > Aditya > >> > > >> >
