jgroup 会员无法加入?
我使用通过 jgroups 分发的 ehcache。我使用 UDP multicat 进行分发。
ehcache 存在于 web 应用程序中。有几台机器运行该 Web 应用程序。由于某种原因,我收到警告 NAKACK。看来 ehcache 的多个实例无法加入 jgroup。
这是 ehcache 配置(包含 jgroups-config):
<cacheManagerPeerProviderFactory class="net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"
properties="connect=UDP(mcast_addr=${ehcache.multicast.address};mcast_port=45566;ip_ttl=32;
mcast_send_buf_size=150000;mcast_recv_buf_size=80000):
PING(timeout=2000;num_initial_members=6):
MERGE2(min_interval=5000;max_interval=10000):
FD_SOCK:VERIFY_SUSPECT(timeout=1500):
pbcast.NAKACK(gc_lag=10;retransmit_timeout=3000):
UNICAST(timeout=5000):
pbcast.STABLE(desired_avg_gossip=20000):
FRAG:
pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;
shun=false;print_local_addr=true)"
propertySeparator="::" />
这是堆栈跟踪:
TRACE - UDP - received [dst: <null>, src: testforce-54850 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=EH_CACHE, arg=own_addr=testforce-54850, view id=null, is_server=false, is_coord=false, logical_name=testforce-54850, physical_addrs=fe80:0:0:0:216:3eff:fea6:7808%2:35176], UDP: [channel_name=EH_CACHE]
TRACE - PING - received GET_MBRS_REQ from testforce-54850, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=hitchhiker-12009, view id=[hitchhiker-12009|0], is_server=true, is_coord=true, logical_name=hitchhiker-12009]
TRACE - UDP - sending msg to testforce-54850, src=hitchhiker-12009, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=hitchhiker-12009, view id=[hitchhiker-12009|0], is_server=true, is_coord=true, logical_name=hitchhiker-12009], UDP: [channel_name=EH_CACHE]
TRACE - UDP - received [dst: <null>, src: testforce-54850 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=EH_CACHE, arg=own_addr=testforce-54850, view id=null, is_server=false, is_coord=false, logical_name=testforce-54850, physical_addrs=fe80:0:0:0:216:3eff:fea6:7808%2:35176], UDP: [channel_name=EH_CACHE]
TRACE - PING - received GET_MBRS_REQ from testforce-54850, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=hitchhiker-12009, view id=[hitchhiker-12009|0], is_server=true, is_coord=true, logical_name=hitchhiker-12009]
TRACE - UDP - sending msg to testforce-54850, src=hitchhiker-12009, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=hitchhiker-12009, view id=[hitchhiker-12009|0], is_server=true, is_coord=true, logical_name=hitchhiker-12009], UDP: [channel_name=EH_CACHE]
TRACE - UDP - received [dst: <null>, src: testforce-54850 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[GET_DIGEST_REQ]: mbr=null, NAKACK: [MSG, seqno=30], UDP: [channel_name=EH_CACHE]
TRACE - NAKACK - hitchhiker-12009: received testforce-54850#30
WARN - NAKACK - hitchhiker-12009: dropped message from testforce-54850 (not in xmit_table), keys are [hitchhiker-12009], view=[hitchhiker-12009|0] [hitchhiker-12009]
TRACE - STABLE - hitchhiker-12009: setting latest_local_digest from NAKACK: [hitchhiker-12009#3]
TRACE - STABLE - hitchhiker-12009: sending stable msg [hitchhiker-12009#3]
TRACE - NAKACK - sending hitchhiker-12009#4
TRACE - UDP - sending msg to null, src=hitchhiker-12009, headers are STABLE: [STABLE_GOSSIP]: digest is hitchhiker-12009: [0 : 3 (3)], NAKACK: [MSG, seqno=4], UDP: [channel_name=EH_CACHE]
TRACE - UDP - looping back message [dst: <null>, src: hitchhiker-12009 (3 headers), size=0 bytes, flags=OOB]
TRACE - UDP - received [dst: <null>, src: hitchhiker-12009 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is hitchhiker-12009: [0 : 3 (3)], NAKACK: [MSG, seqno=4], UDP: [channel_name=EH_CACHE]
TRACE - NAKACK - hitchhiker-12009: received hitchhiker-12009#4
TRACE - STABLE - hitchhiker-12009: handling digest from hitchhiker-12009 (0 votes):
mine: [hitchhiker-12009#2]
other: [hitchhiker-12009#3]
result: [hitchhiker-12009#2]
我能对此做些什么吗? 谢谢
I use a ehcache that distributes via jgroups. I use UDP multicat for the distribution.
The ehcache lives within a webapp. There are several machines that run that webapp. For some reason I get a WARN NAKACK. Seems that the several instances of the ehcache can't join to a jgroup.
This is the ehcache config (containing the jgroups-config):
<cacheManagerPeerProviderFactory class="net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"
properties="connect=UDP(mcast_addr=${ehcache.multicast.address};mcast_port=45566;ip_ttl=32;
mcast_send_buf_size=150000;mcast_recv_buf_size=80000):
PING(timeout=2000;num_initial_members=6):
MERGE2(min_interval=5000;max_interval=10000):
FD_SOCK:VERIFY_SUSPECT(timeout=1500):
pbcast.NAKACK(gc_lag=10;retransmit_timeout=3000):
UNICAST(timeout=5000):
pbcast.STABLE(desired_avg_gossip=20000):
FRAG:
pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;
shun=false;print_local_addr=true)"
propertySeparator="::" />
This is the stack trace:
TRACE - UDP - received [dst: <null>, src: testforce-54850 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=EH_CACHE, arg=own_addr=testforce-54850, view id=null, is_server=false, is_coord=false, logical_name=testforce-54850, physical_addrs=fe80:0:0:0:216:3eff:fea6:7808%2:35176], UDP: [channel_name=EH_CACHE]
TRACE - PING - received GET_MBRS_REQ from testforce-54850, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=hitchhiker-12009, view id=[hitchhiker-12009|0], is_server=true, is_coord=true, logical_name=hitchhiker-12009]
TRACE - UDP - sending msg to testforce-54850, src=hitchhiker-12009, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=hitchhiker-12009, view id=[hitchhiker-12009|0], is_server=true, is_coord=true, logical_name=hitchhiker-12009], UDP: [channel_name=EH_CACHE]
TRACE - UDP - received [dst: <null>, src: testforce-54850 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=EH_CACHE, arg=own_addr=testforce-54850, view id=null, is_server=false, is_coord=false, logical_name=testforce-54850, physical_addrs=fe80:0:0:0:216:3eff:fea6:7808%2:35176], UDP: [channel_name=EH_CACHE]
TRACE - PING - received GET_MBRS_REQ from testforce-54850, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=hitchhiker-12009, view id=[hitchhiker-12009|0], is_server=true, is_coord=true, logical_name=hitchhiker-12009]
TRACE - UDP - sending msg to testforce-54850, src=hitchhiker-12009, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=hitchhiker-12009, view id=[hitchhiker-12009|0], is_server=true, is_coord=true, logical_name=hitchhiker-12009], UDP: [channel_name=EH_CACHE]
TRACE - UDP - received [dst: <null>, src: testforce-54850 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[GET_DIGEST_REQ]: mbr=null, NAKACK: [MSG, seqno=30], UDP: [channel_name=EH_CACHE]
TRACE - NAKACK - hitchhiker-12009: received testforce-54850#30
WARN - NAKACK - hitchhiker-12009: dropped message from testforce-54850 (not in xmit_table), keys are [hitchhiker-12009], view=[hitchhiker-12009|0] [hitchhiker-12009]
TRACE - STABLE - hitchhiker-12009: setting latest_local_digest from NAKACK: [hitchhiker-12009#3]
TRACE - STABLE - hitchhiker-12009: sending stable msg [hitchhiker-12009#3]
TRACE - NAKACK - sending hitchhiker-12009#4
TRACE - UDP - sending msg to null, src=hitchhiker-12009, headers are STABLE: [STABLE_GOSSIP]: digest is hitchhiker-12009: [0 : 3 (3)], NAKACK: [MSG, seqno=4], UDP: [channel_name=EH_CACHE]
TRACE - UDP - looping back message [dst: <null>, src: hitchhiker-12009 (3 headers), size=0 bytes, flags=OOB]
TRACE - UDP - received [dst: <null>, src: hitchhiker-12009 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is hitchhiker-12009: [0 : 3 (3)], NAKACK: [MSG, seqno=4], UDP: [channel_name=EH_CACHE]
TRACE - NAKACK - hitchhiker-12009: received hitchhiker-12009#4
TRACE - STABLE - hitchhiker-12009: handling digest from hitchhiker-12009 (0 votes):
mine: [hitchhiker-12009#2]
other: [hitchhiker-12009#3]
result: [hitchhiker-12009#2]
Any ideas what I can do about this?
Thanx
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您的帖子现在已经有半年了,无论如何,在这种情况下,您必须确保服务器位于同一物理网络中,并且您用于 udp 通信的端口在它们之间的任何地方都没有被阻止。
Your post is half year old now, anyway, in such a case you have to make sure that the servers are in the same physical network and the port that you use for udp communication is not blocked anywhere between them.