From dev-return-95833-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Thu Jul 5 20:06:02 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 38EFE180657 for ; Thu, 5 Jul 2018 20:06:02 +0200 (CEST) Received: (qmail 1312 invoked by uid 500); 5 Jul 2018 18:06:00 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 1284 invoked by uid 99); 5 Jul 2018 18:06:00 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jul 2018 18:06:00 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id D1AF8C0103 for ; Thu, 5 Jul 2018 18:05:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.119 X-Spam-Level: ** X-Spam-Status: No, score=2.119 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, KAM_LOTSOFHASH=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id ILF5oRl649gl for ; Thu, 5 Jul 2018 18:05:58 +0000 (UTC) Received: from mail-vk0-f66.google.com (mail-vk0-f66.google.com [209.85.213.66]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id B69CF5F49F for ; Thu, 5 Jul 2018 18:05:57 +0000 (UTC) Received: by mail-vk0-f66.google.com with SMTP id t4-v6so5288361vke.9 for ; Thu, 05 Jul 2018 11:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qgN+DvVlaqr5duDs3UDzYdEJX6dWxEKuzZynCcWL/R8=; b=DbEJPAySR5GwjfliBDIyUODi5eag9AJcw/AviIkjEqOueA+IxboRbzDJWvqGYQSPyL Nuy5Ng7///q0eCW+Ozw9Wf2F7DeSSMuZiOJswF/xE6PJGiShlvWXD9eVKR2SkD7TleA/ EPtZZDe1hbObz5AH3H9oiZXC+njEs3sJbwV7UZ3ZVmiI/DJI+IgAUE3dPz0HEn5I5RBq 8pElMA4fTFp7n/L6OabAeKW3g0wiNSXTc60qCJgQEJeMjSH3H591mORlOiN9z8Lnxu4s KNR+0dhMMyw8ozl4C3w0upLyP0F/Fw9Cpn0zdcMB/Ybk4RRbwMnHnegwjIcVhXgTGaGd f0uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qgN+DvVlaqr5duDs3UDzYdEJX6dWxEKuzZynCcWL/R8=; b=RW1vZDB1LTMVmZIK0NOXLK892cFe56AJ28FBzl7taNb+v9XoU4fbv55KrdVUcfAkmq qsb2F4ClRBOmFvaItwcREeJcpex96LkcPbXXAux6m29vThZ/dVwC6okK0zAH8VL8XrJr pdNgwqdg/pVOyl82Vp2bCw+jO6ndx2yUEilYh9ukzdd8AAMrfhH1nZs/LoeWXhI1dv1S eommrchgG27KBJ2hYzO3EWLl+CWy4zXmMk2rGCp0vH/H80Cy1Ohor0G8m5EJNj3Lu42G U7KNLStnbWnFjlCDUmJa8KlHSR9ErH1dLOHEMJiyAaQs9lLHbgAmcD3wv0EU1oL8nyQw RcEA== X-Gm-Message-State: APt69E2E84wpMPv6fYqz00wd9W9ekZrsTdObC2qeZIaaLSsrv4u4i3U8 rr0CGFwGzVBn6uJdwwWVDe/vxfyQpZ/pX8XpYNjhCKt6 X-Google-Smtp-Source: AAOMgpfWSVUxrdM+tbWFM4PsPqrkOUF9RqFaS9IDdt8WVcGim4dm6jm/WJNcXqI/fPPF4JZHNm+S8vtZLdRmEJcqQf4= X-Received: by 2002:a1f:9ecd:: with SMTP id h196-v6mr3955012vke.157.1530813952040; Thu, 05 Jul 2018 11:05:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ismael Juma Date: Thu, 5 Jul 2018 11:05:15 -0700 Message-ID: Subject: Re: [DISCUSS] KIP-334 Include partitions in exceptions raised during consumer record deserialization/validation To: dev Content-Type: multipart/alternative; boundary="000000000000d424ff05704465f7" --000000000000d424ff05704465f7 Content-Type: text/plain; charset="UTF-8" Yes, the Scala consumers have been removed in 2.0.0, which simplifies some of this. The following commit was an initial step in unifying the exception handling: https://github.com/apache/kafka/commit/96bcfdfc7c9aac075635b2034e65e412a725672e But more can be done as you mentioned. Ismael On 5 Jul 2018 9:36 am, "Stanislav Kozlovski" wrote: Hey Ismael, It is only slightly related - my PR would attach two new attributes and also touch upon deserialization exceptions. But this PR did provide me with some insight: Maybe the best approach would be to make `InvalidRecordException` a public exception instead of introducing a new one - I did not realize it was not publicly exposed. Does the following: InvalidMessageException extends CorruptRecordException for temporary compatibility with the old Scala clients. * We want to update the server side code to use and catch the new CorruptRecordException. * Because ByteBufferMessageSet.scala and Message.scala are used in both server and client code having * InvalidMessageException extend CorruptRecordException allows us to change server code without affecting the client. still apply? I can see that the `ByteBufferMessageSet` and `Message` scala classes are not present in the codebase anymore. AFAIA the old scala clients were removed with 2.0.0 and we can thus update the server side code to use the `CorruptRecordException` while changing and exposing `InvalidRecordException` to the public. WDYT? I will also make sure to not expose the cause of the exception when not needed, maybe I'll outright remove the `cause` attribute On Thu, Jul 5, 2018 at 4:55 PM Ismael Juma wrote: > Thanks for the KIP, Stanislav. The following PR looks related: > > https://github.com/apache/kafka/pull/4093/files > > Ismael > > On Thu, Jul 5, 2018 at 8:44 AM Stanislav Kozlovski > > wrote: > > > Hey everybody, > > > > I just created a new KIP about exposing more information in exceptions > > caused by consumer record deserialization/validation. Please have a look > at > > it, it is a very short page. > > > > I am working under the assumption that all invalid record or > > deserialization exceptions in the consumer pass through the `Fetcher` > > class. Please confirm if that is true, otherwise I might miss some places > > where the exceptions are raised in my implementation > > > > One concern I have is the name of the second exception - > > `InoperativeRecordException`. I would have named it > > `InvalidRecordException` but that is taken. The `Fetcher` class catches > > `InvalidRecordException` (here > > < > > > https://github.com/apache/kafka/blob/c5b00d20d3703b7fc4358b7258d5d6adb890136f/clients/src/main/java/org/apache/kafka/clients/consumer/internals/Fetcher.java#L1081 > > > > > and here > > < > > > https://github.com/apache/kafka/blob/c5b00d20d3703b7fc4358b7258d5d6adb890136f/clients/src/main/java/org/apache/kafka/clients/consumer/internals/Fetcher.java#L1092 > > >) > > and re-raises it as `KafkaException`, which exposes it as a non-retriable > > exception to the user (`InvalidRecordException` extends > > `RetriableExecption`, but `KafkaException` doesn't). > > A suggestion I got for an alternative name was > > `InvalidFetchRecordException`. Please chime in if you have ideas > > > > Confluence page: KIP-334 > > < > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=87297793 > > > > > JIRA Issue: KAFKA-5682 > > > -- > > Best, > > Stanislav > > > -- Best, Stanislav --000000000000d424ff05704465f7--