当使用近缓存时，一切都会正常工作，直到第二个客户端（可能是 visor）在缓存操作正在进行时尝试连接或断开集群。
在第二个客户端连接/断开连接后，原始客户端将始终错过近缓存，直到原始客户端重新启动。几乎就像集群通知客户他们的问题并保持集群作为事实的来源一样。
我们已经能够通过运行我们的测试并连接/断开与 visor 的连接来重现这一点。在断开连接期间，我们可以在原始客户端 IgniteTxManager$NodeFailureTimeoutObject 的日志中看到提到的超时。
以下是 org.apache.ignite.internal.processors 被抑制的日志片段。
[2017-10-09 14:26:52.148] 启动 - 9955 调试 [http-nio-8081-exec-8] --- CacheHelper：访问缓存 ng-security-service-ORG_SPEC_CACHE 的总时间* | 值 com.cache.model.PrefixCluster@78475a88: 0 毫秒 [2017-10-09 14:26:52.150] 启动 - 9955 调试 [disco-event-worker-#26%null%] --- GridDiscoveryManager: 守护程序节点离开拓扑：TcpDiscoveryNode [id=4cc6c321-d9cc-4149-a6ef-cba68877a269, addrs=[10.70.255.8, 127.0.0.1, 172.17.0.1], sockAddrs=[/172.17 .0.1:0, /127.0.0.1:0, / 10.70.255.8:0]，discPort=0，order=57，intOrder=31，lastExchangeTime=1507577126368，loc=false，ver=2.1.0#20170720-sha1:a6ca5c8a，isClient=true] [2017-10-09 14 :26:52.150] 启动 - 9955 调试 [http-nio-8081-exec-8] --- OrgSpecCacheImpl: OrgSpec 缓存统计信息: OrgSpec ObjId: IgniteCacheProxy [delegate=GridNearCacheAdapter [], opCtx=null, restartFut=null] HitCount: 120, sampleClsName=org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionFullMap，pendingUndeploy=false，undeployed=false，usage=0] [2017-10-09 14:26:52.285] 启动 - 9955 调试[grid-timeout-worker-#15%null%] --- GridResourceProcessor：注入资源 [target=org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject$2@3f183e4] [2017-10-09 14:26:52.317] boot - 9955 DEBUG [http-nio-8081-exec-8] --- CacheHelper: 访问缓存 ng-security-service-ORG_SPEC_CACHE 的总时间 * | 值 com.cache.model.PrefixCluster@6954be5d：167 毫秒 [2017-10-09 14:26:52.319] 启动 - 9955 调试 [http-nio-8081-exec-8] --- OrgSpecCacheImpl：OrgSpec 缓存统计：OrgSpec ObjId: IgniteCacheProxy [delegate=GridNearCacheAdapter [], opCtx=null, restartFut=null] HitCount: 126, MissCount: 53,
我的问题是，这是预期的行为吗？我们能否让近端缓存不被绕过，或者至少在坏客户端断开连接后使用近端缓存重新建立。