• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Not a Bug
  • ehcache
  • drb
  • Reporter: jn
  • February 09, 2017
  • 0
  • Watchers: 3
  • February 09, 2017
  • February 09, 2017

Attachments

Description

We are trying to integrate ehcache into our application, and discovered that sometimes the cache lookup failed when er expect it should succeed. We narrowed the failures down to when the lookup key contains fields which are of enum type. We also simplified the test case and discovered the same problem when the key itself is an enum value. Note that we are using the default serialization out-of-the-box.

I have attached a simple, stand-alone test case which demonstrates the problem. The test case starts by (1) printing out all of the cached values, then (2) does some lookups, then (3) prints out all of the cached values. For step (1), we expect that no values will be displayed, for step (2) we expect the lookups to cause loads, and for step (3) we expect all of the previously looked up values to be displayed as cached values. If the test case is run a second time, we expect for step (1), all of the previously looked up values will be displayed, for step (2) none of the lookups cause loads, and for step (3), all of the previously looked up values will be displayed.

*Running in the same jvm.* If you start without any cached files (delete the cache dir) and then perform the test case twice within the same jvm instance (by uncommenting the second testOptionLongCache() call), it works as expected. Here is the output:

  • Cache ‘OptionLong’ created in EhcacheManager.
  • entries in cache:
  • found 0 entries
  • performing lookups:
  • loading A
  • get(A) = 65
  • loading B
  • get(B) = 66
  • loading C
  • get(C) = 67
  • loading D
  • get(D) = 68
  • entries in cache:
  • D => 68
  • A => 65
  • B => 66
  • C => 67
  • found 4 entries
  • Cache ‘OptionLong’ removed from EhcacheManager.
  • The index for data file ehcache-disk-store.data is more recent than the data file itself by 5ms : this is harmless.
  • Cache ‘OptionLong’ created in EhcacheManager.
  • entries in cache:
  • D => 68
  • A => 65
  • B => 66
  • C => 67
  • found 4 entries
  • performing lookups:
  • get(A) = 65
  • get(B) = 66
  • get(C) = 67
  • get(D) = 68
  • entries in cache:
  • D => 68
  • A => 65
  • B => 66
  • C => 67
  • found 4 entries
  • Cache ‘OptionLong’ removed from EhcacheManager.
  • done

*Running in two separate jvm instances.* If you start without any cached files (delete the cache dir) and then perform the test case twice – in two separate jvm invocations (by leaving the second testOptionLongCache() call commented out and running the main() method twice), the second invocation does not behave as expected. For step (1), no cache entries are found, for step (2) each lookup causes a load, and for step (3) there are duplicate entries. Here is the output:

First run:

  • Cache ‘OptionLong’ created in EhcacheManager.
  • entries in cache:
  • found 0 entries
  • performing lookups:
  • loading A
  • get(A) = 65
  • loading B
  • get(B) = 66
  • loading C
  • get(C) = 67
  • loading D
  • get(D) = 68
  • entries in cache:
  • D => 68
  • A => 65
  • B => 66
  • C => 67
  • found 4 entries
  • Cache ‘OptionLong’ removed from EhcacheManager.
  • done

Second run:

  • The index for data file ehcache-disk-store.data is more recent than the data file itself by 5ms : this is harmless.
  • Cache ‘OptionLong’ created in EhcacheManager.
  • entries in cache:
  • found 0 entries
  • performing lookups:
  • loading A
  • get(A) = 65
  • loading B
  • get(B) = 66
  • loading C
  • get(C) = 67
  • loading D
  • get(D) = 68
  • entries in cache:
  • C => 67
  • A => 65
  • D => 68
  • A => 65
  • B => 66
  • B => 66
  • C => 67
  • D => 68
  • found 8 entries
  • Cache ‘OptionLong’ removed from EhcacheManager.
  • done

Comments

Jim Newsham 2017-02-09

This is against ehcache 3.2.0. I couldn’t find the appropriate version in jira.

Jim Newsham 2017-02-09

We are using Java 8, in Windows 10 x64.

James House 2017-02-09

Ehcache 3.x issues are tracked here: https://github.com/ehcache/ehcache3/issues

Louis Jacomet Jacomet 2017-02-09

This relates to Ehcache 3, not 2.x - see https://github.com/ehcache/ehcache3/issues/1841