Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <F38CBB4D-73D6-4279-8A00-0D3F243AE901@zynga.com>
References: <B3467FD3-F993-4386-B764-7C8319DB8449@zynga.com>
 <CALF7aMQVbry0wa9YudW8p_peX3r=K15qZSSHZxtBD4gTHHpLEA@mail.gmail.com>
 <CAJwFCa0VjJuaY1=YApD=Gy9fTYZyva6XfwX363ATEMZgeLpGRg@mail.gmail.com>
 <F38CBB4D-73D6-4279-8A00-0D3F243AE901@zynga.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Fri, 2 Sep 2011 11:47:34 -0500
Message-ID: 
 <CAJwFCa3VzPwzvd79tByG6aEDGRJLcHRU4OQOwj=O+qvZPT9udg@mail.gmail.com>
Subject: Re: An interesting problem removing a key
To: user@zookeeper.apache.org
Cc: Matthew Willis <mwillis@zynga.com>, Mike Cao <mcao@zynga.com>
Content-Type: multipart/alternative; boundary=20cf300fb1e76a3a8904abf81fce

--20cf300fb1e76a3a8904abf81fce
Content-Type: text/plain; charset=UTF-8

Probably it would be a bit of a larger task than you would like, but
building a proxy might let you do what you want.  Then you could simply
filter out the notifications you don't want people to see.

On Fri, Sep 2, 2011 at 11:22 AM, Ben Hall <ben@zynga.com> wrote:

> Yeah - I guess to explain a little more... we have a very large number of
> clients out in the wild that in essence going to each pool of clients would
> be a huge hassle and pain.  So - yes we could update our client and provide
> a watcher switch but it would be very cumbersome to get to and update each
> of the clients.  We could also change the ZK structure - but again we would
> have to change all of the clients in the wild - a step we are trying to
> avoid.
>
> In short we were looking for just a quick workaround or hack from the
> server ensemble perspective even though it may not be a supported or
> recommended function - this would be just a one time thing for us.
>
> Thanks
> Ben
>
>
> On Sep 2, 2011, at 12:22 AM, Ted Dunning wrote:
>
> > I would recommend not spending a whole lot of time figuring out how to
> make
> > Zookeeper lie to the clients.  It is hard enough to make distributed
> > software that tells the truth.
> >
> > Why don't you just make the ZK structure match what you are trying to do?
> > For instance, have a znode containing the key and a separate znode that
> is
> > just for watching.  Then the server has the option of updating both
> znodes
> > or just the key depending on what behavior you want to get.
> >
> > This is simple and straightforward and makes it very clear what you mean
> to
> > do.  Why hack the server for such a thing?
> >
> > On Fri, Sep 2, 2011 at 1:37 AM, Mahadev Konar <mahadev@hortonworks.com
> >wrote:
> >
> >> Ben,
> >> I dont think I fully understand the use case. Is it possible that you
> >> can register a different callback for that key?
> >>
> >> Something like:
> >>
> >> zk.exists(String path, Watcher watcher)
> >>
> >> where you can register a different watcher for this path?
> >>
> >> Would this work?
> >>
> >> mahadev
> >>
> >>
> >> On Thu, Sep 1, 2011 at 5:58 PM, Ben Hall <ben@zynga.com> wrote:
> >>> Hi,
> >>>
> >>> We have an interesting problem use case that we wanted to ping the
> group
> >> about.
> >>>
> >>> We have a Key on all of our Ensemble servers.  All of our clients are
> >> also subscribed to this key.  We want to remove the key from the
> ensemble
> >> servers without this action getting propagated down to the clients.  Or
> if
> >> it does get propagated down - at a minimum we do not want to watch
> callback
> >> function to be called.
> >>>
> >>> Is there a way to in essence sever the watches from the server
> >> perspective without the client knowing?
> >>>
> >>> We are investing looking into the hidden keys on the zookeeper servers
> >> that hold the list of watches and possibly editing that key.  has anyone
> >> done that before?  Do we know what happens when that key is edited
> manually?
> >>>
> >>> Any other suggestions or possibilities available to us?
> >>>
> >>> Thanks
> >>> Ben
> >>
>
>

--20cf300fb1e76a3a8904abf81fce--