JBoss 4.2.2 Knoten beginnen zu clustern und dann verdächtigen sich gegenseitig

Question

Ich habe eine Website mit JBoss 4.2.2 auf einem bestehenden Red Hat Server ausgeführt. Ich richte einen zweiten Server ein, um ein gruppiertes Paar zu haben (das dann Lasten-ausgeglichen wird). Ich kann sie jedoch nicht erfolgreich clustern.

Der bestehende Server startet JBoss mit:

run.sh -c default -b 0.0.0.0 

(Ich weiß, dass die Konfiguration ‚default‘ nicht Clustering aus der Box unterstützt - ich bin eine modifizierte Version davon verwendet, die Clustering-Unterstützung umfasst .) Wenn ich die zweite JBoss-Instanz mit demselben Befehl starte, bildet sie ihren eigenen Cluster, ohne den ersten zu bemerken. Beide verwenden denselben Partitionsnamen und dieselbe Multicast-Adresse und denselben Port.

Ich habe versucht, die McastReceiverTest und McastSenderTest-Programme zu überprüfen, dass die Maschinen über Multicast kommunizieren können; sie könnten.

Ich bemerkte dann die Informationen an http://docs.jboss.org/jbossas/docs/Clustering_Guide/beta422/html/ch07s07s07.html und sagte, dass JGroups nicht zu alle Schnittstellen binden kann, und bindet stattdessen auf die Standard-Schnittstelle; also war es vermutlich an 127.0.0.1 gebunden, und dadurch wurden die Nachrichten nicht durchgestellt. Anstatt also stelle ich die Instanzen JGroups zu sagen, die internen IP-Adressen zu verwenden:

run.sh -c default -b 0.0.0.0 -Djgroups.bind_addr=10.51.1.131 
run.sh -c default -b 0.0.0.0 -Djgroups.bind_addr=10.51.1.141 

(.131 ist der vorhandene Server, 0,141 ist der neue Server).

Die Knoten bemerken sich jetzt und bilden einen Cluster - zunächst. Doch bei dem Versuch, dies den .ear, der Server-Log sagt zu implementieren:

2010-08-07 22:26:39,321 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:46294 (own address=10.51.1.141:47629) 
2010-08-07 22:26:45,412 WARN [org.jgroups.protocols.FD] I was suspected by 10.51.1.131:48733; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK 
2010-08-07 22:26:49,324 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:46294 (own address=10.51.1.141:47629) 
2010-08-07 22:26:49,324 DEBUG [org.jgroups.protocols.FD] heartbeat missing from 10.51.1.131:46294 (number=0) 
2010-08-07 22:26:49,529 DEBUG [org.jgroups.protocols.MERGE2] initial_mbrs=[[own_addr=10.51.1.141:60365, coord_addr=10.51.1.141:60365, is_server=true]] 
2010-08-07 22:26:52,092 WARN [org.jboss.cache.TreeCache] replication failure with method_call optimisticPrepare; id:18; Args: (arg[0] = GlobalTransaction:<10.51.1.131:46294>:5421085 ...) exception org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/Yudu_ear,Yudu-ejb_jar,Yudu-ejbPU/com/yudu/ejb/entity, caller=GlobalTransaction:<10.51.1.131:46294>:5421085, lock=read owners=[GlobalTransaction:<10.51.1.131:46294>:5421081] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=0) 

... und die .ear nicht einzusetzen.

Wenn ich CacheMode in ejb3-entity-cache-service.xml von REPL_SYNC zu LOCAL ändere, wird die .ear-Datei korrekt implementiert, obwohl die Replikation des Entitäts-Caches dann natürlich nicht erfolgt. Das Protokoll zeigt jedoch immer noch interessante Anzeichen für das gleiche Problem.

Es sieht aus wie:

• zuerst der neue Knoten die bestehende findet und bildet einen Cluster
• dann die FD Prüfungen fehlschlägt, und nach einer festgelegten Anzahl von Ausfällen der neue Knoten trennt sich von dem Cluster aus und bildet einen eigenen Cluster von
• dann findet es wieder, Cluster neu und dieses Mal die FD-Prüfungen funktionieren.

Relevante Bits der Protokolldatei:

