Hello,

this would need to invoke the distributed executor to send a "count" operation across all nodes. So the cost is of that of an RPC being invoked to each other node, and each node is going to quickly iterate on each element to increment your counter.. relatively costly.

A far better approach would be to use the statistics API; in this case you would need to send a custom command to the other nodes to read the statistics, add them all together and divide by the number of "numOwners" you have set as values might have multiple copies (if that is what you want).

Statistics are pretty accurate but might present a +1/-1 skew occasionally, so if you can't tolerate that use the distributed executor (but also make sure noone is adding/removing content at the same time).

To get the real size in terms of memory consumption, that's an hard operation to do in Java as the platform doesn't provide this information. You could estimate the size of objects by looking at the number of bytes when they are marshalled or stored, or the average (full container - empty container) / number of stored elements.. a very rough approximation. Using the size from the marshallers is quite accurate if you configure the cache to store the values in serialized form (as byte[] instead of instances).

this would need to invoke the distributed executor to send a "count" operation across all nodes. So the cost is of that of an RPC being invoked to each other node, and each node is going to quickly iterate on each element to increment your counter.. relatively costly.

I don't think it needs to iterate over the elements of each node. If you submit an DistributedCallable and the DistributedCallable.call method rerturns a cache.size() (it has a refernce to cache from (DistributedCallable.setEnvironment)   you'd get the same effect as your proposal with custom command.