2010-03-04 16 views
5

Actualmente tengo un problema con la configuración de mi jgroups, lo que hace que miles de mensajes se bloqueen en 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 ...JGroups comiendo memoria

Ésta es la configuración pila de protocolos

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 

de inicio mensaje ...

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 el momento.

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 

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

He estado cavando a través de dos volcados de memoria de una de las máquinas para encontrar rarezas, pero nada hasta el momento. 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 de JChannel, una para ehcache y otra para TreeCache. Una mala configuración significa que ambos comparten la misma dirección de difusión de diagnósticos, pero esto no debería ser un problema a menos que quiera enviar mensajes de diagnóstico ¿no? Sin embargo, por supuesto tienen diferentes direcciones de difusión para los mensajes.

Solicito aclaraciones, tengo mucha información, pero estoy un poco inseguro sobre lo que es relevante en este momento.

Respuesta

4

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

Un reinicio de los AS, cambiando la dirección de multidifusión resolvió el problema.

Cuestiones relacionadas