Re: [infinispan-dev] Experiment: Affinity Tagging

Adrian, I don't think that will work. The Hash doesn't know the number of segments so it can't tell where a particular key will land - even assuming knowledge about how the ConsistentHash will map hash codes to segments. However, I'm all for replacing the current Hash interface with another interface that maps keys directly to segments. Cheers Dan On Tue, Jan 20, 2015 at 4:08 AM, Adrian Nistor <anistor(a)redhat.com&gt; wrote: You would need to create your own ConsistentHashFactory, possibly extending ReplicatedConsistentHashFactory. You can then plug the factory in with configurationBuilder.clustering().hash().consistentHashFactory(yourFactory) However, this isn't a really good idea, because then you need a different implementation for distributed mode, and then another implementation for topology-aware clusters (with rack/machine/site ids). And your users would also need to select the proper factory for each cache. You can plug in your own KeyGenerator to generate keys, and maybe replace the Random with a static/thread-local counter. This is actually a drawback of the KeyAffinityService more than Grouping. With grouping, you can actually follow the KeyAffinityService strategy and generate random strings until you get one in the proper segment, and then tag all your keys with that exact string. Sounds very interesting, but I think there may be a problem with your strategy: Infinispan doesn't guarantee you that one of the nodes executing the CommitCommand is the primary owner at the time the CommitCommand is executed. You could have something like this: Cluster [A, B, C, D], key k, owners(k) = [A, B] (A is primary) C initiates a tx that executes put(k, v) Tx prepare succeeds on A and B A crashes, but the other nodes don't detect the crash yet Tx commit succeeds on B, who still thinks is a backup owner B detects the crash, installs a new cluster view consistent hash with owners(k) = [B]