zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andor Molnar <an...@apache.org>
Subject Re: Issues with using ZooKeeper 3.5.5 together with Solr 8.2.0
Date Thu, 15 Aug 2019 15:32:42 GMT
https://issues.apache.org/jira/browse/ZOOKEEPER-3511
Andor

-----Original Message-----From: Patrick Hunt <phunt@apache.org>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 <eolivelli@gmail.com>
wrote:
> Il sab 3 ago 2019, 21:41 Shawn Heisey <apache@elyograg.org> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message