[infinispan-dev] abstracting key locating, asymmetric clusters

[Christian Kulenkampff]

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 :).

>> Also it may be possible to remove the replication mode
>> and instead provide a special locator.
>
> We considered this, however there is a lot of additional overhead and we wouldn't be able to make use of certain JGroups tricks to optimise sending the same state to all servers in the cluster.

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