THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- What resources should we support?
- How would we update them? What would be the security mechanisms used to access them?
- How would we ensure that the external resource has the correct version of the server list, especially, when concurrent server reconfigurations are in progress?
It is difficult to implement a generic mechanism in the client library to address these problems. There are many options for external resource (HTTP, DNS, NFS, LDAP, virtual IP, etc). From security mechanisms view point; there are many solutions as well and some of them could require tedious setup. Even if we resolve this problemFurther, the processing process of updating a resource is not simple. The process that updates the external resources must ensure that only the most recent server list gets recorded at the resource. We could add the capability in the client library to record that records a union of the old and new server configuration at the URL, perform performs the reconfiguration, and then update updates the URL to with the most modified server list. However, the client library would also need to handle failures that may occur in this 3-step process. Further, if the application performs concurrent reconfigurations (which is supported by the server), then the client library would need to resolve race conditions to ensure that the result of last successful configuration is correctly recorded. In order to synchronize updates, the client library would need the external resource to support some atomic primitives (e.g., for locking and fencing).
Considering the complexity of the problem, in the first version, we propose to not implement any mechanisms to update the external resource. The ZooKeeper application would need to implement its own mechanism to update the URL. We expect that in most cases the change in ZooKeeper configuration will be an administrative process. Therefore, the Administrator can easily ensure that the URL is kept up-to-date. When we gain more experience in the future, we could consider adding this part the client library.
...
- h1:port1,h2:port2/path (current format unchanged)
- zk://h1:port1,h2:port2!/path (new format to specify host:port connection string)
- http://abc.com/serversserves.txt!/path (the client library will use http to retrieve the server list)
- file:///a/b/c/server.txt!/path (read the server list from a file)
...
If the URL protocol is either HTTP or file, then the client library will periodically check the resource and update its in-core server list. If the protocol is “zk” “zk” or the traditional connection string is used, then the client library will periodically resolve the DNS names, if needed. The refresh and/or name resolution will be enabled by default.
...
TBD: We could add a new constructor to specify these options, but I prefer it would be good to avoid creating new constructors for every feature.
If the server list retrieved from the URL does not include the server that the client is currently connected to, then the client will disconnect from the server and attempt to reconnect to other servers (using the new list). Otherwise, the new list will be used next time when the client attempts to connect to a server.
The server list stored in the URL will be the usual ZooKeeper configuration file (zoo.cfg) with the following exceptions:
- A new optional property “version” “
version” will added to the configuration file. The version number indicates the reconfiguration version number and should match with the version number of the current server configuration returned byZooKeeper.getConfig()(see [1],[2] for further details). The version number, when specified, will be used to ensure that the client will be choose the new server list only if the version number of the list is higher than the current version number. - The “
server.x=host:serverPort:electionPort” property will be changed to “server.x=host:serverPort:electionPort:clientPort”.
...
- A tool to update a password protected HTTP URL.
- Avoid URL refresh from the same JVM for each client. This problem is similar to implementing shared sessions.
- Support for DNS based discovery at the client?
- For applications that want to use protocols other than file or URL, we could provide a callback mechanism. When the client library needs to retrieve the server list, it will invoke the callback method in the application. It will be responsibility of the application to discover the server list.
- For applications do not have an external web server or file server to record the configuration, we can implement the solution using virtual IPs described in ZOOKEEPER-1031.
...
...
F. References
...
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|