2010-03-04 9 views
5

Obecnie mam problem z moją konfiguracją jgroups, powodując utknięcie tysięcy wiadomości w NAKACK.xmit_table. Właściwie wszystkie z nich wydają się skończyć w xmit_table, a inny zrzut z kilka godzin później wskazuje, że nie zamierzają opuścić albo ...JGroups jedzenie pamięci

Jest to konfiguracja stosu protokołów

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 

Startup wiadomość ...

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) 

... oznacza, że ​​do tej pory wszystko jest w porządku.

Dzienniki, zestaw ostrzec poziomu nie oznacza, że ​​coś jest nie tak z wyjątkiem occational

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

który Zgaduję ma związku, ponieważ zaobserwowano wcześniej bez problemu Pamięć.

Przeszukałem dwie zrzuty pamięci z jednej z maszyn, aby znaleźć dziwne rzeczy, ale nic tak daleko. Z wyjątkiem być może niektóre statystyki z różnych protokołów

UDP ma

num_bytes_sent 53617832 
num_bytes_received 679220174 
num_messages_sent 99524 
num_messages_received 99522 

podczas NAKACK ma ...

num_bytes_sent 0 
num_bytes_received 0 
num_messages_sent 0 
num_messages_received 0 

... i ogromną xmit_table.

Każda maszyna ma dwie instancje JChannel, jedną dla ehcache i jedną dla TreeCache. Błędna konfiguracja oznacza, że ​​oba z nich mają ten sam adres mikrosekundy, ale nie powinno to stanowić problemu, chyba że chcę wysyłać wiadomości diagnostyczne w odpowiedni sposób? Mają jednak oczywiście różne adresy mcastów dla wiadomości.

Proszę o wyjaśnienia, mam wiele informacji, ale jestem trochę niepewna, co jest istotne w tym momencie.

Odpowiedz

4

Okazuje się, że jeden z węzłów w klastrze w ogóle nie odebrał żadnych wiadomości multiemisji. Spowodowało to, że wszystkie węzły pozostały na swoich własnych tabelach xmit_tables, ponieważ nie otrzymały żadnych komunikatów stabilności z "izolowanego" węzła, informując, że otrzymały swoje wiadomości.

Restart AS, zmiana adresu multicastowego rozwiązała problem.

Powiązane problemy