#25 Child watches are not triggered when the node is deleted


If a client sets a watch on "/foo" with a getChildren("/foo" ...) and "/foo" gets deleted, no watch event is triggered. (Ever.)

It could be argued that this is correct behavior since the children did not change, but it can lead to confusion since "/foo" could be recreated and children added and still the watch would not get triggered. (We trace watches by znode instance and deleting and creating "/foo" causes a new znode instance.)

The correct behavior should be that when a znode is removed there are three events triggered: parent child watches, znode data watches, and znode child watches.


  • Benjamin Reed

    Benjamin Reed - 2008-06-01
    • milestone: --> 3.0.0
  • Patrick Hunt

    Patrick Hunt - 2008-06-03

    Logged In: YES
    Originator: NO

    This is going to be a bit more complicated that it seems. Let me know what you think of the following:

    The server has 2 watcher lists; data & child. Currently watchers are triggered exclusively to one or the other list (all datachanged are on data list, all children changed on child list,etc...)

    Merely adding a "childwatches.trigger(path, nodedeleted)" to datatree will result in (potentially) two nodedeleted events being sent to a watcher (if client did a exists(path) & getchildren(path) for example). I don't believe we want to do this.

    There are two options afaict; add a new watch list "deletedNodeWatches" to datatree that contains both data & child watches to be triggered for nodedelete events only, or continue to have 2 lists and filter out any duplicate events during the trigger phase.

    Adding more lists doesn't seem like a great option. Option 2 would require a change to watchmanager.triggerwatches to return the set of watchers triggered, which would be used to filter out duplicate triggers.

    pseudo for datatree.deletenode:
    processedwatches = datawatches.triggerwatches(path, nodedeleted)
    childwatches.triggerwatches(path, nodedeleted, processedwatches)

    triggerwatches would be updated to use processwatches parameter to filter out duplicate nodedeleted events from being generated (the child watch would be cleared on the server)

    Secondly the client (current patch) also has two lists - data and child watches. The client will have to use the same trick -- trigger both data and child watches, eliminate duplicates by uniquely triggering based on path/watcher pairs. (process the data watches, process the child watches filtering out any dups from being generated).

  • Patrick Hunt

    Patrick Hunt - 2008-06-03
    • assigned_to: nobody --> breed
  • Benjamin Reed

    Benjamin Reed - 2008-06-03

    Logged In: YES
    Originator: YES

    I don't think we want another list, that will just make things more complicated.

    Option 2 is best since triggerWatch already builds a HashSet that we can simply return.

  • Patrick Hunt

    Patrick Hunt - 2008-06-10
    • status: open --> closed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks