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
|