cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6557) CommitLogSegment may be duplicated in unlikely race scenario
Date Fri, 17 Jan 2014 12:51:19 GMT


Benedict commented on CASSANDRA-6557:

bq. Let's do that for now then.

Okay. I'll hold off until we decide if the off-heap memtables are going to make it into 2.1,
as they really *need* need the NBQ. There are at least two spots where without atomic swapping
of head/tail pointers the algorithm will be either unsafe, have unreasonable consequences,
or unreasonable performance tradeoffs. Or, at least, we can decide that when we come to it

> CommitLogSegment may be duplicated in unlikely race scenario
> ------------------------------------------------------------
>                 Key: CASSANDRA-6557
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: 2.1
>            Reporter: Benedict
>             Fix For: 2.1
> In the unlikely event that the thread that switched to a new CLS has not finished executing
the cleanup of its switch by the time the CLS has finished being used, it is possible for
the same segment to be 'switched' in again. This would be benign except that it is added to
the activeSegments queue a second time also, which would permit it to be recycled twice, creating
two different CLS objects in memory pointing to the same CLS on disk, after which all bets
are off.
> The issue is highly unlikely to occur, but highly unlikely means it will probably happen
eventually. I've fixed this based on my patch for CASSANDRA-5549, using the NonBlockingQueue
I introduce there to simplify the logic and make it more obviously correct.

This message was sent by Atlassian JIRA

View raw message