Couchbase Client Java SDK не использует другой узел кластера, когда первый не отвечает

Question

Итак, согласно этой странице: http://developer.couchbase.com/documentation/server/current/sdk/java/start-using-sdk.html

// Connects to a cluster on 10.0.0.1 and tries 10.0.0.2
// if the other one does not respond during bootstrap.
Cluster cluster = CouchbaseCluster.create("10.0.0.1", "10.0.0.2");

Кажется, я открываю проект Maven в Eclipse. Использование последней версии Java SDK для клиента couchbase:

<dependency>
    <groupId>com.couchbase.client</groupId>
    <artifactId>java-client</artifactId>
    <version>2.3.4</version>
</dependency>

Мой код, короткий и сладкий:

import com.couchbase.client.java.Cluster;
import com.couchbase.client.java.CouchbaseCluster;

public class Main {
    public static void main(String[] args){
        Cluster cluster = CouchbaseCluster.create("10.200.0.10", "10.200.0.11", "10.200.0.12");
        System.out.println(cluster.clusterManager("Administrator", "password").info().raw());
    }
}

Мой кластер Couchbase состоит из трех узлов на трех виртуальных машинах. Развернут с докером. Они прекрасно работают, и у меня есть другое приложение, использующее все замечательные функции SDK, но я обнаружил, что что-то ломается, когда я делаю тестирование:

Если я запускаю приведенный выше код, когда узел 10.200.0.11 или / и узел 10.200.0.12 не работает, все хорошо. Я получаю хороший JSON в консоли, включая детали на всех трех узлах!

Проблема: если я запускаю этот код, а узел 10.200.0.10 не работает, он не пытается загрузиться с использованием двух других узлов, как указано в их примере из их документации. Вместо этого и Eception бросается, и приложение заканчивается.

Ошибка:

WARNING: [null][ConfigEndpoint]: Could not connect to remote socket.
Exception in thread "main" java.lang.RuntimeException: java.net.ConnectException: Connection refused: /10.200.0.10:8091
    at     com.couchbase.client.core.utils.Blocking.blockForSingle(Blocking.java:85)
    at com.couchbase.client.java.cluster.DefaultClusterManager.info(DefaultClusterManager.java:59)
    at com.couchbase.client.java.cluster.DefaultClusterManager.info(DefaultClusterManager.java:54)
    at quickTestDeleteThis.Main.main(Main.java:10)
Caused by: java.net.ConnectException: Connection refused: /10.200.0.10:8091
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
    at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
    at com.couchbase.client.deps.io.netty.channel.socket.nio.NioSocketChannel.do    FinishConnect(NioSocketChannel.java:223)
    at com.couchbase.client.deps.io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:285)
    at   com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:589)
    at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:513)
    at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:427)
    at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:399)
    at com.couchbase.client.deps.io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:140)
    at com.couchbase.client.deps.io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
    at java.lang.Thread.run(Thread.java:745)
Nov 02, 2016 4:45:22 PM com.couchbase.client.core.endpoint.AbstractEndpoint$2 operationComplete
WARNING: [null][ConfigEndpoint]: Could not connect to remote socket.

Я предполагаю, что это может быть связано с тем, что 10.200.0.10 является оркестратором, и никакой новый оркестратор не будет отвечать информацией о кластере. Но согласно документации по архитектуре Couchbase: http://www.couchbase.com/sites/default/files/uploads/all/whitepapers/Couchbase_Server_Architecture_Review.pdf

Если происходит сбой узла оркестратора, существующие узлы обнаружат, что он больше не доступен, и немедленно выберут нового оркестратора, чтобы кластер продолжал работать без сбоев.

Казалось бы, если соединение с первым узлом в списке узлов в объекте Cluster не может быть подключено, значит, оно не пробует другую, возможную ошибку?

Answer 1

Известная проблема, которая в настоящее время устраняется. Можно найти здесь: https://issues.couchbase.com/browse/JCBC-999