zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: An interesting problem removing a key
Date Fri, 02 Sep 2011 16:47:34 GMT
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
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message