From user-return-12034-archive-asf-public=cust-asf.ponee.io@zookeeper.apache.org Sat Aug 3 19:41:23 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 CD0691802C7 for ; Sat, 3 Aug 2019 21:41:22 +0200 (CEST) Received: (qmail 14651 invoked by uid 500); 3 Aug 2019 19:41:20 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 14640 invoked by uid 99); 3 Aug 2019 19:41:20 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Aug 2019 19:41:20 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 5923C1A3479 for ; Sat, 3 Aug 2019 19:41:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=6.31 tests=[KAM_NUMSUBJECT=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id mgUGmV_jKDy8 for ; Sat, 3 Aug 2019 19:41:14 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=54.67.1.252; helo=bilbo.elyograg.org; envelope-from=apache@elyograg.org; receiver= Received: from bilbo.elyograg.org (bilbo.elyograg.org [54.67.1.252]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTP id 6A3BDBC7AD for ; Sat, 3 Aug 2019 19:41:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by bilbo.elyograg.org (Postfix) with ESMTP id 461Dsw57WSz7qmZ for ; Sat, 3 Aug 2019 13:41:08 -0600 (MDT) Received: from bilbo.elyograg.org ([127.0.0.1]) by localhost (bilbo@elyograg.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEC99Q_HQIKT for ; Sat, 3 Aug 2019 13:41:08 -0600 (MDT) Received: from [192.168.1.118] (170-72-4-30.ut.vivintwireless.net [170.72.4.30]) (Authenticated sender: elyograg@elyograg.org) by bilbo.elyograg.org (Postfix) with ESMTPSA id 461Dsw3VF9z7qmV for ; Sat, 3 Aug 2019 13:41:08 -0600 (MDT) Subject: Re: Issues with using ZooKeeper 3.5.5 together with Solr 8.2.0 To: user@zookeeper.apache.org References: <30DAC384-66C0-4F47-82D7-7E2B783A409A@gmail.com> <9D1EABD0-B911-476E-8591-6C3BC78D09D6@cominvent.com> From: Shawn Heisey Message-ID: <01ea4d95-00d1-381f-22a8-5719b51675e8@elyograg.org> Date: Sat, 3 Aug 2019 13:41:08 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 8/2/2019 10:33 AM, Patrick Hunt wrote: > Right, it prints the membership of the quorum, see (for majority case which > is typical): > org.apache.zookeeper.server.quorum.flexible.QuorumMaj#toString > https://github.com/apache/zookeeper/blob/faa7cec71fddfb959a7d67923acffdb67d93c953/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/flexible/QuorumMaj.java#L112 For our purposes (the Solr project) the output of the "conf" 4lw command is inconsistent, changing when there is a multi-server ensemble. All of the lines except the "membership: " one use an equals sign as a separator. Our parsing code fails on that line because there is no equals sign. Whether or not the ZK project should consider this a bug is the question that I am asking. While getting to the bottom of that question, another one arises: Who are the intended audiences of the "conf" 4lw output? If one of those audiences is ZK itself, then the output of the command probably will work perfectly for that audience, as ZK uses Java's "properties" API to read its config file, which means that both = and : will work as separators. The current output also works great for a human audience. Humans are quite flexible. The difficulty is machine-based parsers like the one in Solr, which is very simple and just splits lines on an equal sign. How much consistency can an audience like this expect? I would personally say that the way "membership: " is output is a bug. That line probably should be entirely removed, or the colon could be replaced with an equal sign. I think that the line only makes sense for a human audience, and that audience probably doesn't really need it. An alternate path: One statement in the documentation would remove all difficulty, without any code changes in ZK: "The output from the conf 4lw command should be parsed by the Java Properties API for best results." If that statement is added, then Solr just needs to utilize the Properties API, which is very easy to do, and all is well again. So... I'm thinking we should open an issue in Jira, and then leave it up to the ZK committers whether it's better to change the output or adjust the documentation. I can supply a patch either way. What does the community think? Thanks, Shawn