2010-08-07 23:47:07,423 INFO [org.jgroups.protocols.UDP] socket information: local_addr=10.51.1.141:35666, mcast_addr=228.1.2.3:45566, bind_addr=/10.51.1.141, ttl=2 sock: bound to 10.51.1.141:35666, receive buffer size=131071, send buffer size=131071 mcast_recv_sock: bound to 0.0.0.0:45566, send buffer size=131071, receive buffer size=131071 mcast_send_sock: bound to 10.51.1.141:59196, send buffer size=131071, receive buffer size=131071 
2010-08-07 23:47:07,431 DEBUG [org.jgroups.protocols.UDP] created unicast receiver thread 
2010-08-07 23:47:09,445 DEBUG [org.jgroups.protocols.pbcast.GMS] initial_mbrs are [[own_addr=10.51.1.131:48888, coord_addr=10.51.1.131:48888, is_server=true]] 
2010-08-07 23:47:09,446 DEBUG [org.jgroups.protocols.pbcast.GMS] election results: {10.51.1.131:48888=1} 
2010-08-07 23:47:09,446 DEBUG [org.jgroups.protocols.pbcast.GMS] sending handleJoin(10.51.1.141:35666) to 10.51.1.131:48888 
2010-08-07 23:47:09,751 DEBUG [org.jgroups.protocols.pbcast.GMS] [10.51.1.141:35666]: JoinRsp=[10.51.1.131:48888|61] [10.51.1.131:48888, 10.51.1.141:35666] [size=2] 
2010-08-07 23:47:09,752 DEBUG [org.jgroups.protocols.pbcast.GMS] new_view=[10.51.1.131:48888|61] [10.51.1.131:48888, 10.51.1.141:35666] 
... 
2010-08-07 23:47:10,047 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Number of cluster members: 2 
2010-08-07 23:47:10,047 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Other members: 1 
... 
2010-08-07 23:47:20,034 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48888 (own address=10.51.1.141:35666) 
2010-08-07 23:47:30,037 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48888 (own address=10.51.1.141:35666) 
2010-08-07 23:47:30,038 DEBUG [org.jgroups.protocols.FD] heartbeat missing from 10.51.1.131:48888 (number=0) 
2010-08-07 23:47:40,040 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48888 (own address=10.51.1.141:35666) 
2010-08-07 23:47:40,040 DEBUG [org.jgroups.protocols.FD] heartbeat missing from 10.51.1.131:48888 (number=1) 
... 
2010-08-07 23:48:19,758 WARN [org.jgroups.protocols.FD] I was suspected by 10.51.1.131:48888; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK 
2010-08-07 23:48:20,054 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48888 (own address=10.51.1.141:35666) 
2010-08-07 23:48:20,055 DEBUG [org.jgroups.protocols.FD] [10.51.1.141:35666]: received no heartbeat ack from 10.51.1.131:48888 for 6 times (60000 milliseconds), suspecting it 
2010-08-07 23:48:20,058 DEBUG [org.jgroups.protocols.FD] broadcasting SUSPECT message [suspected_mbrs=[10.51.1.131:48888]] to group 
... 
2010-08-07 23:48:21,691 DEBUG [org.jgroups.protocols.pbcast.NAKACK] removing 10.51.1.131:48888 from received_msgs (not member anymore) 
2010-08-07 23:48:21,691 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] I am (127.0.0.1:1099) received membershipChanged event: 
2010-08-07 23:48:21,691 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] Dead members: 0 ([]) 
2010-08-07 23:48:21,691 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] New Members : 0 ([]) 
2010-08-07 23:48:21,691 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] All Members : 1 ([127.0.0.1:1099]) 
... 
2010-08-07 23:49:59,793 WARN [org.jgroups.protocols.FD] I was suspected by 10.51.1.131:48888; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK 
2010-08-07 23:50:09,796 WARN [org.jgroups.protocols.FD] I was suspected by 10.51.1.131:48888; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK 
2010-08-07 23:50:19,144 DEBUG [org.jgroups.protocols.FD] Recevied Ack. is invalid (was from: 10.51.1.131:48888), 
2010-08-07 23:50:19,144 DEBUG [org.jgroups.protocols.FD] Recevied Ack. is invalid (was from: 10.51.1.131:48888), 
... 
2010-08-07 23:50:21,791 DEBUG [org.jgroups.protocols.pbcast.GMS] new=[10.51.1.131:48902], suspected=[], leaving=[], new view: [10.51.1.141:35666|63] [10.51.1.141:35666, 10.51.1.131:48902] 
... 
2010-08-07 23:50:21,792 DEBUG [org.jgroups.protocols.pbcast.GMS] view=[10.51.1.141:35666|63] [10.51.1.141:35666, 10.51.1.131:48902] 
2010-08-07 23:50:21,792 DEBUG [org.jgroups.protocols.pbcast.GMS] [local_addr=10.51.1.141:35666] view is [10.51.1.141:35666|63] [10.51.1.141:35666, 10.51.1.131:48902] 
2010-08-07 23:50:21,822 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.DefaultPartition] New cluster view for partition DefaultPartition (id: 63, delta: 1) : [127.0.0.1:1099, 127.0.0.1:1099] 
2010-08-07 23:50:21,822 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] membership changed from 1 to 2 
... 
2010-08-07 23:50:31,825 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48902 (own address=10.51.1.141:35666) 
2010-08-07 23:50:31,832 DEBUG [org.jgroups.protocols.FD] received ack from 10.51.1.131:48902 

Aber ich ratlos bin zu verstehen, warum die FD Kontrollen in der ersten Runde scheitern; und obwohl es schließlich mit dem anderen Knoten zu clustern scheint, scheint der anfängliche Fehler genug zu sein, um die Bereitstellung durcheinander zu bringen, wenn sie versucht, den Entitätszustand zu teilen und dadurch zu verhindern, dass sie tatsächlich auf nützliche Weise funktioniert.

Wenn jemand Licht darauf werfen kann, werde ich sehr dankbar sein!

Answer 1

Ich denke, bevor Sie zu JBoss 4.2 weitergehen.3 (was wahrscheinlich ein guter Ort zu sein, schließlich ist) oder eine neue Konfiguration Gebäude (I mit @skaffman einig über Beschneidung ist einfacher als das Hinzufügen), sollten Sie folgendes versuchen:

Auf 10.51.1.131:

run.sh -c default -b 10.51.1.131 -Djgroups.bind_addr=10.51.1.131

auf 10.51.1.141:

run.sh -c default -b 10.51.1.141 -Djgroups.bind_addr=10.51.1.141

nach all der Dokumentation ich auf diese nicht finden, die -b Parameter ist der serv Die Instanz-Bind-Adresse und die Tatsache, dass sie unterschiedlich sind, könnte zu einer signifikanten Schizophrenie für JGroups führen. Ich hatte eine Cluster-Umgebung mit vier Servern, die über drei Jahre erfolgreich funktionierte, und das war Teil der empfohlenen Konfiguration von RH/JBoss (wir hatten einen Supportvertrag und erhielten Hilfe von Bela Ban).