2010-03-04 18 views
5

J'ai actuellement un problème avec ma configuration jgroups, provoquant le blocage de milliers de messages dans la table NAKACK.xmit_table. En fait, tous semblent se retrouver dans la xmit_table, et une autre décharge de quelques heures indique plus tard qu'ils ne l'intention de quitter soit ...JGroupes mangeant de la mémoire

Ceci est la configuration de la pile de protocole

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 

démarrage message ...

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) 

... indique que tout va bien jusqu'ici.

Les journaux, mis à mettre en garde niveau n'indique pas que quelque chose ne va pas, sauf pour la occational

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

que je devine est sans rapport, car il a été vu plus haut sans que la question de la mémoire de la mémoire.

J'ai creusé à travers deux dumps mémoire de l'une des machines pour trouver des bizarreries mais rien pour l'instant. Sauf peut-être quelques statistiques des différents protocoles

UDP a

num_bytes_sent 53617832 
num_bytes_received 679220174 
num_messages_sent 99524 
num_messages_received 99522 

tout NAKACK a ...

num_bytes_sent 0 
num_bytes_received 0 
num_messages_sent 0 
num_messages_received 0 

... et un énorme xmit_table.

Chaque machine possède deux instances JChannel, une pour ehcache et une pour TreeCache. Une mauvaise configuration signifie que les deux partagent la même adresse de diagnostic, mais cela ne devrait pas poser de problème, sauf si je veux envoyer des messages de diagnostic correctement. Cependant, ils ont bien sûr des adresses Mcast différentes pour les messages.

S'il vous plaît demander des éclaircissements, j'ai beaucoup d'informations, mais je suis un peu incertain sur ce qui est pertinent à ce stade.

Répondre

4

Il s'avère que l'un des noeuds du cluster n'a reçu aucun message de multidiffusion. Cela a provoqué que tous les nœuds se sont accrochés à leurs propres xmit_tables, car ils n'ont reçu aucun message de stabilité du nœud «isolé», indiquant qu'il avait reçu leurs messages.

Un redémarrage des AS, en changeant l'adresse de multidiffusion a résolu le problème.