• Task
  • Status: Open
  • 2 Major
  • Resolution:
  • ehcache-core
  • ljacomet
  • Reporter: alexsnaps
  • March 10, 2011
  • 0
  • Watchers: 1
  • November 19, 2013

Description

We’ve had recurring speed issues with the perf tests on BlockingCache. Whether being too fast (though I’ll be deleting these tests in agreement with Greg) or too slow with respect to the boundary values in those test. We have not seen huge disparity, but we’ve been above limits nonetheless. After some digging around on that subject and some experimenting during dev week, it seems RRWL aren’t really reliable wrt starving: http://www.javaspecialists.eu/archive/Issue165.html I still believe that RRWL will suit most cases best wrt BlockingCache, but maybe we should consider letting people choose another locking approach when using BlockingCache in case they are being hit with weirdness they can’t afford. Mainly looking for opinions here…

Comments

Alexander Snaps 2011-03-14

From a chat with Chris: Using a temporary lock put in place by the writer while it works on computing the element i.e. on noticing the absent value it install a marker object on which all the readers wait we would have to completely hide it’s existence anyway to avoid changing the contract of BlockingCache we could even keep a secondary map, of locks… Map<Key, ReentrantLock> activeEntries that way it’s completely hidden from the underlying cache

Alexander Snaps 2013-11-19

To component owner for prioritization… Other than my crazy pounding tests, no one ever complained about anything here.