[jira] [Commented] (CASSANDRA-7554) Make CommitLogSegment sync/close asynchronous wrt each other

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

    [ 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)