jgroup的成員無法加入？

Question

我使用通過jgroups分發的ehcache。我使用UDP multicat進行分發。

ehcache生活在一個web應用程序。有幾臺機器運行該webapp。出於某種原因，我得到了WARN NAKACK。似乎ehcache的幾個實例無法加入到jgroup中。

這是ehcache的配置（含JGroups的-配置）：

<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] 

任何想法我可以做這件事？ Thanx

Answer 1

現在，您的文章已有半年的歷史，無論如何，在這種情況下，您必須確保服務器位於同一物理網絡中，並且您用於udp通信的端口不會在它們之間的任何位置被阻止。