Изменение конфигурации между двумя поведением Hazelcast Nodes Behavior?

Question

Я использую Hazelcast (ver3.2), чтобы иметь распределенный вызов между двумя работающими экземплярами приложения (два разных JVM-интерфейса, узлы подключаются через tcp). Каждый из моих экземпляров является узлом, и каждый из моих экземпляров имеет Асинхронные клиенты.

По какой-то причине я должен изменить максимальный размер моего распределенного запроса и процесса резервного копирования (от асинхронного до синхронизации). Мне нужно, чтобы по крайней мере один из моих экземпляров запускался каждый раз, я изменил конфигурацию оребренного дерева для каждого экземпляра и перезапустил экземпляры один за другим (tomcat).

Мой вопрос:Будет ли конфигурация дифференциалов быть проблема?

Моя распределенная очередь настроена в файле hazelcast-config каждого из моих экземпляров (узлов).

Другой вопрос:ли мой Distributed Queue должен быть только лишь в одном из файлов конфигурации узлов Hazelcast? Если два узла являются частью кластера, DistributedQueue должен быть объявлен с каждой стороны или только с одним?

Благодаря

ОБНОВЛЕНИЕ

я выполнил быстрый тест с использованием двух узлов, начиная локальные и два различных configiration: один с распределенной очередью под названием «testQueue» с максимальным размером = 90, а другими один с тем же именем очереди, но с максимальным размером = 70.

@Test 
    public void twoNodesWithDifferentQueueConfiguration() throws Exception { 


    Config config1 = new ClasspathXmlConfig("hazelcast-node-1-config.xml"); 
    HazelcastInstance hz1 = Hazelcast.newHazelcastInstance(config1); 

    Config config2 = new ClasspathXmlConfig("hazelcast-node-2-config.xml"); 
    HazelcastInstance hz2 = Hazelcast.newHazelcastInstance(config2); 


    System.out.println("Local Queue of Hz1 remaining capacity : "+hz1.getQueue("testQueue").remainingCapacity()); 
    System.out.println("Local Queue of Hz2 remaining capacity : "+hz2.getQueue("testQueue").remainingCapacity()); 
    HazelcastInstance hazelcastClient = HazelcastClient.newHazelcastClient(getClientConfig()); 

    hazelcastClient.getQueue("testQueue").add(UUID.randomUUID().toString()); 

    System.out.println("Local Queue of Hz1 remaining capacity : "+hz1.getQueue("testQueue").remainingCapacity()); 
    System.out.println("Local Queue of Hz2 remaining capacity : "+hz2.getQueue("testQueue").remainingCapacity()); 

} 

Два узла соединяются друг с другом и образуют кластер. Если использовать простой java-клиент и добавить элемент в очередь, называемую «testQueue», максимальный размер остатка очереди выглядит для каждого узла другим.

Local Queue of Hz1 remaining capacity : 90 
Local Queue of Hz2 remaining capacity : 70 
mai 18, 2016 3:54:30 PM com.hazelcast.core.LifecycleService 
INFOS: HazelcastClient[hz.client_0_test2] is STARTING 
mai 18, 2016 3:54:30 PM com.hazelcast.core.LifecycleService 
INFOS: HazelcastClient[hz.client_0_test2] is STARTED 
mai 18, 2016 3:54:30 PM com.hazelcast.core.LifecycleService 
INFOS: HazelcastClient[hz.client_0_test2] is CLIENT_CONNECTED 
mai 18, 2016 3:54:30 PM com.hazelcast.client.spi.ClientClusterService 
INFOS: 

Members [2] { 
    Member [127.0.0.1]:5701 
    Member [127.0.0.1]:5702 
} 

Local Queue of Hz1 remaining capacity : 89 
Local Queue of Hz2 remaining capacity : 69 

Но это один и тот же объект распределенный право?

Answer 1

Будет ли проблема с конфигурацией проблемой?

Да. Конфигурации должны быть одинаковыми для всех узлов и должны быть определены в начале. Я считаю, что «на лету» конфигурации еще не поддерживаются.

Должен ли мой распределенный заказ находиться только в одном из узлов Файлы конфигурации Hazelcast? Если два узла входят в кластер, , DistributedQueue должен быть объявлен с каждой стороны или только с одним?

Если вы используете XML-способ настройки Hazelcast, тогда вы можете определить конфигурацию очереди в этом самом. Если вы начинаете программно, то определения в одном месте достаточно. Обратите внимание, что это распределенная структура данных, поэтому, как только вы определяете ее в одном узле, она распределяется по кластеру &.