• Bug
  • Status: Resolved
  • 2 Major
  • Resolution: Not a Bug
  • ehcache
  • cdennis
  • Reporter: javor
  • October 06, 2012
  • 0
  • Watchers: 6
  • October 19, 2012
  • October 19, 2012

Attachments

Description

Cache configured with eternal (non-expiring) unbounded diskStore is sometimes evicting elements.

Configuration is like this:

<ehcache>
	<diskStore path="/tmp"/>
	<cache name="testCache"
			maxBytesLocalHeap="1M"
			eternal="true">
		<persistence strategy="localTempSwap"/>
	</cache>
</ehcache>

I’m attaching a failing test which reproduces the issue. Failing test results:

noElementsShouldBeEvicted(tests.ehcache.CacheWithDiskStoreTest): Non-zero number of evicted elements: 8378
  testCachedElementsCanBeRetrieved(tests.ehcache.CacheWithDiskStoreTest): Failed retreiving value for key key 0

(Number of evicted elements reported by the test is not always the same)

h2. Additional findings * Similar problem is reproduced when specifying in-memory limit with maxEntriesLocalHeap (instead of maxBytesLocalHeap) ** Reproducing that however requires caching many more elements (or/and maybe longer time to execute): I managed to reproduce when trying to put ~5 million elements to cache. * The problem is reproduced with both configuration-file and API configuration. * There is enough room on disk. There is file created by Ehcache in the specified diskStore path (but seems at some moment the file stops to grow).

Comments

Fiona OShea 2012-10-12

Can you look at this for Gladstone+?

Chris Dennis 2012-10-19

The behavior you are seeing when configuring the cache with a “maxBytesLocalHeap” is as expected. The open source DiskStore uses heap space to store the keys. If it starts to use more heap space than has been allowed then elements will be evicted from the disk store in order to save space.

Regarding the behavior when using “maxEntriesLocalHeap” - I couldn’t reproduce this myself when trying counts of up to 5M. The only thing I can suspect is that maybe the disk store writes are failing for some reason (possibly due to lack heap space) and that this means we are failing to write some values correctly. If you have a reproducible test case for this second scenario then it would be very helpful if you filed a second jira for that issue.