Menu
▾
▴
[Zookeeper-developer] [ zookeeper-Bugs-1981340 ] Child watches are not triggered when the node is deleted
|
From: SourceForge.net <no...@so...> - 2008-06-10 21:24:03
|
Bugs item #1981340, was opened at 2008-06-01 08:05 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1981340&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 3.0.0 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: Benjamin Reed (breed) Summary: Child watches are not triggered when the node is deleted Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 14:24 Message: Logged In: YES user_id=12853 Originator: NO Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-20 ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-06-03 11:44 Message: Logged In: YES user_id=154690 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. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-06-03 11:27 Message: Logged In: YES user_id=12853 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). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1981340&group_id=209147 |
