[ https://issues.apache.org/jira/browse/OAK-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14647589#comment-14647589 ]
Alex Parvulescu commented on OAK-3168: -------------------------------------- To followup with what Guava Cache is doing I see the removal listeners are a bit more complex [0], and the notification itself also contains the reason, of which 'REPLACED' [2] can be a possible value. Adding this level of info to the eviction callbacks might be a bit more involved, so I'm going to look into fixing the segment code. Along these lines I forgot to add Thomas suggestion to use 'putIfAbsent'. {code} cache.asMap().putIfAbsent(..) {code} [0] https://code.google.com/p/guava-libraries/wiki/CachesExplained#Removal_Listeners [1] http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/cache/RemovalCause.html [2] http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/cache/RemovalCause.html#REPLACED > SegmentCache flushes Segment on update > -------------------------------------- > > Key: OAK-3168 > URL: https://issues.apache.org/jira/browse/OAK-3168 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segmentmk > Reporter: Alex Parvulescu > Assignee: Alex Parvulescu > Fix For: 1.3.5 > > > The SegmentCache currently uses the cache eviction call to remove the Segment > instance from memory to help keep the cache memory requirements under control > [0]. > What I've noticed though, is that for a cache update (existing key) there > will also be an eviction call happening, which results in a lot of extra IO > pressure on the SegmentStore which not only is not able to cache the segment, > but is forced to reload it multiple times as the reference gets nullified > after each load. > This comes from the sampling behavior of the SegmentId: it will not hit the > cache each time it needs to load a new Segment, but rather load it from IO > and (re)place it in the cache, based on a sampling rate [1]. > Now I see 2 options: > * change the cache code to _not_ call the eviction callback on updates (or > allow disabling this call on updates) > * change the SegmentTracker code to add the value to the cache only if it's > not there as Segments are immutable, so no harm done. > Raised this issue offline with [~tmueller], [~mduerig] first and as I > understand [~mduerig] is in favor of option one, while [~tmueller] proposed > that the Lirs cache impl should be inline with what the guava cache does, and > depending on that we could choose the right fix here. > Hope this covers everything. > [0] > https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentTracker.java#L133 > [1] > https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentId.java#L135 -- This message was sent by Atlassian JIRA (v6.3.4#6332)