On Thu, Jun 25, 2020 at 1:45 PM Enrico Olivelli <[email protected]> wrote:
> Il Gio 25 Giu 2020, 22:13 Patrick Hunt <[email protected]> ha scritto: > > > On Thu, Jun 25, 2020 at 3:20 AM Enrico Olivelli <[email protected]> > > wrote: > > > > > Hi, > > > we recently got into ZOOKEEPER-3803 > FileTxnSnapLog.fastForwardFromEdits() > > > throws NPE if TestingServer is started from another thread (see [1]) > > > and I have similar cases in other non OS products that run ZooKeeper > from > > > Java. > > > > > > The case of ZOOKEEPER-3803 is for Curator TestingServer, and here we > are > > > talking about running a ZK server for testing purposes. > > > But I have other usecases in which the ZK server must be launched, for > > > production usage, from a Java based bootstrap launcher. > > > > > > We are now officially supporting our binary package distribution that > > runs > > > ZooKeeper from a bash script and the bash script is coupled with > > > ZooKeeperMain and QuorumPeerMain. > > > > > > In my opinion we should provide a well known and supported API, better > > than > > > using directly those two classes, to run ZooKeeper safely in > production, > > > but launched from Java. > > > > > > I am not here supporting or suggesting the idea of running ZooKeeper > > inside > > > the same process of a client application, > > > but only to provide a clear and stable API to start/stop and do minimal > > > health checks to a ZooKeeper peer. > > > > > > I will be happy to work on it > > > > > > Thoughts ? > > > > > > > Sounds reasonable to me. That said I'm not sure I follow you entirely. > > Isn't that the goal of the two Main classes? Is it that they are > deficient > > (and can therefore be fixed to address) or they are serving a different > > role entirely from what you intend to provide? > > > > Those classes do not have a clear interface. > > We need at least > - init(configuration) > - start() > - stop() > - boolean isAlive() > > Makes sense to me. Can we refactor the Main classes to include/use that and also doc/pub it as an public/enduser interface? Possible user/consumer visible regressions may make that a bad idea? Or do you want to have just one interface that supports any cluster type, distributed or non. I could see both approaches working. Patrick > Optionally we can provide some utility to get the endpoint address. > > Very similar to Curator TestingServer but: > - for production > - maintained by Zookeeper project > > > Enrico > > > > > Patrick > > > > > > > > > > Enrico > > > > > > > > > [1] https://issues.apache.org/jira/browse/ZOOKEEPER-3803 > > > > > >
