JGroups comiendo la memoria

Question

Actualmente tengo un problema con mi configuración JGroups, causando miles de mensajes de quedarse atascado en la NAKACK.xmit_table. En realidad, todos ellos parecen terminar en el xmit_table, y otro volcado desde unas pocas horas más tarde indica que ellos nunca tienen la intención de dejar bien ...

Este es el protocolo pila de configuración

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

Los mensajes de inicio ...

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 que todo está bien hasta ahora.

Los registros establecidos, para advertir de nivel no indica que algo está mal con excepción de la occational

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

, que supongo no está relacionada ya que se ha visto anteriormente, sin el problema de memoria de memoria.

He estado cavando a través de dos volcados de memoria de una de las máquinas de encontrar rarezas, pero nada hasta ahora. A excepción de tal vez algunas estadísticas de los diferentes protocolos

UDP tiene

num_bytes_sent 53617832
num_bytes_received 679220174
num_messages_sent 99524
num_messages_received 99522

mientras NAKACK tiene ...

num_bytes_sent 0
num_bytes_received 0
num_messages_sent 0
num_messages_received 0

... y una enorme xmit_table.

Cada máquina tiene dos instancias JChannel, uno para ehcache y uno para TreeCache. Un medio mala configuración que ambos comparten la misma dirección de diagnositics mcast, pero esto no debería suponer un problema a menos que quiero enviar mensajes de diagnóstico correcto? Sin embargo lo hacen, por supuesto, tienen diferentes direcciones MCAST para los mensajes.

Por favor, pedir aclaraciones, no tengo mucha información, pero estoy un poco incierto sobre lo que es relevante en este punto.

Answer 1

Resulta que uno de los nodos del clúster no recibió ningún mensaje de multidifusión en absoluto. Esto hizo que todos los nodos que se aferran a sus propios xmit_tables, ya que no reciben ningún mensaje de estabilidad desde el nodo 'aislado', indicando que había recibido sus mensajes.

Un reinicio del asno, el cambio de la dirección de multidifusión resolvió el problema.