JGroups mangiare memoria

Question

Al momento ho un problema con la mia configurazione JGroups, causando migliaia di messaggi sempre bloccato nel NAKACK.xmit_table. In realtà tutti loro sembrano finire nel xmit_table, e un'altra discarica da qualche ora dopo indica che non hanno mai intenzione di lasciare o ...

Questo è il protocollo stack di configurazione

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

Messaggio di avvio ...

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)

... indica che tutto va bene fino ad ora.

I log, insieme ad avvertire a livello non indica che qualcosa non va fatta eccezione per il occational

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

che sto cercando di indovinare non è correlata in quanto si è visto in precedenza, senza il problema di memoria di memoria.

Sono hanno scavato attraverso due dump di memoria da una delle macchine per trovare stranezze, ma nulla finora. Fatta eccezione forse per alcune statistiche provenienti dai diversi protocolli

UDP ha

num_bytes_sent 53617832
num_bytes_received 679220174
num_messages_sent 99524
num_messages_received 99522

mentre NAKACK ha ...

num_bytes_sent 0
num_bytes_received 0
num_messages_sent 0
num_messages_received 0

... e un xmit_table enorme.

Ogni macchina ha due istanze JChannel, uno per EHCache e uno per TreeCache. Un mezzo di errata configurazione che entrambi condividono lo stesso diagnositics mcast indirizzo, ma questo non dovrebbe costituire un problema a meno che voglio inviare messaggi di diagnostica giusto? Tuttavia essi, naturalmente, hanno diversi indirizzi MCAST per i messaggi.

Si prega di chiedere chiarimenti, ho un sacco di informazioni, ma sono un po 'incerto su ciò che è rilevante a questo punto.

Answer 1

Si scopre che uno dei nodi del cluster non ha ricevuto alcun messaggio multicast a tutti. Questo ha causato tutti i nodi da appendere alle proprie xmit_tables, dal momento che non hanno ottenuto alcun messaggio di stabilità dal nodo 'isolato', affermando di aver ricevuto i loro messaggi.

Un riavvio di asino, cambiare l'indirizzo multicast ha risolto il problema.