It is possible for the count store files to be perceived as unusable in case the header information or some key data is not consistent. While not a fatal error, this is communicated by throwing an IOException which is caught and the paged portion of the opened file will be unmapped. However, before this fix it was that IOException would be ignored by the responsible catch clause, leading to the leak of the file map and the inability of the database to shutdown since that file was mapped. This patch fixes the issue by catching all possible Exceptions thrown during open and not only RuntimeExceptions as before.
Some exception messages and debug logging statements were too generic and lacked information about the specific condition that could lead to the problem observed. This commit adds some information that can provide some insights that can be useful for debugging.
The test occasionally failed because of a race condition between sending a message from NetworkSender and stopping a NetworkReceiver instance. The test depended on the message sent to result in a ClosedChannelException which occasionally did not happen, because NetworkReceiver.stop() does not block waiting for all listening threads to exit. The result is that the message would be received and the expected exception would not happen. The fix adds a retry loop that keeps sending messages until the exception manifests. Then it goes on to verify the actual functionality