2010-03-04 106 views
5

我目前有一个问题,我的jgroups配置,导致成千上万的消息卡在NAKACK.xmit_table。其实所有的人都似乎在xmit_table结束了,从几个小时,另一转储后表示,他们从来没有打算要么离开......JGroups吃内存

这是协议栈配置

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 

启动消息...

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) 

...表示目前一切正常。

日志,设置为警告级别并不表明什么是除occational

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

,我猜是无关,因为前面已经没有了记忆内存问题看作是错误的。

我一直在从一台机器上挖掘两个内存转储来发现奇怪的东西,但没有到目前为止。除了从不同的协议也许有人统计

UDP具有

num_bytes_sent 53617832 
num_bytes_received 679220174 
num_messages_sent 99524 
num_messages_received 99522 

而NAKACK有...

num_bytes_sent 0 
num_bytes_received 0 
num_messages_sent 0 
num_messages_received 0 

...和巨大的xmit_table。

每台机器都有两个JChannel实例,一个用于ehcache,一个用于TreeCache。配置错误意味着它们都共享相同的诊断mcast地址,但是除非我想正确地发送诊断消息,否则这不会造成问题。但是,他们当然有不同的消息mcast地址。

请要求澄清,我有很多的信息,但我有点不确定在这一点上什么是相关的。

回答

4

事实证明,集群中的其中一个节点根本没有收到任何多播消息。这导致所有节点挂在自己的xmit_tables上,因为它们没有从“隔离”节点获得任何稳定性消息,表明它已收到它们的消息。

重启AS,改变组播地址解决了问题。