[
https://issues.apache.org/jira/browse/CURATOR-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan Zimmerman updated CURATOR-332:
-------------------------------------
Description:
The WatcherRemoveCuratorFramework introduced in 3.0.0 doesn't track watchers
correctly and can sometimes lose track of some watchers and, thus, not delete
them when requested to. Examples:
* Exists watchers stay set even when there is a NoNode exception
* If a watcher is successfully set and then the same watcher is used during a
network failure, WatcherRemoveCuratorFramework will clear the watcher
internally.
was:
The WatcherRemoveCuratorFramework introduced in 3.0.0 doesn't track watchers
correctly and can sometimes lost track of some watchers and, thus, not delete
them when requested to. Examples:
* Exists watchers stay set even when there is a NoNode exception
* If a watcher is successfully set and then the same watcher is used during a
network failure, WatcherRemoveCuratorFramework will clear the watcher
internally.
> Internal watcher tracking for new WatcherRemoveCuratorFramework feature is
> not correct
> --------------------------------------------------------------------------------------
>
> Key: CURATOR-332
> URL: https://issues.apache.org/jira/browse/CURATOR-332
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework, Recipes
> Affects Versions: 3.1.0
> Reporter: Jordan Zimmerman
> Assignee: Jordan Zimmerman
> Fix For: 3.2.0
>
>
> The WatcherRemoveCuratorFramework introduced in 3.0.0 doesn't track watchers
> correctly and can sometimes lose track of some watchers and, thus, not delete
> them when requested to. Examples:
> * Exists watchers stay set even when there is a NoNode exception
> * If a watcher is successfully set and then the same watcher is used during a
> network failure, WatcherRemoveCuratorFramework will clear the watcher
> internally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
