kezhuw commented on PR #2069: URL: https://github.com/apache/zookeeper/pull/2069#issuecomment-1740226666
> trying to dynamically set a system property prior to calling an API method doesn't seem like a great option. `quorumSync` is a server side property, client are innocent to this. > It seems unreliable if programmers don't know how the ZK servers are configured ZooKeeper have both client API and server daemon, it is somewhat inevitable if we change server side behavior of an api. `quorumSync` is provided mainly for feature gate and rolling upgrade. I was thinking to [bump protocol version](https://github.com/apache/zookeeper/pull/2070#discussion_r1338287108)(a.k.a. `sync` is a quorum only if all server are upgraded to 3.10.0) so we don't need it in rolling upgrade. I am ok to drop it if that is solved and we don't want a feature gate for this. > Wouldn't it be better to have an explicit public API method for this? Not sure. I think `sync` fits this purpose naturally, otherwise we won't have to explain about [`sync` + `read`](https://zookeeper.apache.org/doc/r3.9.0/zookeeperInternals.html#sc_consistency). **I think the question for us should be "Is it a bug for `sync` + `read` to read dated data ?"** If it is yes, then all above questions shouldn't be issues. Otherwise, we should resort to new apis as you said, for example [ZOOKEEPER-3600](https://issues.apache.org/jira/browse/ZOOKEEPER-3600)(https://github.com/apache/zookeeper/pull/1137). I am leaning towards it is a bug, so here we are. -- 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
