Sorry, I forget that you have mentioned this idea in your previous reply. I
guess the question is, do we still need this KIP if we can have custom
error message specified in the exception via the other KIP?
On Mon, Mar 27, 2017 at 11:00 PM, Mayuresh Gharat <
gharatmayures...@gmail.com> wrote:
> Hi Dong,
>
> I do agree with that as I said before the thought did cross my mind and I
> am working on getting another KIP ready to have error responses returned
> back to the client.
>
> In my opinion, it's OK to add a new error code if it justifies the need. As
> Ismael, mentioned on the jira, we need a specific non retriable error code
> in this case, with specific message, at least until the other KIP is ready.
>
> Thanks,
>
> Mayuresh
> On Mon, Mar 27, 2017 at 10:55 PM Dong Lin <lindon...@gmail.com> wrote:
>
> > Hey Mayuresh,
> >
> > I get that you want to provide a more specific error message to user.
> Then
> > would it be more useful to have a KIP that allows custom error message to
> > be returned to client together with the exception in the response? For
> > example, broker can include in the response PolicyViolationException("key
> > can not be null for non-compact topic ${topic}") and client can print
> this
> > error message in the log. My concern with current KIP that it is not very
> > scalable to always have a KIP and class for every new error we may see in
> > the future. The list of error classes, and the errors that need to be
> > caught and handled by the client code, will increase overtime and become
> > harder to maintain.
> >
> > Thanks,
> > Dong
> >
> >
> > On Mon, Mar 27, 2017 at 7:20 PM, Mayuresh Gharat <
> > gharatmayures...@gmail.com
> > > wrote:
> >
> > > Hi Dong,
> > >
> > > I had thought about this before and wanted to do similar thing. But as
> > was
> > > pointed out in the jira ticket, we wanted something more specific than
> > > general.
> > > The main issue is that we do not propagate server side error messages
> to
> > > clients, right now. I am working on a KIP proposal to propose it.
> > >
> > > Thanks,
> > >
> > > Mayuresh
> > >
> > > On Mon, Mar 27, 2017 at 5:55 PM, Dong Lin <lindon...@gmail.com> wrote:
> > >
> > > > Hey Mayuresh,
> > > >
> > > > Thanks for the patch. I am wondering if it would be better to add a
> > more
> > > > general error, e.g. InvalidMessageException. The benefit is that we
> can
> > > > reuse this for other message level error instead of adding one
> > exception
> > > > class for each possible exception in the future. This is similar to
> the
> > > use
> > > > of InvalidRequestException. For example, ListOffsetResponse may
> return
> > > > InvalidRequestException if duplicate partitions are found in the
> > > > ListOffsetRequest. We don't return DuplicatedPartitionException in
> this
> > > > case.
> > > >
> > > > Thanks,
> > > > Dong
> > > >
> > > >
> > > >
> > > > On Wed, Mar 22, 2017 at 3:07 PM, Mayuresh Gharat <
> > > > gharatmayures...@gmail.com
> > > > > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > We have created KIP-135 to propose that Kafka should return a
> > > > non-retriable
> > > > > error when the producer produces a message with null key to a log
> > > > compacted
> > > > > topic.
> > > > >
> > > > > Please find the KIP wiki in the link :
> > > > >
> > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > > 135+%3A+Send+of+null+key+to+a+compacted+topic+should+throw+
> > > > > non-retriable+error+back+to+user.
> > > > >
> > > > >
> > > > > We would love to hear your comments and suggestions.
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Mayuresh
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -Regards,
> > > Mayuresh R. Gharat
> > > (862) 250-7125
> > >
> >
>
