These are chat archives for atomix/atomix
We are no longer monitoring this channel, please join Slack! https://join.slack.com/t/atomixio/shared_invite/enQtNDgzNjA5MjMyMDUxLTVmMThjZDcxZDE3ZmU4ZGYwZTc2MGJiYjVjMjFkOWMyNmVjYTc5YjExYTZiOWFjODlkYmE2MjNjYzZhNjU2MjY
There are use cases for them. Like I said, the reason
entrySet exist in
DistributedMap is because it was required to build an Atomix based cluster manager for Vert.x, which stores a small amount of state in a
Map and frequently calls
keySet on that map. Clearly it doesn’t scale, but it doesn’t scale much less than a callback-based iteration method. It’s not like maps even can be larger than the memory of any node. Indeed, the limitation that maps and other data structures must fit into the memory of a single node already exists, so it’s not entirely impractical to provide methods for pulling full data structures to the client. It would be impractical if maps were partitioned.
As long as it’s documented that
toArray will pull the entire data structure to the client it’s fine with me, and the stream API can be implemented for using callbacks. I think it’s worth making the collections fully compatible with Java collection interfaces for use cases like the Vert.x cluster manager.