From user-return-12074-archive-asf-public=cust-asf.ponee.io@zookeeper.apache.org Thu Aug 15 15:32:46 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 BE02E180645 for ; Thu, 15 Aug 2019 17:32:45 +0200 (CEST) Received: (qmail 55944 invoked by uid 500); 15 Aug 2019 15:32:44 -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 55933 invoked by uid 99); 15 Aug 2019 15:32:44 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2019 15:32:44 +0000 Received: from dph-mint (51B61FF7.dsl.pool.telekom.hu [81.182.31.247]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 1314E7C77 for ; Thu, 15 Aug 2019 15:32:43 +0000 (UTC) Message-ID: <89b286a5793cb4b83d78f21678df1bac80f870da.camel@apache.org> Subject: Re: Issues with using ZooKeeper 3.5.5 together with Solr 8.2.0 From: Andor Molnar To: user@zookeeper.apache.org Date: Thu, 15 Aug 2019 17:32:42 +0200 In-Reply-To: References: <30DAC384-66C0-4F47-82D7-7E2B783A409A@gmail.com> <9D1EABD0-B911-476E-8591-6C3BC78D09D6@cominvent.com> <01ea4d95-00d1-381f-22a8-5719b51675e8@elyograg.org> Content-Type: multipart/alternative; boundary="=-9fkkQgeQK6V1YwPiOmgq" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 --=-9fkkQgeQK6V1YwPiOmgq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit https://issues.apache.org/jira/browse/ZOOKEEPER-3511 Andor -----Original Message-----From: Patrick Hunt Reply- To: user@zookeeper.apache.orgTo: UserZooKeeper < user@zookeeper.apache.org>Subject: Re: Issues with using ZooKeeper 3.5.5 together with Solr 8.2.0Date: Mon, 5 Aug 2019 09:04:44 -0700 It sounds to me like a regression. We always had the properties format for4lw, this (membership:) breaks that. I'd recommend fixing it in the next3.5/3.6. ie. output the membership on a single line "membership: .... \n".Should be a pretty simple change - anyone interested in taking it on? Also agree that folks should move off 4lw to the new (better) options, espas we plan to deprecate 4lw at some point. Patrick On Sun, Aug 4, 2019 at 12:15 PM Enrico Olivelli wrote: > Il sab 3 ago 2019, 21:41 Shawn Heisey ha > scritto: > > 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#to > > > String > 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 > > commandis inconsistent, changing when there is a multi-server > > ensemble. All ofthe lines except the "membership: " one use an > > equals sign as aseparator. Our parsing code fails on that line > > because there is noequals sign. > > Whether or not the ZK project should consider this a bug is the > > questionthat I am asking. > > While getting to the bottom of that question, another one > > arises: Whoare the intended audiences of the "conf" 4lw > > output? If one of thoseaudiences is ZK itself, then the output of > > the command probably willwork perfectly for that audience, as ZK > > uses Java's "properties" API toread its config file, which means > > that both = and : will work asseparators. > > The current output also works great for a human audience. Humans > > arequite flexible. > > The difficulty is machine-based parsers like the one in Solr, which > > isvery simple and just splits lines on an equal sign. How > > muchconsistency can an audience like this expect? I would > > personally saythat the way "membership: " is output is a bug. That > > line probablyshould be entirely removed, or the colon could be > > replaced with an equalsign. I think that the line only makes sense > > for a human audience, andthat audience probably doesn't really need > > it. > > An alternate path: One statement in the documentation would remove > > alldifficulty, without any code changes in ZK: > > "The output from the conf 4lw command should be parsed by the > > JavaProperties API for best results." > > I think the best option is to switch to the Admin, HTTP + json based, > as itis possible to integrate better with other automatic tools.We > are working on docs for 3.6 (expecially the http admin server).We > also added many new 'commands' to the admin API, which is supposed to > bethe future for the mid/long term > Enrico > > > > If that statement is added, then Solr just needs to utilize > > theProperties 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 upto the ZK committers whether it's better to change the output > > or adjustthe documentation. I can supply a patch either way. What > > does thecommunity think? > > Thanks,Shawn --=-9fkkQgeQK6V1YwPiOmgq--