1 of 1 people found this helpful
The number of redundant copies is configured in Infinispan through numOwners config option. (That's if you use a distributed cache, for replicated caches the numOwnes is set to cluster size).
A cache write *always fails* if less than numOwners nodes are updated. There's no way to negotiate this failure condition ATM, e.g specify the update to be successful if numOwners-2 nodes ack.
Does this answer your question?
Yes, that's perfect. Thank-you very much, I had failed to appreciate numOwners could be used with a replicated cache.
Sorry to come back to this, but I am after a little clarification:
A cache write *always fails* if less than numOwners nodes are updated.
So when using a (synchronous) distributed cache, if ( numOwners > clusterSize) then cache writes should fail?
I ask because this is not the behaviour I am seeing - with a cluster size between 1 and 4 I am able to successfully PUT when numOwners is set to 5.
(See: captPatches/PutFailTest · GitHub for simple test:
git clone email@example.com:captPatches/PutFailTest.git
mvn clean install )
Confirm, I'm able to put object even if I have just single-node cluster.
There is no way to control or tune the consistency level on a write, it is set by the numOwners in the configuration as Mircea mentioned. However there is no way to force a write to error if less than numOwners is written to if there aren't that many members in the cluster to begin with.
The contract is more of the case of we will guarantee the write to numOwners if there are more than numOwners in the cluster or up to the current number of members if it is less than numOwners. The differentiating piece is the fact that Infinispan is highly consistent and is not eventually consistent where tunable consistency is used.
[ISPN-999] Support eventual consistency - JBoss Issue Tracker might be of interest to you.
Many Thanks for the responses.