We discussed an error code for rate-limiting (which I think made sense), isn't it a similar case?
On Mon, Mar 16, 2015 at 10:10 PM, Jay Kreps <jay.kr...@gmail.com> wrote: > 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 >> >> > >> >> >>
