kezhuw commented on PR #1899: URL: https://github.com/apache/zookeeper/pull/1899#issuecomment-1188893150
I found this in reproducing [CURATOR-593](https://issues.apache.org/jira/browse/CURATOR-593) and [CURATOR-611](https://issues.apache.org/jira/browse/CURATOR-611). Curator [EnsembleTracker](https://github.com/apache/curator/blob/master/curator-framework/src/main/java/org/apache/curator/framework/imps/EnsembleTracker.java) uses [getConfig](https://github.com/apache/curator/blob/master/curator-framework/src/main/java/org/apache/curator/framework/imps/EnsembleTracker.java#L157) to track zookeeper ensemble changes. It [ignores](https://github.com/apache/curator/blob/master/curator-framework/src/main/java/org/apache/curator/framework/imps/EnsembleTracker.java#L113) illegal path event from buggy stripping. But after ZooKeeper [3.6.3](https://github.com/apache/zookeeper/blob/release-3.6.3/zookeeper-server/src/main/java/org/apache/zookeeper/ZooKeeper.java#L627), the illegal path causes exception inside ZooKeeper client and hence disconnection. CURATOR-593/CURATOR-611 are blocked by this as `getConfig` watcher will not receive event from chroot client. > This is a special case which can be handled if needed. Doing the larger refactor would definitely break backward compatibility. I agree. I think we can intercept `getConfig` watcher to pass "/zookeeper/config" to original watcher. This is a breaking change to old behavior though probably not by design. I guess it might be an opportunity to define and document semantics of `getConfig` watcher. Anyway, semantics of `getConfig` watcher could be a separate issue. And this pr should not break anything. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@zookeeper.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
