[
https://issues.apache.org/jira/browse/CASSANDRA-7554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14064816#comment-14064816
]
Benedict commented on CASSANDRA-7554:
-------------------------------------
Patch available
[here|https://github.com/belliottsmith/cassandra/tree/7554-async-cls]
> Make CommitLogSegment sync/close asynchronous wrt each other
> ------------------------------------------------------------
>
> Key: CASSANDRA-7554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7554
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Fix For: 2.1.1
>
>
> There are a few minor issues with CLS I wanted to tidy up after working on
> nearby code a bit recently, namely:
> 1) We use synchronized() for sync() and for various minor accessors, meaning
> either can block on the other, which is bad since sync() is lengthy
> 2) Currently close() (and hence recycle()) must wait for a sync() to
> complete, which means even if we have room available in segments waiting to
> be recycled an ongoing sync might prevent us from reclaiming the space,
> prematurely bottlenecking on the disk here
> 3) recycle() currently depends on close(), which depends on sync(); if we've
> decided to recycle/close a file before it is synced, this means we do not
> care about the contents so can actually _avoid_ syncing to disk (which is
> great in cases where the flush writers get ahead of the CL sync)
> To solve these problems I've introduced a new fairly simple concurrency
> primitive called AsyncLock, which only supports tryLock(), or
> tryLock(Runnable) - with the latter executing the provided runnable on the
> thread _currently owning the lock_ after it relinquishes it. I've used this
> to make close() take a Runnable to be executed _when the segment is actually
> ready to be disposed of_ - which is either immediately, or once any in
> progress sync has completed. This means the manager thread never blocks on a
> sync.
> There is a knock on effect here, which is that we are even less inclined to
> obey the CL limit (which has always been a soft limit), so I will file a
> separate minor ticket to introduce a hard limit for CL size in case users
> want to control this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
