Re: [infinispan-dev] abstracting key locating, asymmetric clusters

Thank you for the reply! I currently try to implement a game server system for my diploma thesis. I would like to use Infinispan for sharing dynamic game objects between the nodes. Shared parameters for the locator/ConsistentHash would simplify things for some cases (e.g. spatial hash and node assignment "by hand"). The implementation of virtual nodes may profit from a common interface for providing dynamic parameters to all nodes too (one could add virtual nodes "by hand"/with special algorithms to the hash wheel). When these shared parameters (like a key-to-address registry for providing keys that stay at a special node [usage triggered via group or special key class...] or a list of nodes that should participate in providing a cache) are consistently shared with all nodes there should not be a loss of any deterministic aspects. Changing a parameter would just trigger something like a node join event. Maybe sharing data in a broader context (per cache not per locator) makes more sense (e.g. cache configurations could be send to joining nodes). But I want to emphasize these are only some thoughts that came up while thinking about my game server system. Actually I am not sure if a cache like Infinispan is really a good approach for sharing write-intensive virtual world data. However using delta aware data structures I got some promising results. I will implement something with Infinispan anyway. Of course I will share the results :). Yeah, I also thought about this. It would require to be able to return some kind of multicast-adresses with the locator/ConsistentHash and just by comparing DistributionInterceptor to ReplicationInterceptor there are indeed many things that one would have to make skippable... For my use case I am really looking forward to the new applyDelta method. Since the putMap Command does not support deltas (why, performance?), maybe an applyDeltas method would even add some more performance/convenience. Cheers Christian