[
https://issues.apache.org/jira/browse/OAK-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159046#comment-15159046
]
Michael Dürig commented on OAK-4015:
------------------------------------
The fairness guarantee still applies amongst expedited/non-expedited threads
trying to enter the lock. This is what that comment refers to.
{{monitor.getOccupiedDepth() == 1}} is required in case the lock has been
entered more than once by the current thread. It ensures it is only removed
from the set of expedited threads once it leaves the lock for the last time.
> Expedite commits from the compactor
> -----------------------------------
>
> Key: OAK-4015
> URL: https://issues.apache.org/jira/browse/OAK-4015
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
> Reporter: Michael Dürig
> Labels: compaction, gc, perfomance
> Fix For: 1.6
>
> Attachments: OAK-4015-histo.png, OAK-4015-wait-time.png
>
>
> Concurrent commits during compaction cause those to be re-compacted.
> Currently it seems that the compaction thread can end up waiting for some
> time to acquire the commit lock [1], which in turn causes more commits to
> pile up to be re-compacted. I think this could be improved by tweaking the
> lock such that the compactor could jump ahead of the queue. I.e. use a lock
> which can be acquired in expedited mode.
> [1] SegmentNodeStore#commitSemaphore
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)