Wildfly 9: JGRP000012: отброшенное сообщение из другого кластера hq-cluster (наш кластер ee)

После того, как мы обновились с Wildfly 8.2.1.Final до Wildfly 9.0.1.Final, мы начали получать много предупреждений, таких как следующие:

WARNING [org.jgroups.protocols.TCP] (INT-1,ee,dev6.example.com:server1) JGRP000012: discarded message from different cluster hq-cluster (our cluster is ee). Sender was ad3f8046-3c95-f6d4-da13-3019d931f9e4 (received 4 identical messages from ad3f8046-3c95-f6d4-da13-3019d931f9e4 in the last 64159 ms)

Сообщения предназначены для различных хостов и серверов на хостах. То же самое было в бета-версиях и CR-версиях Wildfly, с другой стороны, этого не было в версии 8. Мы используем TCP в качестве транспорта, однако согласно другие ресурсы то же самое для UDP.

Есть ли у кого-то решение (конечно, кроме повышения уровня серьезности логов)? Спасибо.


cluster-computing wildfly hornetq
person TomS    schedule 26.08.2015    source источник
comment
Можете ли вы опубликовать свою конфигурацию jgroups?   -  person teacurran    schedule 26.08.2015
comment
Здесь и здесь они говорят: Эти сообщения безопасны.   -  person Tiny    schedule 06.12.2015

Ответы (1)


arrow_upward
7
arrow_downward

Наконец-то мы нашли проблему и решение. Wildfly 9 отправляет сообщения узлам кластера и HornetQ по одному и тому же каналу связи, что, похоже, приводит к коллизиям. Мы решили проблему созданием второго стека и разделением трафика между ними.

Для TCP рабочая конфигурация выглядит следующим образом:

        <stacks default="tcp">
            <stack name="tcp">
                <transport type="TCP" socket-binding="jgroups-tcp"/>
                <protocol type="TCPPING">
                     <property name="initial_hosts">
                         node1[7600],node1[7750],node2[7600],node2[7750]
                     </property>
                     <property name="port_range">
                         0
                     </property>
                </protocol>
                <protocol type="MERGE2"/>
                <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
                <protocol type="FD"/>
                <protocol type="VERIFY_SUSPECT"/>
                <protocol type="pbcast.NAKACK2"/>
                <protocol type="UNICAST3"/>
                <protocol type="pbcast.STABLE"/>
                <protocol type="pbcast.GMS"/>
                <protocol type="MFC"/>
                <protocol type="FRAG2"/>
                <protocol type="RSVP"/>
            </stack>
            <stack name="tcphq">
                <transport type="TCP" socket-binding="jgroups-tcp-hq"/>
                <protocol type="TCPPING">
                    <property name="initial_hosts">
                        node1[7660],node1[7810],node2[7660],node2[7810]
                    </property>
                    <property name="port_range">
                        0
                    </property>
                </protocol>
                <protocol type="MERGE2"/>
                <protocol type="FD_SOCK" socket-binding="jgroups-tcp-hq-fd"/>
                <protocol type="FD"/>
                <protocol type="VERIFY_SUSPECT"/>
                <protocol type="pbcast.NAKACK2"/>
                <protocol type="UNICAST3"/>
                <protocol type="pbcast.STABLE"/>
                <protocol type="pbcast.GMS"/>
                <protocol type="MFC"/>
                <protocol type="FRAG2"/>
                <protocol type="RSVP"/>
            </stack>
        </stacks>

Вам также необходимо настроить HornetQ (используйте правильный стек jgroups, в данном случае tcphq):

        <broadcast-groups>
            <broadcast-group name="bg-group1">
                 <jgroups-stack>tcphq</jgroups-stack>
                 <jgroups-channel>hq-cluster</jgroups-channel>
                 <broadcast-period>5000</broadcast-period>
                 <connector-ref>
                      http-connector
                 </connector-ref>
            </broadcast-group>
        </broadcast-groups>

        <discovery-groups>
            <discovery-group name="dg-group1">
                 <jgroups-stack>tcphq</jgroups-stack>
                 <jgroups-channel>hq-cluster</jgroups-channel>
                 <refresh-timeout>10000</refresh-timeout>
            </discovery-group>
        </discovery-groups>

... и, конечно, вам нужно добавить соответствующий socket-binding в socket-binding-group:

        <socket-binding name="jgroups-tcp-hq" port="7660"/>
        <socket-binding name="jgroups-tcp-hq-fd" port="7670"/>

К сожалению, у меня нет опыта работы с UDP, но думаю принцип будет тот же.

person TomS    schedule 02.09.2015
comment
Я заметил, что initial_hosts имеет одинаковые порты для обоих стеков, верно? Также порты, вероятно, должны быть правильно установлены в привязке к сокету? (Учитывая, что порт-оффсетов нет) - person Konstantin; 23.10.2015
comment
Вы правы, была ошибка. Я, вероятно, сделал это, копируя исходник туда. Большое спасибо! Возможно, он мог бы еще работать (и поэтому никто не заметил?), но теперь он определенно лучше. - person TomS; 23.10.2015
comment
Извините за некро-бамп, но мне также любопытны ваши начальные настройки хостов, особенно для стека tcp: node1[7600],node1[7750],node2[7600],node2[7750] - почему у вас есть узел, указанный дважды (например, узел 1 указан для двух портов, 7600 и 7750)? - person rbellamy; 30.04.2016
comment
@rbellamy Привет, это потому, что у нас есть две группы (то есть отдельные серверы) на каждом узле, и они различаются портом. - person TomS; 01.05.2016