[
https://issues.apache.org/jira/browse/CASSANDRA-6557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874732#comment-13874732
]
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: https://issues.apache.org/jira/browse/CASSANDRA-6557
> 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
(v6.1.5#6160)
