Il sab 3 ago 2019, 21:41 Shawn Heisey <apa...@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#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." > I think the best option is to switch to the Admin, HTTP + json based, as it is 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 be the future for the mid/long term Enrico > 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 >
