Wildfly 9: JGRP000012: messaggio scartato da cluster clusterq diverso (il nostro cluster è ee)

Question

Dopo l'aggiornamento da Wildfly 8.2.1.Final a Wildfly 9.0.1.Final, abbiamo iniziato a ricevere molti avvisi come seguente:

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) 

I messaggi sono per host e server diversi presso gli host. La stessa cosa era nelle versioni beta e beta di Wildfly, d'altra parte, non era nella versione 8. Usiamo TCP come trasporto, tuttavia secondo lo other resources lo stesso vale per UDP.

Qualcuno ha una soluzione (ovviamente oltre ad aumentare il livello di gravità dei registri)? Grazie.

Answer 1

Abbiamo finalmente trovato il problema e la soluzione. Wildfly 9 invia i messaggi per i nodi del cluster e per HornetQ all'interno dello stesso canale di comunicazione, che sembra effettuare collisioni. Abbiamo risolto il problema creando il secondo stack e dividendo il traffico tra di loro.

Per TCP, la configurazione di lavoro è la seguente:

 <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> 

È inoltre necessario configurare HornetQ (utilizzare il corretto JGroups-stack, tcphq in questo caso):

 <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> 

... e naturalmente è necessario aggiungere il numero socket-binding in socket-binding-group:

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

Purtroppo, non ho esperienza con UDP, ma penso che il principio sarà lo stesso.