Wildfly 9: JGRP000012: verworfene Nachricht von verschiedenen Cluster hq-cluster (unser Cluster ist ee)

Question

Nachdem wir von Wildfly 8.2.1.Final auf Wildfly 9.0.1.Final aktualisiert haben, haben wir angefangen, viele Warnungen wie die zu bekommen folgende:

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) 

Die Nachrichten sind für verschiedene Hosts und Server auf Hosts. Das gleiche war in Betas und CR-Versionen von Wildfly, auf der anderen Seite war es nicht in Version 8. Wir verwenden TCP als Transport, aber nach other resources ist das gleiche für UDP.

Hat jemand eine Lösung (natürlich anders als den Schweregrad von Protokollen zu erhöhen)? Vielen Dank.

Answer 1

Wir haben endlich das Problem und die Lösung gefunden. Wildfly 9 sendet die Nachrichten für die Cluster-Knoten und für HornetQ innerhalb des gleichen Kommunikationskanals, der Kollisionen zu verursachen scheint. Wir haben das Problem gelöst, indem wir den zweiten Stack erstellt und den Traffic aufgeteilt haben.

Für TCP, die Arbeitskonfiguration ist wie folgt:

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

Sie müssen auch HornetQ konfigurieren (verwenden Sie die richtige jgroups-Stack, tcphq in diesem Fall):

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

... und natürlich müssen Sie das entsprechende socket-binding in socket-binding-group:

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

hinzufügen

Leider habe ich keine Erfahrung mit UDP, aber ich denke, das Prinzip wird das gleiche sein.