How does grouping operate for a distributed cache when "number of copies" > 1, the behaviour seems clear when "number of copies" = 1, but if grouping locates objects to a specific node and only one copy can be located on each node this seems to lead to a contradiction? Does the "number of copies" become redundant in the presence of grouping?
If you use grouping, all the keys with the same group will have the same owners, it doesn't matter what the value of numOwners is (there's a typo in the Group Javadoc, it says owner but it should say owners).
How it works: Normally Infinispan computes the hashCode of a key and determines a list of owners based on this hashCode and an internal "consistent hash". If you enable grouping for a key, the key's hashCode is replaced with the group's hashCode, but the rest of the algorithm stays the same.
Is it possible to group objects across different caches, i.e. is it possible to annote a common attribute of two or more object types (separate caches) with the grouping annotation such that they will co-locate within their respective caches to a common node?
Not with the default consistent hashing algorithm. You have to use a different consistent hash factory, either SyncConsistentHashFactory or TopologyAwareSyncConsistentHashFactory.
Thanks for this information. As you say, I think I was hung-up on the singlular use of "owner" in the documentation chapter "The Grouping API". If the Javadoc is going to be updated then it would be a good idea to update the documentation as well, maybe adding a new sentence about the (non) impact of using numOwners in conjunction with grouping.