Il lun 5 ago 2019, 00:57 Jan Høydahl <[email protected]> ha scritto:
> Will admin server be folded in and exposed on same port as main client > port in the future? If not, clients will need to have one config for zkHost > plus one more for zkAdminServer. Personally I hope we won't do this. I hope we continue investing in the client endpoint performances and mixing it with an HTTP server will complicate things. That said, it is possible in theory to merge them I asked in another thread of admin server port number will have a > better/more unique default than 8080 in the future, such as 2188 or > whatever? > +1 I don't know how much this can impact downstream bundles. I am not an user of admin server yet, I will switch as soon as 3.6 is out. Enrico > Jan Høydahl > > > 4. aug. 2019 kl. 21:15 skrev Enrico Olivelli <[email protected]>: > > > > Il sab 3 ago 2019, 21:41 Shawn Heisey <[email protected]> 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 > >> >
