EHC ❯ SelfPopulatingCache should expose the numberOfStripes constructor parameter from BlockingCache

• Type: New Feature
• Status: Resolved
• Priority: 2 Major
• Resolution: Fixed
• Component/s: ehcache-core
• Labels:

• Assignee: cschanck
• Reporter: jahlborn
• Created: July 26, 2013
• Votes: 0
• Watchers: 4
• Updated:

  February 20, 2014
• Resolved:

  January 06, 2014

Description

The SelfPopulatingCache does not provide a constructor parameter to influence the “numberOfStripes” parameter for the BlockingCache. This should be exposed so that it can be specified when creating a SelfPopulatingCache.

On a related note, the default value for the number of stripes for the BlockingCache seems rather high for the average use case. the default value is 2048 which (assuming i understand correctly) would require an application with 2048 active threads accessing 2048 unique keys in the cache to benefit from the number of stripes. i would guess that in normal usage that the key overlaps is fairly high, so you probably need a few multiples more of active threads to truly utilize that many locks. (for comparison, the default concurrency level of the ConcurrentHashMap in the jdk is 16).

now, this may seem like a silly thing to worry about, but all those lock stripes use a non-trivial amount of memory. on a 64bit jvm, each stripe can be ~200 bytes. with 2048 stripes, that comes to ~400k of memory just for locking overhead! in our multitenant application, we have ~1000 cache instances. we realized that the cache instances alone were using up 400MB of memory aside from any contained data!

Comments

Chris Schanck 2014-01-06

Added constructor to expose functionality.