Changing the size of a ChronicleMap

Question

I have a ChronicleMap (v2.3.2) running in a server, created using the following call:

ChronicleMapBuilder.of(MyKey.class, MyValue.class).entries(20_000_000).createPersistedTo(pathToData);

There is a possibility that the number of entries stored in the ChronicleMap will need to evolve. Therefore, I envisage doing the following at application startup:

1. load the existing ChronicleMap from disk
2. get maximum number of entries from the existing ChronicleMap
3. if the new size (loaded from a configuration file) isn't different then finish, else...
4. create a new ChronicleMap with the new size
5. copy the contents of the old ChronicleMap to the new one
6. close and delete the old ChronicleMap

However, I can't see anything in the interface exposed by ChronicleMap which will let me find out the value passed into the entries method when it was created. I assume that longSize() is just the number of entries actually stored, rather than the map's maximum size.

Is there a way to find out this value? Or perhaps there's a better way to do this kind of migration?

Answer 1

If performing this sequence of steps on the application startup and the new size (loaded from a configuration file) changed, you actually insert that number of new entries into the map, i. e. on application shutdown the map size is equal to the new size (loaded from a config), why couldn't you compare longSize() of the map with the new expected size?

There is no way to retrieve the value mapped to entries() configuration, because it is not even a part of the internal ChronicleMap's state, i. e. it is not stored in private fields.

The bulletproof way would be to keep the previous configuration file, when the main configuration file is updated, to compare size configuration in them.

There is no fundamentially different and better way to evolve the ChronicleMap size. ChronicleMap doesn't suit well, if you need to evolve the size. So you need to write some kind of this boilerplate code.

Chronicle Map 3 could grow beyond limit (up to x1000 size from the original), but it's performance drops sharply, if the size exceeds the originally configured entries() number.

UPDATE. Also important to note, that in some cases you may not, in fact, need to change the size, e. g. if values are large (KBs and up) and the number of entries is also large. In this case you could configure the maximum possible Map size from the start, but it won't overuse memory much, because of the Linux feature of lazy page allocation.