[
https://issues.apache.org/jira/browse/OAK-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318086#comment-15318086
]
Michael Dürig commented on OAK-4277:
------------------------------------
Some initial work:
* http://svn.apache.org/viewvc?rev=1747158&view=rev decouples the
{{WriteCacheManager}} from the {{SegmentWriter}}. Instead of being instantiated
by the latter it is now passed into it via a constructor argument.
* http://svn.apache.org/viewvc?rev=1747159&view=rev makes {{FileStoreBuilder}}
a top level class. This builder has a lot of its own functionality by now and
will probably accumulate more once we need to pass cache configuration through
it.
* http://svn.apache.org/viewvc?rev=1747160&view=rev: Invalidating the write
caches in {{WriteCacheManager}} is now down via an (extension of) the
{{GCMonitor}} instead of an explicit method call to the cache. This further
reduces coupling between {{SegmentWriter}}, {{FileStore}} and the caches.
> 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)
