Hi Vishal and Ashanka, I think Ted and Pat had somewhat comentted on this before.
Reiterating these comments below. If you are ok with these points I see no concern in ZooKeeper as an embedded application. Also, as Pat mentioned earlier there are some cases where the server code will "system.exit". This is typically only if quorum communication fails in some weird, unrecoverable way. We have removed most of these but there are a few still remaining. --- Comments by Ted ---- I can't comment on the details of your code (but I have run in-process ZK's in the past without problem) Operationally, however, this isn't a great idea. The problem is two-fold: a) firstly, somebody would probably like to look at Zookeeper to understand the state of your service. If the service is down, then ZK will go away. That means that Zookeeper can't be used that way and is mild to moderate on the logarithmic international suckitude scale. b) secondly, if you want to upgrade your server without upgrading Zookeeper then you still have to bounce Zookeeper. This is probably not a problem, but it can be a slight pain. c) thirdly, you can't scale your service independently of how you scale Zookeeper. This may or may not bother you, but it would bother me. d) fourthly, you will be synchronizing your server restarts with ZK's service restarts. Moving these events away from each other is likely to make them slightly more reliable. There is no failure mode that I know of that would be tickled here, but your service code will be slightly more complex since it has to make sure that ZK is up before it does stuff. If you could make the assumption that ZK is up or exit, that would be simpler. e) yes, I know that is more than two issues. That is itself an issue since any design where the number of worries is increasing so fast is suspect on larger grounds. If there are small problems cropping up at that rate, the likelihood of there being a large problem that comes up seems higher. On 4/23/10 11:04 AM, "Vishal K" <vishalm...@gmail.com> wrote: > Hi, > > Good question. We are planning to do something similar as well and it will > great to know if there are any issues with embedding ZK server into an app. > We simply use QourumPeerMain and QourumPeer from our app to start/stop the > ZK server. Is this not a good way to do it? > > On Fri, Apr 23, 2010 at 1:28 PM, Asankha C. Perera <asan...@apache.org>wrote: > >> Hi All >> >> I'm very new to ZK, and am looking at embeding ZK into an app that needs >> cluster management - and the objective is to use ZK to notify >> application cluster control operations (e.g. shutdown etc) across nodes. >> >> I came across this post [1] from the user list by Ted Dunning from some >> months back : >> "My experience with Katta has led me to believe that embedding a ZK in a >> product is almost always a bad idea. - The problems are that you can't >> administer the Zookeeper cluster independently and that the cluster >> typically goes down when the associated service goes down." >> >> However, I believe that both the above are fine to live with for the >> application under consideration, as ZK will be used only to coordinate >> the larger application. Is there anything else that needs to be >> considered - and can I safely shutdown the clientPort since the >> application is always in the same JVM - but, if I do that how would I >> "connect" to ZK thereafter ? >> >> thanks and regards >> asankha >> >> [1] http://markmail.org/message/tjonwec7p7dhfpms >>