zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <apa...@elyograg.org>
Subject Re: Issues with using ZooKeeper 3.5.5 together with Solr 8.2.0
Date Sat, 03 Aug 2019 19:41:08 GMT
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

Mime
View raw message