Блог

Главная - Вопросы по программированию - Первый узел hazelcast завершает работу вместо того, чтобы стать ведущим

Первый узел hazelcast завершает работу вместо того, чтобы стать ведущим

#java #spring-boot #tcp #hazelcast #distributed-cache

#java #весенняя загрузка #tcp #hazelcast #распределенный кэш

Вопрос:

Я пытаюсь сформировать кластер, используя обнаружение tcp / ip. Я не могу понять, почему первый узел не выбирается в качестве основного. В кластере нет других узлов. И журналы ошибок не говорят сами за себя.

Журналы отладки :

2020-10-27 05:31:46 ОТЛАДКА com.hazelcast.internal.cluster.ClusterService:49 - [192.168.10.31]:5701 [dev] [3.12] Установка главного адреса в null
2020-10-27 05:31:46 ОТЛАДКА com.hazelcast.cluster.impl.TcpIpJoiner:49 - [192.168.10.31]:5701 [dev] [3.12] Мастер PostJoin: null, isMaster: false
2020-10-27 05:31:46 ОШИБКА com.hazelcast.instance.Node:49 - [192.168.10.31]:5701 [dev] [3.12] Не удалось присоединиться к кластеру. Завершаем работу сейчас!
2020-10-27 05:31:46 ИНФОРМАЦИЯ com.hazelcast.core.LifecycleService:49 - [192.168.10.31]:5701 [dev] [3.12] [192.168.10.31]: 5701 ЗАВЕРШАЕТ РАБОТУ
2020-10-27 05:31:46 ПРЕДУПРЕЖДЕНИЕ com.hazelcast.instance.Node:49 - [192.168.10.31]:5701 [dev] [3.12] Принудительное завершение...
2020-10-27 05:31:46 ОТЛАДКА com.hazelcast.internal.cluster.ClusterService:49 - [192.168.10.31]:5701 [dev] [3.12] Установка главного адреса в null
2020-10-27 05:31:46 ИНФОРМАЦИЯ com.hazelcast.instance.Node:49 - [192.168.10.31]:5701 [dev] [3.12] Завершение работы диспетчера соединений...

Версия Hazelcast: 3.12

 <dependency>
  <groupId>com.hazelcast</groupId>
  <artifactId>hazelcast</artifactId>
  <version>3.12</version>
</dependency>

Конфигурация Hazelcast :

 String hazelcastClusterMemberOne = 192.168.10.*
Config config = new Config();
        NetworkConfig network = config.getNetworkConfig();
        JoinConfig join = network.getJoin();
        join.getMulticastConfig().setEnabled(false);
        join.getTcpIpConfig().addMember(hazelcastClusterMemberOne)
                .setEnabled(true);

        HazelcastInstance hazelcast = Hazelcast.newHazelcastInstance(config);

Журналы ошибок :

2020-10-27 05:31:46 [основная] ОШИБКА com.hazelcast.instance.Узел com.hazelcast.instance.Node:49 - [192.168.10.31]:5701 [dev] [3.12] Не удалось присоединиться к кластеру. Завершаем работу сейчас!
2020-10-27 05:31:46 [главная] ИНФОРМАЦИЯ com.hazelcast.core.LifecycleService com.hazelcast.core.LifecycleService:49 - [192.168.10.31]:5701 [dev] [3.12] [192.168.10.31]: 5701 ЗАВЕРШАЕТ РАБОТУ
2020-10-27 05:31:46 [main] ПРЕДУПРЕДИТЬ com.hazelcast.instance.Узел com.hazelcast.instance.Node:49 - [192.168.10.31]:5701 [dev] [3.12] Завершается принудительно...
2020-10-27 05:31:46 [главная] ИНФОРМАЦИЯ com.hazelcast.instance.Узел com.hazelcast.instance.Node:49 - [192.168.10.31]:5701 [dev] [3.12] Завершение работы диспетчера соединений...

РЕДАКТИРОВАТЬ: это происходит на сервере, который размещен в облаке AWS, но приведенная выше конфигурация отлично работает на моем локальном компьютере

Ответ №1:

Попробуйте изменить подстановочный знак на явный IP-адрес.

Т.Е. Нет

 getTcpIpConfig().addMember("192.168.10.*")
                .setEnabled(true);

но

 getTcpIpConfig().addMember("192.168.10.1")
                .setEnabled(true);

Или, если вам нужно несколько возможностей, перечислите их явно

 getTcpIpConfig().addMember("192.168.10.1")
                .addMember("192.168.10.2")
                .addMember("192.168.10.3")
                .setEnabled(true);

ОБНОВЛЕНО НИЖЕ

TcpIpConfig не был предназначен для использования с широким спектром возможностей. Wwildcard не реализован для этого поля. Вы можете перечислить все 256 возможностей или отправить подстановочный знак, реализующий PR. В любом случае для проверки требуется 256 портов, что будет медленным.

Если вы знаете адрес первого узла во время выполнения, вы можете передать его другим как свойство.

Если вы этого не сделаете, то один из других механизмов обнаружения, вероятно, будет лучшим выбором.

Обратите внимание также, TcpIpConfig что это просто спецификация для механизма обнаружения, а не механизм связи после обнаружения. Производительность взаимодействия между участниками не связана с выбором механизма обнаружения.

ОБНОВЛЕНО 2 НИЖЕ Приведенный выше ответ неверен, теперь, попробовав его с 3.12.0, реализован подстановочный знак.

Комментарии:

1. Причина, по которой я указал подстановочный знак, заключается в том, что IP-адреса участников не являются статическими и могут варьироваться от 0 до 255

2. Понятно, я обновил свой ответ более подробно.

3. У меня создалось впечатление, что поддерживается подстановочный знак, вот что меня сбило с толку! Спасибо! Но есть идеи, почему подстановочный знак работал в моей локальной настройке?

4. Привет, да, похоже, что это так, на самом деле попробовав это. Так что это не проблема. Я вижу, что вы используете AWS, поэтому, возможно, плагин AWS Discovery станет выходом из положения. Тем не менее, все равно было бы полезно узнать, в чем причина ошибки в AWS. У вас есть еще журналы, которыми вы можете поделиться? Если вы пытаетесь использовать диапазон IP-адресов, возможно, вы находите чужой кластер и вам отказывают в подключении к нему.

5. В журналах я вижу, что узел отправляет главный вопрос всем IP-адресам в списке участников. Некоторые IP-адреса возвращаются в список. Когда узел утверждает, что он является ведущим, возникает следующая ошибка: 2020-10-27 05:31:46 DEBUG com.hazelcast.cluster.impl.TcpIpJoiner:49 - [192.168.10.31]:5701 [dev] [3.12] com.hazelcast.spi.exception.RetryableIOException: Packet not sent to -> [192.168.10.111]:5703 over null после этого главный адрес устанавливается как null, и узел завершает работу.