[
https://issues.apache.org/jira/browse/OAK-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288622#comment-15288622
]
Michael Dürig edited comment on OAK-4277 at 5/18/16 8:51 AM:
-------------------------------------------------------------
At http://svn.apache.org/viewvc?rev=1744356&view=rev I started this effort by
better encapsulating those caches:
* Moved the individual caches to the top level to simplify testing,
configurability, management and monitoring
* Introduced the {{WriterCacheManager}} class as owner for those caches
managing the cache generations
A next step would be to improve how old (or generally stale) generations are
evicted. This is currently done explicitly by a respective call from the file
store compaction method. I think this should better be handled by making the
cache manager listen to gc events (aka. {{GCMonitor}}, so OAK-4283 is a
prerequisite here.
was (Author: mduerig):
At http://svn.apache.org/viewvc?rev=1744356&view=rev I started this effort by
better encapsulating those caches:
* Moved the individual caches to the top level to simplify testing,
configurability, management and monitoring
* Introduced the {{WriteCacheManager}} class as owner for those caches managing
the cache generations
A next step would be to improve how old (or generally stale) generations are
evicted. This is currently done explicitly by a respective call from the file
store compaction method. I think this should better be handled by making the
cache manager listen to gc events (aka. {{GCMonitor}}, so OAK-4283 is a
prerequisite here.
> 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)
