There is a bit of a conundrum here. Your problem is one of coordination. In the Zookeeper world, it is common to solve problems like this using ephemeral znodes to indicate that a server is up. Your problem is that you are trying to coordinate with the Zookeeper process itself and don't have an external Zookeeper available to help you.
This problem of coordinating with the coordinator is exactly what makes embedded use of Zookeeper somewhat problematic. I have written, used and tried to maintain applications that have embedded Zookeepers and this has always been a problem. In addition, using an embedded Zookeeper also leads to multi-master issues because it is usually possible to invoke multiple copies of the program with the embedded Zookeeper. You don't usually want to hunt for a port number because the ZK port should be a well-known thing (test cases are the major exception) and you don't usually want to share some other invocations embedded Zookeeper. You also don't usually want Zookeeper to go down just because of an application error. All in all, I really prefer to have a separate Zookeeper service and avoid embedded designs. There is a small management overhead (just start it once and arrange for restart on reboot ... it will run forever). On Sat, May 28, 2011 at 10:18 AM, Avinash Lakshman < [email protected]> wrote: > Hi All > > I am trying to run ZK in embedded mode. Basically I invoke > QuorumPeerMain.main() on a separate thread. However is there a way to > programmatically determine if the local server is ready to take write > requests? I would like to on a separate thread create a Zookeeper instance > and save some state. Currently I have a Thread.sleep(10seconds) to achieve > what I want. > > Thanks in advance > Avinash >
