cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7554) Make CommitLogSegment sync/close asynchronous wrt each other
Date Thu, 17 Jul 2014 10:56:04 GMT


Benedict commented on CASSANDRA-7554:

Patch available [here|]

> Make CommitLogSegment sync/close asynchronous wrt each other
> ------------------------------------------------------------
>                 Key: CASSANDRA-7554
>                 URL:
>             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

View raw message