EHC ❯ BlockingCache perfomance issue because of default number of mutexes

• Type: Bug
• Status: Closed
• Priority: 2 Major
• Resolution: Fixed
• Component/s: ehcache-core
• Labels:

• Assignee: alexsnaps
• Reporter: ihrytsyuk
• Created: September 24, 2010
• Votes: 0
• Watchers: 2
• Updated:

  October 19, 2010
• Resolved:

  September 30, 2010

Attachments

• ihrytsyuk (4.00 k) application/zip Ehcache2.2.0-BlockingCacheIssueWithMutexes-maven2Project.zip

Description

Lets consider next example: * Thread-1 requests element by key-1 from a cache. The Element doesn’t exist in the cache. It takes 30 sec to calculate element. * Several milliseconds later Thread-2 requests element by key-2 from the cache. The Element exists in the cache. * CompoundStore#getSyncForKey(Object key) returns the same Sync for key-1 and key-2 from method. So Thread-2 will wait for 30 sec until Thread-1 is calculating its element. But Thread-2’s element is already in the cache and must be returned asap.

In ehcache-core-2.0.1 we were able to pass number of mutexes (a.k.a numberOfStripes) to BlockingCache constructor to decrease probability of mentioned scenario. In ehcache-core-2.2.0 we also can pass a numberOfStripes to constructor, but actually default number of mutexes (64) is used. As result, we can have unreasonable delays.

Test application is attached. It shows mentioned scenario and is maven2-ready.

Comments

Fiona OShea 2010-09-29

Alex, does this look like a regression? Assigning to Magnum to get a quick answer:)

Alexander Snaps 2010-09-30

reverted to StripedReadWriteLockSync for standalone blocking cache