Turns out we already have an InvalidRequestException: https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/network/RequestChannel.scala#L75-L98
We just don't map it in Errors.java so it results in an UNKNOWN error when sent back to the client. I will migrate the InvalidRequestException to the client package, add it to Errors and use that to signify any protocol parsing/rule errors. On Wed, Jun 15, 2016 at 2:55 PM, Dana Powers <dana.pow...@gmail.com> wrote: > On Wed, Jun 15, 2016 at 12:19 PM, Ismael Juma <ism...@juma.me.uk> wrote: > > Hi Grant, > > > > Comments below. > > > > On Wed, Jun 15, 2016 at 6:52 PM, Grant Henke <ghe...@cloudera.com> > wrote: > >> > >> The one thing I want to avoid is to many super specific error codes. I > am > >> not sure how much of a problem it really is but in the case of wire > >> protocol errors like multiple instances of the same topic, do you have > any > >> thoughts on the error? Should we make a generic InvalidRequest error and > >> log the detailed message on the broker for client authors to debug? > >> > > > > That is a good question. It would be good to get input from client > > developers like Dana on this. > > I think generic error codes are fine if the wire protocol requirements > are documented [i.e., no duplicate topics and partitions/replicas are > either/or not both]. If I get a broker error at the protocol level > that I don't understand, the first place I look is the protocol docs. > It may cause a few more emails to the mailing lists asking for > clarification, but I think those will be easier to triage than > confused emails like "I said create topic with 10 partitions, but I > only got 5???" > > -Dana > -- Grant Henke Software Engineer | Cloudera gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
