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() 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 > > >
