cxzl25 commented on code in PR #7558:
URL: https://github.com/apache/kyuubi/pull/7558#discussion_r3622952086
##########
kyuubi-ha/src/main/scala/org/apache/kyuubi/ha/client/zookeeper/ZookeeperDiscoveryClient.scala:
##########
@@ -416,6 +549,14 @@ class ZookeeperDiscoveryClient(conf: KyuubiConf) extends
DiscoveryClient {
" ZooKeeper. The server will be shut down after the last client
session completes.")
ZookeeperDiscoveryClient.this.deregisterService()
serviceDiscovery.stopGracefully()
+ } else if (event.getType == Watcher.Event.EventType.NodeCreated) {
Review Comment:
Sorry for the late reply.
We encountered several ZooKeeper-related issues.
1. We previously attempted to re-register the watcher unconditionally within
`DeRegisterWatcher` whenever any event was received. However, under certain
circumstances, this produced adverse side effects and prevented ZooKeeper from
reconnecting when exceptions occurred.
https://github.com/apache/kyuubi/issues/6477
2. In the early phase, we faced unexpected closures of ZooKeeper sessions.
After investigation, we found it was related to this ticket:
https://issues.apache.org/jira/browse/ZOOKEEPER-1622
3. We removed `ConnectionStateListenable` in our internal build. Although
Kyuubi supports self-recovery to the `RECONNECTED` state after entering the
`LOST` state, Curator will not attempt to reconnect to ZooKeeper without any
API invocations via zkclient.
Regarding the rewatch logic you plan to implement: is there a possibility
that when you trigger watch re-registration, the server registers another
identical engine instance?
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
