Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Not sure this is an appropriate place for my question.
If not maybe someone would give me a link to a proper forum.
I'm using ehcache 1.6.0 and have got a number of java.io.EOFException when accessing various elements in the cache. All look like this
**Note** that EOFException is thrown not in java.io.RandomAccessFile.readFully(); which may indicate an evicted element, but rather in java.io.ObjectInputStream.readObject() which actually reads data from an array preloaded from disk.
The content is quite simple - keys are all Strings and the data are byte arrays.
The keys for which the exceptions occur are all contained in Cache.getKeys() collection.
Can someone give me a clue what could this mean
Could it be that the disc cache is corrupted? You need to gracefully shutdown the cache; the JVM shutdown hook is not always reliable. You can shutdown reliably using CacheManager.shutdown()
Yes, I use CacheManager.shutdown().
Of course, from time to time JVM crashes and this prevents the cache from being properly shut down. But this happens not very often. Maybe a couple of times for the current cache instance.
However the current percentage of bad elements is about 10%.
Is there a way to detect a disk store corruption?
I echo alphabravo (sorry - silly joke). A lot of things can go wrong with the DiskStore files on an unclean shutdown. See this .
By the way, a follow-up question for you ehcache experts out there: If you've been good and set up your code to use CacheManager.shutdown(), but you experience a hard crash, is there a good way to deal with the resulting problems? Should I catch the EOFException and delete the underlying files? That wouldn't be my first choice, but if it's the only viable option, I can live with it.
Hm… Thank you for the link. Having read this I came to another question.
Is it possible that due to a sudden crash a key becomes pointing to some different value, not originally stored for this key?
Regarding handling EOFException. You can't catch it (at least in usuall manner) because it isn't exposed outside the cache. It's handled internally and logged to JUL.
Not sure. I think it's always failed pretty fast for me (rather than appearing to work), but I guess you never know when dealing with a corrupted data file.
Good point on the EOFException. I hadn't realized that the DiskStore wasn't rethrowing it. That definitely makes the problem harder to deal with…