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

Reply via email to