zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli <eolive...@gmail.com>
Subject Re: Issues with using ZooKeeper 3.5.5 together with Solr 8.2.0
Date Mon, 05 Aug 2019 06:35:27 GMT
Il lun 5 ago 2019, 00:57 Jan Høydahl <jan.asf@cominvent.com> 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 <eolivelli@gmail.com>:
> >
> > 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#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
> >>
>

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