Couchbase Connection leaks to a single node in the cluster

We are observing 2x the number of connections open on a single node in a given Couchbase cluster. All connections are on port 11210.

The development team believes they have identified a bug that creates this behavor during a cluster change and a new map being distributed to the Couchbase clients. Below is their observation.
... there in the list to randomize the nodes, but there’s a bug in the constructor of Couchbase SDK class com.couchbase.client.vbucket.provider.BucketConfigurationProvider

Here’s the code:

public BucketConfigurationProvider(final List<URI> seedNodes,
final String bucket, final String password,
final CouchbaseConnectionFactory connectionFactory)

{ config = new AtomicReference<Bucket>(); configurationParser = new ConfigurationParserJSON(); httpProvider = new AtomicReference<ConfigurationProviderHTTP>( new ConfigurationProviderHTTP(seedNodes, bucket, password) ); refreshingHttp = new AtomicBoolean(false); pollingBinary = new AtomicBoolean(false); observers = Collections.synchronizedList(new ArrayList<Reconfigurable>()); binaryConnection = new AtomicReference<CouchbaseConnection>(); this.seedNodes = Collections.synchronizedList(new ArrayList<URI>(seedNodes)); this.bucket = bucket; this.password = password; this.connectionFactory = connectionFactory; potentiallyRandomizeNodeList(seedNodes); disableCarrierBootstrap = Boolean.parseBoolean( CouchbaseProperties.getProperty("disableCarrierBootstrap", "false")); disableHttpBootstrap = Boolean.parseBoolean( CouchbaseProperties.getProperty("disableHttpBootstrap", "false")); }

The potentiallyRandomizeNodeList method will randomize the list passed to it and in fact, in our clients we ARE randomizing the two-element list we are passing.
Unfortunately, the wrong list is being passed to this method. The code should be randomizing the list stored as a member variable.
The line should read
potentiallyRandomizeNodeList(this.seedNodes);

because four lines above a completely new list is constructed by making a shallow copy of the input argument, seedNodes.

The list later used to get the configuration information is always used ordered and that’s why all our management connections are to the same node, the first one in our list.

I found this in v1.4.2 of the client, but v1.4.4 seems to have the same code so I don’t think it’s been fixed yet.