[OAK-4882] Bottleneck in the asynchronous persistent cache

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.4.8, 1.5.10
• Fix Version/s: 1.4.10, 1.5.13, 1.6.0
• Component/s: cache, documentmk
• Assignee: Tomek Rękawek
• Reporter: Tomek Rękawek
• Created: 04/Oct/16 08:26
• Updated: 16/Feb/21 09:55
• Resolved: 02/Nov/16 12:43

Description

The class responsible for accepting new cache operations which will be handled asynchronously is CacheActionDispatcher. In case of a high load, when the queue is full (=1024 entries), the add() method removes the oldest 256 entries. However, we can't afford losing the updates (as it may result in having stale entries in the cache), so all the removed entries are compacted into one big invalidate action.

The compaction action (CacheActionDispatcher#cleanTheQueue) still holds the lock taken in add() method, so threads which tries to add something to the queue have to wait until cleanTheQueue() ends.

Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so it won't hold the lock for the whole time.

Issue Links

• Is contained by: OAK-5147 Backport asynchronous queue improvements to 1.2
• is duplicated by: OAK-2686 Persistent cache: log activity and timing data, and possible optimizations
• is related to: OAK-5138 NodeCache.getIfPresent() may result in writing to persistent cache
• is related to: OAK-5142 Make sure that metadata entries are eventually removed
• relates to: OAK-2761 Persistent cache: add data in a different thread
• relates to: OAK-5071 Persistent cache: use the asynchronous mode by default

Sub-Tasks

• Implement mini-benchmark for PersistentCache: Closed
• Extend PersistentCacheStats with async queue-related stats: Closed