Persistent connections should be indexed on server list contents, not their order.

In the current state, we simply treat the connection parameter as a string.

An example use case may be of several clients trying to load-balance between various entry points nodes (EPTs). Such a strategy ensures that they aren't all hitting the same node for configuration requests.

However when attempting to use this in conjunction with persistent connections, we have the consequence that each permutation of the "Server List" is treated as a separate key when using persistent connections; therefore something like:

$base_list = array("1.1.1.1", "2.2.2.2", "3.3.3.3", "4.4.4.4");

for ($i = 0; $i < 1000; $i++)

{ $cur_list = $base_list; shuffle($cur_list); $cb = new Couchbase($cur_list, "", "", "", true); $cb->set("foo", "bar"); // other operations }

In a nutshell, this code has a "base" set of four servers. In the "normal" initialization code, the list is copied and then shuffled around, so that the first server in the list is always something else. Since the first server in the list ends up becoming the EPT (unless the server is down, in which case the next node is used, etc.) this enables some kind of cheap load balancing.

However this also means the order of the array is different, which means the "canonical connection key" is different, which means that when considering whether an existing connection is available, a new one is created. Since we have 4 servers in the list, there is a potential of having 4*4=16 different client objects per process. These objects will never die.

The solution is then to "deconstruct" the connection string in such a way that the server list itself is always alphabetically sorted. The effective list (When actually connecting) will remain the same, but for indexing purposes, it shall be sorted.