Make it possible to tell if corrupt entries were removed.

[martinandersson]

A client may call ChronicleMapBuilder.recoverPersistedTo() in order to attempt a recovery of persisted maps.

This page says:

If the Chronicle Map is configured to store entry checksums along with entries, recovery procedure checks for each entry that the checksums is correct, otherwise it assumes the entry is corrupted and deletes it from the Chronicle Map.

Storing checksums is default for persisted maps.

Firstly, I think that this minor detail that entries are deleted should go into the JavaDoc. Not that I complain about your documentation because your documentation simply rocks. It is clear that you have engaged only the best developers to work for you =)

My problem is that I need to take action if entries are deleted. So currently, my only option is to store an entry count elsewhere. Not too much of an ordeal, but I think an enhanced API would be hugely beneficial. Given the current design, my first thought is an added overload that accept a callback/listener for entry deletions.

I wish to express my deepest gratitude for Chronicle Map. In my mind, your project clearly outshines all the competition.

[leventov]

Yes, I considered that when was developing Chronicle Map's recovery. Decided not to include anything but the simplest version without any "recovery listening" (as of now). The main reason is that recovery procedure checks the whole data structure: locks, links between sub-structures, internal entry counters, etc. In theory, it could accept a file with random data, and make it look like a correct Chronicle Map data structure (very likely it will clean up barely everything, and the "recovered" Chronicle Map will be empty). This raises many issues:

• Make "listener" API to cover all possible error conditions doesn't seem like a good idea, because it will share too much details about the data structure, and will make the API to break with every data structure change
• Some error conditions are "overlapping", e. g. if a link from the Chronicle Map data structure "root" to some sub-structure (containing actual entries) is corrupted, the recovery procedure might never "reach" that sub-structure and report that some entries in it are corrupted or not, it will simply make the "root" data structure to "forget" about that data altogether.
• On the other hand, attempts to traverse a corrupted data structure and interpreting wild data might lead to a situation, when recovery procedure tries to treat some memory that never actually contained stored entries as entries, reporting "removed entries" which never actually existed.
• Intergrating such a simple metric as total number of entries and reporting the change (so what you want to store outside Chronicle Map) may also be tricky from inside the Chronicle Map -- imagine, that in the Chronicle Map data structure only memory where entry counts stored is actually corrupted, but all the rest memory is correct. In this case "entry count reporting" will say you that entry count has changed, while it actually didn't. What you can trust a little bit more, is only 1) entry count (ChronicleMap.size()), queried after recovery procedure succeeds; 2) entry count, stored outside memory mapped file, in more durable location -- what you basically do now.

I think that this minor detail that entries are deleted should go into the JavaDoc.

Indeed it should, I will check that.

Thanks for high estimate of our work :)

[leventov]

In the new 3.13.0 release, a beta interface for listening for recovery events added: see ChronicleHashCorruption.