•  24-09-2019
  •  | 
  •  

Pergunta

Eu atualmente tenho um problema com meu jgroups de configuração, fazendo com que milhares de mensagens de ficar preso no NAKACK.xmit_table.Na verdade, todos eles parecem acabar no xmit_table, e um outro despejo de algumas horas mais tarde, indica que eles nunca pretende deixar...

Esta é a pilha de protocolo de configuração

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

Mensagem de inicialização...

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 está tudo bem até agora.

Os logs, conjunto para avisá-nível não indica que algo está errado, exceto para o occational 

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

que eu estou supondo que não está relacionado, pois foi visto anteriormente, sem a memória do problema de memória.

Eu tenho de ter sido a cavar através de dois despejos de memória de uma das máquinas para encontrar raridades, mas até agora nada.Exceto talvez algumas estatísticas a partir de diferentes protocolos de

O UDP tem 

num_bytes_sent 53617832
num_bytes_received 679220174
num_messages_sent 99524
num_messages_received 99522

enquanto NAKACK tem...

num_bytes_sent 0
num_bytes_received 0
num_messages_sent 0
num_messages_received 0

...e um enorme xmit_table.

Cada máquina tem dois JChannel instâncias, uma para ehcache e um para TreeCache.Uma configuração incorreta significa que ambos compartilham o mesmo diagnositics mcast endereço, mas isso não deve representar um problema a menos que eu queira enviar mensagens de diagnóstico certo?No entanto, eles obviamente têm diferentes mcast endereços para mensagens.

Por favor, pedir esclarecimentos, eu tenho muitas informações, mas eu sou um pouco incerto sobre o que é relevante neste ponto.

Foi útil?

Solução

Acontece que um dos nós do cluster não receber quaisquer mensagens de difusão seletiva em tudo.Isso fez com que todos os nós para pendurar em suas próprias xmit_tables, uma vez que eles não obter alguma estabilidade mensagens do 'isolado' nó, afirmando que tinha recebido suas mensagens.

Uma reinicialização do Cu, alterar o endereço de difusão seletiva resolvido o problema.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top