[jira] [Commented] (OAK-4277) Finalise de-duplication caches

["Alex Parvulescu (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15312028#comment-15312028 ] 

Alex Parvulescu commented on OAK-4277:
--------------------------------------

{code}
    private final Generation<RecordCache<String>> stringCaches =
            new Generation<>(STRING_RECORDS_CACHE_SIZE <= 0
                    ? RecordCache.<String>empty()
                    : RecordCache.<String>factory(STRING_RECORDS_CACHE_SIZE));
{code}
could we allow the {{factory()}} method to produce an{{empty()}} cache transparently if the size is zero or negative? (code comes from WriterCacheManager)

> Finalise de-duplication caches
> ------------------------------
>
>                 Key: OAK-4277
>                 URL: https://issues.apache.org/jira/browse/OAK-4277
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: segment-tar
>            Reporter: Michael Dürig
>            Assignee: Michael Dürig
>              Labels: caching, compaction, gc, monitoring
>             Fix For: 1.6
>
>
> OAK-3348 "promoted" the record cache to a de-duplication cache, which is heavily relied upon during compaction. Now also node states go through this cache, which can seen as one concern of the former compaction map (the other being equality). 
> The current implementation of these caches is quite simple and served its purpose for a POC for getting rid of the "back references" (OAK-3348). Before we are ready for a release we need to finalise a couple of things though:
> * Implement cache monitoring and management
> * Make cache parameters now hard coded configurable
> * Implement proper UTs 
> * Add proper Javadoc
> * Fine tune eviction logic and move it into the caches themselves (instead of relying on the client to evict items pro-actively)
> * Fine tune caching strategies: For the node state cache the cost of the item is determined just by its position in the tree. We might want to take further things into account (e.g. number of child nodes). Also we might want to implement pinning so e.g. checkpoints would never be evicted. 
> * Finally we need to decide who should own this cache. It currently lives with the {{SegmentWriter}}. However this is IMO not the correct location as during compaction there is dedicated segment writer whose cache need to be shared with the primary's segment writer upon successful completion. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)