[
https://issues.apache.org/jira/browse/CASSANDRA-6557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935308#comment-13935308
]
Jonathan Ellis commented on CASSANDRA-6557:
-------------------------------------------
LGTM, committed
> 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
> Assignee: Benedict
> Priority: Minor
> Fix For: 2.1 beta2
>
> Attachments: 6557.2.txt
>
>
> 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.2#6252)
