处于Invalidation模式的Infinispan集群 - 尽管某些节点具有该值,但get(key)仍返回NULL

时间:2015-01-08 12:23:16

标签: caching distributed infinispan invalidation

我有以下拓扑: Infinispan集群处于Invalidation模式,put在一个节点上执行,gets在其他节点上执行。 当集群只包含两个节点时,一切运行良好:当键/值插入到一个节点时,另一个节点在第一次被询问时,查询该节点并从那里获取值。如果更新/删除密钥,则发送失效消息。

当集群中有两个以上的节点时,问题就开始了:在将密钥插入到一个节点之后,当另一个节点被要求输入该密钥及其值时,有时会返回该值,有时会返回NULL。

从某些角度来看,这是有道理的,因为节点查询其邻居并且其中一些具有值而其他节点没有。无论哪个首先回复,都将定义响应是否为NULL或实际值。

虽然有意义,但这种行为使得这种操作模式毫无用处,这让我觉得我可能会遗漏一些东西。 这是我的配置:

<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:7.0 http://www.infinispan.org/schemas/infinispan-config-7.0.xsd"  xmlns="urn:infinispan:config:7.0">
    <jgroups>
        <stack-file name="tcp" path="jgroups-tcp.xml" />
    </jgroups>
   <cache-container name="SampleCacheManager" statistics="true" default-cache="invalidatedWithClusterCacheLoaderCache" shutdown-hook="DEFAULT">
     <transport stack="tcp" cluster="clustered" node-name="NodeA"/>
     <serialization marshaller="org.infinispan.marshall.core.VersionAwareMarshaller"            version="1.0">
     </serialization>
     <jmx domain="org.infinispan" />    
     <invalidation-cache name="invalidatedWithClusterCacheLoaderCache" mode="SYNC" remote-timeout="20000" >
        <persistence>
                <cluster-loader remote-timeout="20000" preload="false" ></cluster-loader>
        </persistence> 
     </invalidation-cache>
   </cache-container>
</infinispan>

的JGroups-tcp.xml:

<config xmlns="urn:org:jgroups"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.4.xsd">
    <TCP bind_port="7800" port_range="10"
         recv_buf_size="20000000"
         send_buf_size="640000"
         loopback="false"
         max_bundle_size="64k"
         bundler_type="sender-sends-with-timer"
         enable_diagnostics="true"
         thread_naming_pattern="cl"

         timer_type="new"
         timer.min_threads="4"
         timer.max_threads="10"
         timer.keep_alive_time="3000"
         timer.queue_max_size="1000"
         timer.wheel_size="200"
         timer.tick_time="50"

         thread_pool.enabled="true"
         thread_pool.min_threads="2"
         thread_pool.max_threads="8"
         thread_pool.keep_alive_time="5000"
         thread_pool.queue_enabled="true"
         thread_pool.queue_max_size="100000"
         thread_pool.rejection_policy="discard"

         oob_thread_pool.enabled="true"
         oob_thread_pool.min_threads="1"
         oob_thread_pool.max_threads="8"
         oob_thread_pool.keep_alive_time="5000"
         oob_thread_pool.queue_enabled="false"
         oob_thread_pool.queue_max_size="100"
         oob_thread_pool.rejection_policy="discard"/>

   <MPING bind_addr="${jgroups.bind_addr:127.0.0.1}" break_on_coord_rsp="true"
          mcast_addr="${jgroups.mping.mcast_addr:228.2.4.6}"
          mcast_port="${jgroups.mping.mcast_port:43366}"
          ip_ttl="${jgroups.udp.ip_ttl:2}"
          num_initial_members="2" timeout="2000"/>

    <MERGE3/>

    <FD_SOCK/>
    <FD_ALL interval="2000" timeout="5000" />
    <VERIFY_SUSPECT timeout="500"  />
    <BARRIER />
    <pbcast.NAKACK use_mcast_xmit="false"
                   retransmit_timeout="100,300,600,1200"
                   discard_delivered_msgs="true" />
    <UNICAST3 conn_expiry_timeout="0"/>

    <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
                   max_bytes="10m"/>
    <pbcast.GMS print_local_addr="true" join_timeout="5000"
                max_bundling_time="30"
                view_bundling="true"/>
    <MFC max_credits="2M"
         min_threshold="0.4"/>
    <FRAG2 frag_size="60000"  />
    <pbcast.STATE_TRANSFER  />
</config>

总结一下我的问题:它应该以这种方式工作还是在我的情况下配置错误?

1 个答案:

答案 0 :(得分:1)

失效缓存无法检索远程值。这里描述[1]。它只会在内存中本地检索值。

远程查找由您在持久性配置中配置的集群加载程序完成。这将询问群集中的所有其他节点的值。我调整了一个现有的Infinispan测试以获得超过2个缓存,并且您经历过远程查找中的错过。如果没有值的节点在具有该值的节点之前返回(它接受第一个响应),则缓存加载器似乎返回null。

我记录[2]以查看此内容。

[1] http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_invalidation_mode [2] https://issues.jboss.org/browse/ISPN-5134