EHC ❯ Index file should not be deleted on successful start-up
-
Bug
-
Status: Closed
-
-
Resolution: Fixed
-
-
-
drb
-
Reporter: sourceforgetracker
-
September 21, 2009
-
0
-
Watchers: 0
-
September 22, 2009
-
September 22, 2009
Description
The current behaviour in DiskStore#readIndex() is to delete the index file immediately after reading it, whether or not the index restore was successful.
Deleting the index if restore is unsuccessful makes perfect sense, but if restore was successful, why delete it, since it might contain valuable data that would be lost on abnormal termination?
For example, I have a case where JVM shut-down or sevlet shut-down would have to write about 2.5 million entries from memory to disk, which, although fast, is not fast enough for our monitoring scripts, which will kill -9 the process after 15 seconds of it being asked to shut-down. Therefore I actually schedule a periodic flush() of the cache every X minutes, which is great because it’s asynchronous with cache operation and builds a recoverable persistent cache. Because of the JVM-shutdown problem, I’ve disabled the JVM shut-down hook, and don’t perform any ‘manual’ cache manager shutdown, relying on the periodic flush() to keep the persistent cache reasonably up-to-date.
Now when I restart the application, the persistent store is restored (great), but then the index file is immediately deleted, which means if a restart occurs before the periodic flush() kicks in, I loose everything.
As a work-around, I schedule an immediate flush() to re-build the index, but this seems like a pointless operation, since a few milliseconds ago, the cache was still there!
Any chance of changing this behaviour? Sourceforge Ticket ID: 2003322 - Opened By: ellispritchard - 26 Jun 2008 17:45 UTC
Re-opening so that I can properly close out these issues and have correct Resolution status in Jira