Hey Slave, Just some more details, it looks like the GridNearCacheEntry.primaryNode is the suspect. That is what updates the topVer. If you create 2 nodes, then X clients. Using one of the clients to create a cache with a near cache config it seems to work as expected. However, if you create a cache on the node instance then populate that cache, but try to get from a near cache created through the client the change of a topology will cause the setting of the topVer to none, then the primaryNode never get to reset the topVer causing the GridNearCacheEntry.valid to return false.
Hope that makes some sense, but attached is a test i used. It's crude but should at least show what i am trying to convey. The good test to what is expected with a miss count being the initial call and the one after the invalidation of the topology change, the bad has almost all read marked as misses which causes the hard hit to the cluster. GridCacheNearClientMissTest.java <http://apache-ignite-users.70518.x6.nabble.com/file/t1401/GridCacheNearClientMissTest.java> Thanks Tim(ay) -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
