Hi Val, Thanks for inputs. This was very helpful. I now understand the significance of AffinityFunction and affinityKey. All makes sense in case of partitioned caches but i am still not clear about replicated caches. I checked implementations of AffinityFunction interface and there are 2 - RendezvousAffinityFunction and FairAffinityFunction. 1) Which one is default? 2) Both implementations implement "public int partition(Object key) " method where they use hash of key and mod it with number of partitions. This suggests that (in replicated cache while topology remains unchanged) for all get requests for a key on any client node, request will be served by same server node all the time. is that right or did i misunderstood it?
if above point 2 is correct then, Do you think there will be any gain if in case of replicated caches we use round robin or weight based or current server load / performance based strategy to decide which server node to send a request for a cache operation? or will it be an overkill because in case of cache operations (other than get) which changes something in cache will anyway will propagate to other server nodes. and it may also be an overkill in case if near cache is utilized by clients. Regards, Vinay Sharma -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Data-grid-Load-balancing-tp2819p2934.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
