Нет физического адреса для x, удаление сообщения при перезапуске узла в кластере jgroups

Журнал моего узла заполнен предупреждающим сообщением «Отбрасывание одноадресного сообщения в неправильное место назначения» при перезапуске одного из узлов в кластере. мы используем Jgroups, TCP, версию jgroups-3.4.1.Final. Мой сервер не подходит, с этими предупреждающими сообщениями, заразно выброшенными

Ниже приведены предупреждающие сообщения [0;33mWARN [TransferQueueBundler,h-broadcast,h-13] [TCP] JGRP000032: h-13: нет физического адреса для 8281f201-7fb1-f6ac-faf3-d6837bc39087, сбрасывается сообщение

[0;33mWARN [INT-1,h-broadcast,h-13] [TCP] JGRP000031: h-13: отбрасывание одноадресного сообщения в неверный пункт назначения d205fcba-151c-ad58-8323-fe4f49117f88

Пожалуйста, дайте мне знать, как решить эту проблему

Спасибо, Ниведита.

<TCP loopback="true" 
    recv_buf_size="${tcp.recv_buf_size:20M}" 
    send_buf_size="${tcp.send_buf_size:640K}"
    discard_incompatible_packets="true" 
    max_bundle_size="64K" 
    max_bundle_timeout="5" 
    enable_bundling="true" 
    use_send_queues="true"
    sock_conn_timeout="300" 
    timer_type="new" 
    timer.min_threads="4" 
    timer.max_threads="10" 
    timer.keep_alive_time="3000"
    timer.queue_max_size="500" 
    thread_pool.enabled="true" 
    thread_pool.min_threads="4" 
    thread_pool.max_threads="10"
    thread_pool.keep_alive_time="5000" 
    thread_pool.queue_enabled="true" 
    thread_pool.queue_max_size="100000"
    thread_pool.rejection_policy="discard" 
    oob_thread_pool.enabled="true" 
    oob_thread_pool.min_threads="1"
    oob_thread_pool.max_threads="8" 
    oob_thread_pool.keep_alive_time="5000" 
    oob_thread_pool.queue_enabled="false"
    oob_thread_pool.queue_max_size="100" 
    oob_thread_pool.rejection_policy="discard" 
    bind_addr="${hybris.jgroups.bind_addr}" 
    bind_port="${hybris.jgroups.bind_port}" />
<TCPPING timeout="3000" 
    initial_hosts="xxx.xx.xx.4[7800],xxx.xx.xx.5[7800],xxx.xx.xx.6[7800], xxx.xx.xx.7[7800], xxx.xx.xx.8[7800], xxx.xx.xx.9[7800], xxx.xx.xx.10[7800], xxx.xx.xx.11[7800], xxx.xx.xx.12[7800], xxx.xx.xx.13[7800], xxx.xx.xx.68[7800], xxx.xx.xx.69[7800], xxx.xx.xx.70[7800], xxx.xx.xx.4[7800], xxx.xx.xx.5[7800], xxx.xx.xx.6[7800]" 
    num_initial_members="16"/>

<MERGE2 min_interval="10000" max_interval="30000" />
    <FD_SOCK />
    <FD timeout="3000" max_tries="3" />
    <VERIFY_SUSPECT timeout="1500" />
    <BARRIER />
    <pbcast.NAKACK use_mcast_xmit="false" exponential_backoff="500" discard_delivered_msgs="true" />
    <UNICAST2 />
    <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="4M" />
    <pbcast.GMS print_local_addr="true" join_timeout="3000" view_bundling="true" />
    <UFC max_credits="20M" min_threshold="0.4" />
    <MFC max_credits="20M" min_threshold="0.4" />
    <FRAG2 frag_size="60K" />
    <pbcast.STATE_TRANSFER />

jgroups
person Nivedita Dixit    schedule 28.04.2016    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Большое спасибо за предложения. Узлы кластера самовосстановились, когда один из проблемных узлов вышел из строя (он не мог подключиться через telnet по сравнению с другими узлами, которые могли подключиться через telnet)

person Nivedita Dixit    schedule 01.05.2016
comment
я не могу получить этот ответ четко. у меня такая же проблема! как мне настроить в кластере jgroups? - person Nandhakumar Kittusamy; 17.08.2017
comment
Среди узлов в кластере у одного из узлов возникла проблема с сетью, мы не смогли подключиться к нему через telnet через порт 7800. Когда этот неисправный узел был удален из кластера, узлы самовосстановились и присоединились к кластеру. - person Nivedita Dixit; 19.08.2017
comment
В любом случае, спасибо за ваше решение! В моем случае я могу подключить узел с помощью telnet, но он не может присоединиться к кластеру. Я не знаю, где проблема. - person Nandhakumar Kittusamy; 19.08.2017

arrow_upward
2
arrow_downward

Я предполагаю, что вы используете TCP:TCPPING? Вы перечисляете всех участников в TCPPING.initial_hosts? Это наиболее вероятная причина предупреждений выше.

Существует кэш, отображающий UUID (внутреннее представление членов кластера JGroups) в физические адреса в каждом элементе.

Посмотреть содержимое можно либо через JMX, либо через probe.sh uuids. В h13 должно быть сопоставление для 8281f201-7fb1-f6ac-faf3-d6837bc39087, но оно отсутствует. Опять же, скорее всего потому, что h13 нет в списке TCPPING.

Вы можете попробовать альтернативный протокол обнаружения (например, MPING, если поддерживается многоадресная IP-рассылка, FILE_PING, для которого требуется общая файловая система, TCPGOSSIP с внешней службой поиска и т. д.). Подробности смотрите в руководстве.

person Bela Ban    schedule 29.04.2016
comment
Да, мы перечислили все хосты в атрибуте initial_hosts в файле jgroups-tcp.xml. мы работаем в лазурном облаке, которое не поддерживает многоадресную рассылку, поэтому мы не можем использовать многоадресную рассылку. . Пожалуйста, найдите ниже конфигурацию jgroups-tcp.xml - person Nivedita Dixit; 29.04.2016
comment
Вставил конфигурацию jgroups-tcp.xml в вопрос - person Nivedita Dixit; 29.04.2016
comment
Пробовал с помощью команды Probe, но ничего не возвращается. Если Probe использует многоадресную рассылку, думаю, мне это не подойдет. Не могли бы вы помочь, если я могу использовать какой-либо альтернативный механизм - person Nivedita Dixit; 29.04.2016
comment
probe.sh -add x.x.x.4 подключается к одному из узлов, получает адреса остальных и затем подключается ко всем участникам. - person Bela Ban; 02.05.2016

arrow_upward
0
arrow_downward

Я столкнулся с этой проблемой на этой неделе и настраивал брандмауэр, чтобы JGroups работал в течение нескольких дней, пока сегодня я не переключил стек JGroup с UDP на TCP, и внезапно все проблемы исчезли.

person Wey Gu    schedule 17.03.2021