From dev-return-110092-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Mon Dec 30 10:07:35 2019 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 [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 42734180657 for ; Mon, 30 Dec 2019 11:07:35 +0100 (CET) Received: (qmail 59268 invoked by uid 500); 30 Dec 2019 10:07:33 -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 59256 invoked by uid 99); 30 Dec 2019 10:07:33 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Dec 2019 10:07:33 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id AD8CEC054B for ; Mon, 30 Dec 2019 10:07:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=confluent.io Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 6xzpEXFchQP8 for ; Mon, 30 Dec 2019 10:07:31 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::343; helo=mail-wm1-x343.google.com; envelope-from=stanislav@confluent.io; receiver= Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id 9BB347E112 for ; Mon, 30 Dec 2019 10:07:30 +0000 (UTC) Received: by mail-wm1-x343.google.com with SMTP id d139so11297745wmd.0 for ; Mon, 30 Dec 2019 02:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=confluent.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=aclJZHVTY6c+XMyi4s2iJBLi2Uowoilxtm3HhtuoM/Y=; b=aaY3MAGgdU0ks3ymN6n50gIv6QXCWeoAjPJM4pZSpygz9DLzGsmav1siTfVGhvV488 QCE8k8oqhEYez5f8OKhscaoPE3S9oGVgpfPAgCc+6XbaRLIqJgzg31S4JZemfcQrZHc4 sbieZxugP1L0c/iu8nWNif3l1mVatXLgXtjedO1w1s5QWMUX6hihdWtoReWj0efja+f7 cTs0Hi/qUBucmodU/Vz2b9fZmzmlzurytRjk9M6REKtjaOAuV4dn0/0dbrCunbAt75qm o172ZxM9ZtEp9GN6YL1ZcKuzu9jqGnrHs9ilLOJDyXvezp+Jp4DPZXAbD0TieIxGAjlS Z3+g== 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=aclJZHVTY6c+XMyi4s2iJBLi2Uowoilxtm3HhtuoM/Y=; b=HSsiOOob+XIvUIPGs4elsw2yAWCY/5LVkkNHq9T2Xmh3dYf0XyMc7/VygJuqxgWO11 o81ei7sXF07VWyrs3keNAwyVNmhQDxW9aXv4D1wAq4iBmHYOzAqrA/98G6Wn901Aqwk1 jRkuC+cbNNiwcBS+jPPV0A+Nr3i+hsoIk4ZQW29kkKsFrXiL9JbhWlwd4pckNQG/4J9h Zo5s6H5z7y7EGaXrOCcrQslooWiAVZeVOFjO2ncEyF3B/lzYf7IiUobCSIErE+eipZ5O fZJGglW0tOGDTMMyQ2ebrcD2aVCXBDLWoyax/9epuE0Gv8vEipkdQ4LJNEXz38DxWtzX zULw== X-Gm-Message-State: APjAAAVFHuW26l5YvJ4xEvLZFqbj8fERssjj5JBxdebOBka0gpOa10bT 5KMIyRordiw+BzsWc2zBxTL1iwk7NJ2QoAu/9/Qe6v5K X-Google-Smtp-Source: APXvYqzy0ANCBNT+wsSzZfOAW/rMbVB+v0r4bMoLXNdQeFnFh5Hdp2Vke1eC/62Hjqyj2oxAnWREFE9+5ONvPGEicTM= X-Received: by 2002:a1c:964f:: with SMTP id y76mr33459000wmd.62.1577700449350; Mon, 30 Dec 2019 02:07:29 -0800 (PST) MIME-Version: 1.0 References: <58f32d1c-d1dd-4101-8bae-a9e6cbe093ab@www.fastmail.com> <73548d8e-bc22-4b58-a473-d3a50a87294f@www.fastmail.com> In-Reply-To: <73548d8e-bc22-4b58-a473-d3a50a87294f@www.fastmail.com> From: Stanislav Kozlovski Date: Mon, 30 Dec 2019 10:07:18 +0000 Message-ID: Subject: Re: [DISCUSS] KIP-552: Add interface to handle unused config To: dev@kafka.apache.org Content-Type: multipart/alternative; boundary="000000000000d89f35059ae902d1" --000000000000d89f35059ae902d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Would printing all the unused configurations in one line, versus N lines, be more helpful? I know that it would greatly reduce the verbosity in log visualization tools like Kibana while still allowing us to see all the relevant information without the need for an explicit action (e.g changing the log level) Best, Stanislav On Sat, Dec 28, 2019 at 3:13 PM John Roesler wrote: > Hi Artur, > > That=E2=80=99s a good point. > > One thing you can do is log a summary at WARN level, like =E2=80=9C27 > configurations were ignored. Ignored configurations are logged at DEBUG > level.=E2=80=9D > > I looked into the code a little, and these log messages are generated in > AbstractConfig (logAll and logUnused). They both use the logger associate= d > with the relevant config class (StreamsConfig, ProducerConfig, etc.). The > list of all configs is logged at INFO level, and the list of unused confi= gs > is logged at WARN level. This means that it's not possible to silence the > unused config messages while still logging the list of all configs. You > could only silence both by setting (for example) ProducerConfig logger to > ERROR or OFF. > > If it's desirable to be able to toggle them independently, then you can > create a separate logger for unused configs, named something like > "org.apache.kafka.clients.producer.ProducerConfig.unused". Then, you can > leave the log at WARN, so it would continue to be printed by default, and > anyone could disable it by setting > "org.apache.kafka.clients.producer.ProducerConfig.unused" to ERROR or OFF= , > without disturbing the rest of the config log messages. > > It's simpler without the extra logger, but you also get less control. Do > you think the extra control is necessary, versus printing a summary at WA= RN > level? > -John > > > On Fri, Dec 27, 2019, at 04:26, Artur Burtsev wrote: > > Hi, > > > > Indeed changing log level to debug would be the easiest and I think > > that would be a good solution. When no one object I'm ready to move > > forward with this approach and submit a MR. > > > > The only minor thing I have =E2=80=93 having it at debug log level migh= t make > > it a bit less friendly for developers, especially for those who just > > do the first steps in Kafka. For example, if you misspelled the > > property name and trying to understand why things don't do what you > > expect. Having a warning might save some time in this case. Other than > > that I cannot see any reasons to have warnings there. > > > > Thanks, > > Artur > > > > On Thu, Dec 26, 2019 at 10:01 PM John Roesler > wrote: > > > > > > Thanks for the KIP, Artur! > > > > > > For reference, here is the kip: > https://cwiki.apache.org/confluence/display/KAFKA/KIP-552%3A+Add+interfac= e+to+handle+unused+config > > > > > > I agree, these warnings are kind of a nuisance. Would it be feasible > just to leverage log4j in some way to make it easy to filter these > messages? For example, we could move those warnings to debug level, or ev= en > use a separate logger for them. > > > > > > Thanks for starting the discussion. > > > -John > > > > > > On Tue, Dec 24, 2019, at 07:23, Artur Burtsev wrote: > > > > Hi, > > > > > > > > This KIP provides a way to deal with a warning "The configuration {= } > > > > was supplied but isn't a known config." when it is not relevant. > > > > > > > > Cheers, > > > > Artur > > > > > > > --=20 Best, Stanislav --000000000000d89f35059ae902d1--