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

Question

После того, как мы обновились от 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 в качестве транспорта, однако согласно other resources то же самое для UDP.

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

Answer 1

Мы, наконец, нашли проблему и решение проблемы. 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, но я думаю, что принцип будет таким же.