compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (20)

View Page History
h2. Details:

h4. Terminology

*{_}supplied-list: _{*}The list of bootstrap nodes supplied to the client library by the administrator or the developer.
*{_}derived-list:_* The list of bootstrap nodes retrieved from the cluster when a valid config is received.  Typically this will be a superset of the supplied list.  This may be 

This project would be a simple set of changes per client library.  In the end, each client library must have a way to configure...
# A supplied-list of bootstrap URIs (this already exists)
# A way to configure the client to use those URIs the supplied-list either...
## In order supplied (thus, every client will deterministically have the same configuration)
##  
## In a random order (thus, clients could end up in different places if not all of the URIs go to the same cluster).  This _must_ be the *default* for the client library.
# A configuration file approach, idiomatic to the platform (i.e. yaml for Ruby, properties files for Java) which can allow for the reconfiguration of URIs without restarting the application.

## In the order supplied (thus, every client will deterministically have the same configuration).  This _must_ be *optional* and configurable.  This project won't specify how the order happens.  It may be a List type for Java and an array of strings for node.js, for instance.
# A configuration file approach, idiomatic to the platform (i.e. yaml for Ruby, properties files for Java) which can allow for the reconfiguration of URIs without restarting the application.  This reconfiguration file _must not_ be re-read during operation.  It is to be used only at application startup time.

The sequence of operations for a client can be fairly easily described.


# Client determines if RANDOM or ORDERED is specified by the application developer via either file based configuration (i.e., .properties \[Java\] or app.config \[.NET\]) or simple code changes (i.e., editing the .php or .py file).
## If RANDOM, client selects one of the nodes in the supplied-list at random
## If ORDERED, client selects the first node in the supplied -list
# Client connects to and bootstraps against that node, following the hyperlink chain in a proper RESTful style
# After getting a valid configuration from the bootstrap, the client updates it's internal list derived-list with all nodes the configuration deems valid.

On topology change...
# Client receives configuration updates from the cluster as nodes are rebalanced in and start supplying services.  When the new configuration is received, the client's internal list derived-list of nodes is atomically swapped after configuration validation.

h3. Bootstrap of Client With a List of Four Nodes, One Down\\

# Client determines if RANDOM or ORDERED is specified by the application developer via either file based configuration (i.e., .properties \[Java\] or app.config \[.NET\]) or simple code changes (i.e., editing the .php or .py file).
## If RANDOM, client selects one of the nodes in the supplied-list at random
## If ORDERED, client selects the first node in the supplied -list
# Client attempts to bootstrap against the _down_ node, and fails to connect after a reasonable time interval of not more than five seconds. If possible, the client logs the problem at the warning level.
# Client revisits the list
## If RANDOM, client selects another node at random from the supplied-list, ensuring that the same node is not selected
## If ORDERED, client selects the next node in the supplied-list
# Client connects to and bootstraps against that node, following the hyperlink chain in a proper RESTful style
# After getting a valid configuration from the bootstrap, the client updates it's internal list derived-list with all nodes the configuration deems valid.

On topology change...

h3. Bootstrap of Client With a List of Four Nodes, All Down or Unreachable\\

# Client determines if RANDOM or ORDERED is specified by the application developer via either file based configuration (i.e., .properties \[Java\] or app.config \[.NET\]) or simple code changes (i.e., editing the .php or .py file).
## If RANDOM, client selects one of the nodes in the list at random

h3. Other Notes

Note that this functionality is NOT intended to allow one to switch clusters dynamically. The bootstrap list would only be updated based on configuration streams sent from the cluster. Change to the configuration file backing the client would only be picked up if the application was restarted.