Would "WeakWatcher", a proxy watcher that holds a weak reference to the proxied watcher, not also solve this with minimal overhead? You could do this today.

1/ Add a useWeakReferences parameter to new constructor (sets default
2/ Add alternative methods, which take useWeakWatcherRef boolean.

I would prefer option 2 over 1, since I could see some users wishing to use both weak/strong in the same session. Couldn't we just mark the watcher with a "implements WeakWatcher" obviating the need for an explicit parameter?

An additoinal option - we could do the same thing by instead having a "ZooKeeperWeakWatches" subclass of zookeeper that provides this additional functionality (if we could overcome other objections) which would not impact existing users. You might be able to do this today, or with minimal changes to the ZooKeeper class...

I would prefer deregisterWatcher, as a result.

Seems like this would be a useful feature. Today you can get away with not doing this by using something like a StrongWatcher proxy similar to above (or some other way of ignoring the eventual trigger). Each deregister requires a roundtrip to the server however (also handle the case when disconnected of course). We might want to allow multiple paths to be dereg as once... (the server will kill the connection if the request packet size exceeds 1mb though so keep that in mind too...). Not sure if there are other technical issues to consider.


Dominic Williams wrote:
Quite a few platforms make the specification of weak listeners explicit e.g.
in ActionScript you can specify a boolean in addEventListener that specifies
whether the event source should hold weak references to listeners. Therefore
I think whether you want an event source to hold a weak or strong reference
to your listener is really an application-level choice i.e. it is the
application logic's choice whether to supply an anonymous inner class
instance that will disappear unless the event source holds a strong
reference, or a named object that you want to be freed from memory when
*you* remove your references to it.

I think for many application programming problems, there is no nice way to
manage memory unless an event source offers to hold weak references to

deregisterWatcher certainly works for things like locks where you do try {
lock.lock(); } finally { lock.unlock(); } but how about where you are
continually creating objects that maintain a copy of some items beneath
nodes (where, say, you are constantly changing your focus from one node to

In this case, most probably you will want to create a primitive that
calls deregisterWatcher in finalize(). But the problem of course is that
finalize() will never get called.

For that reason, you end up with references to primitives on which you
*must* call close() before you lose a reference to them.

In practice, this is just not possible to do reliably which is why I don't
think there can be a substitute to weak references.

Best, Dominic

On 19 March 2010 18:47, Henry Robinson <he...@cloudera.com> wrote:

(moved to zookeeper-dev)

This API exposes internal implementation details which ties future versions
of the client to supporting a particular set of semantics.

I would prefer deregisterWatcher, as a result.


On 19 March 2010 03:11, Dominic Williams <thedwilli...@googlemail.com
Hi I can see some people might be assigning for example anonymous class
instances as watchers/handlers, and not keeping any references to them.

To avoid breaking existing use cases, two options:

1/ Add a useWeakReferences parameter to new constructor (sets default

2/ Add alternative methods, which take useWeakWatcherRef boolean.

Internally will be trivial to have both

private final Map<String, Set<Watcher>> dataWatches =
           new HashMap<String, Set<Watcher>>();

private final Map<String, WeakSet<Watcher>> dataWatchesWeak =
            new HashMap<String, WeakSet<Watcher>>();

On 18 March 2010 22:47, Ted Dunning <ted.dunn...@gmail.com> wrote:

This kind of sounds strange to me.

My typical idiom is to create a watcher but not retain any references
outside the client.  It sounds to me like your change will cause my
to be collected and deactivated when GC happens.

On Thu, Mar 18, 2010 at 3:32 AM, Dominic Williams <
thedwilli...@googlemail.com> wrote:

The current ZooKeeper client holds strong references to Watcher
want to change the client so it only holds weak references. Feedback

Henry Robinson
Software Engineer

Reply via email to