JGroups Speicher essen

Question

Im Moment habe ich ein Problem mit meinem jgroups Konfiguration, so dass Tausende von Nachrichten in der NAKACK.xmit_table stecken zu bleiben. Eigentlich alle von ihnen scheinen in dem xmit_table am Ende, und eine andere Deponie von einigen Stunden zeigt später, dass sie auch nie zu verlassen beabsichtigen ...

Dies ist der Protokollstapel Konfiguration

UDP(bind_addr=xxx.xxx.xxx.114;
bind_interface=bond0;
ip_mcast=true;ip_ttl=64;
loopback=false;
mcast_addr=228.1.2.80;mcast_port=45589;
mcast_recv_buf_size=80000;
mcast_send_buf_size=150000;
ucast_recv_buf_size=80000;
ucast_send_buf_size=150000):
PING(num_initial_members=3;timeout=2000):
MERGE2(max_interval=20000;min_interval=10000):
FD_SOCK:
FD(max_tries=5;shun=true;timeout=10000):
VERIFY_SUSPECT(timeout=1500):
pbcast.NAKACK(discard_delivered_msgs=true;gc_lag=50;retransmit_timeout=600,1200,2400,4800;use_mcast_xmit=true):
pbcast.STABLE(desired_avg_gossip=20000;max_bytes=400000;stability_delay=1000):UNICAST(timeout=600,1200,2400):
FRAG(frag_size=8192):pbcast.GMS(join_timeout=5000;print_local_addr=true;shun=true):
pbcast.STATE_TRANSFER

Start Nachricht ...

2010-03-01 23:40:05,358 INFO  [org.jboss.cache.TreeCache] viewAccepted(): [xxx.xxx.xxx.35:51723|17] [xxx.xxx.xxx.35:51723, xxx.xxx.xxx.36:53088, xxx.xxx.xxx.115:32781, xxx.xxx.xxx.114:32934]
2010-03-01 23:40:05,363 INFO  [org.jboss.cache.TreeCache] TreeCache local address is 10.35.191.114:32934
2010-03-01 23:40:05,393 INFO  [org.jboss.cache.TreeCache] received the state (size=32768 bytes)
2010-03-01 23:40:05,509 INFO  [org.jboss.cache.TreeCache] state was retrieved successfully (in 146 milliseconds)

... zeigt an, dass alles in Ordnung ist so weit.

Die Protokolle, auf warn-Ebene bedeutet nicht, dass etwas falsch ist mit Ausnahme der occational

2010-03-03 09:59:01,354 ERROR [org.jgroups.blocks.NotificationBus] exception=java.lang.IllegalArgumentException: java.lang.NullPointerException

, die ich bin zu raten, ist unabhängig, da es früher ohne den Speicher Speicherproblem gesehen wurde.

Ich habe wurde von einem der Maschinen durch zwei Speicherabbilder zu graben Seltsamkeiten zu finden, aber bisher nichts. Mit Ausnahme vielleicht einige Statistiken aus den verschiedenen Protokollen

UDP hat

num_bytes_sent 53617832
num_bytes_received 679220174
num_messages_sent 99524
num_messages_received 99522

während NAKACK hat ...

num_bytes_sent 0
num_bytes_received 0
num_messages_sent 0
num_messages_received 0

... und ein großer xmit_table.

Jede Maschine hat zwei JChannel Instanzen, eine für ehcache und eine für TreeCache. Eine falsche Konfiguration bedeutet, dass beide die gleiche diagnositics Adresse mcast teilen, aber das sollte kein Problem darstellen, wenn ich richtige Diagnose senden Nachrichten will? Allerdings tun sie natürlich unterschiedliche mcast Adressen für die Nachrichten.

Bitte fragen Sie nach Erklärungen, ich habe eine Menge Informationen, aber ich bin ein bisschen unsicher, was an dieser Stelle relevant ist.

Answer 1

Es stellt sich heraus, dass einer der Knoten im Cluster keine Multicast-Nachrichten überhaupt erhalten hat. Dies führte alle Knoten, um ihre eigenen xmit_tables zu hängen, da sie keine Stabilität Nachrichten aus dem ‚isoliert‘ Knoten erhalten hat, die besagt, dass es ihre Nachrichten erhalten hatte.

Ein Neustart von AS, die Multicast-Adresse zu ändern löste das Problem.