JGroups的吃内存

Question

我现在有一个问题，我的JGroups配置，导致数以千计的邮件被陷在NAKACK.xmit_table。其实所有的人都似乎在xmit_table结束了，从几个小时，另一转储后表示，他们从来没有打算离开要么...

这是协议栈配置

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的。配置错误意味着两者共享同一个Diagnositics公司MCAST地址，但除非我想正确发送诊断消息这不应该成为问题？然而，它们做当然具有用于消息的不同MCAST地址。

请去问清问题，我有很多的信息，但我有点不确定的是在这一点上相关的。

Answer 1

事实证明，在集群中的一个节点没有接收到有任何的多播消息。这导致所有节点挂到自己的xmit_tables，因为他们没有得到从“孤立”节点的任何消息的稳定性，说明它已收到他们的邮件。

AS的重新启动，改变组播地址解决的问题。