[
https://issues.apache.org/jira/browse/CASSANDRA-6557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874631#comment-13874631
]
Benedict commented on CASSANDRA-6557:
-------------------------------------
bq. active a NBQV on the available NBQ
Just to clarify how this would work: a NBQ can create views on their data that
retain references to any items polled from the original after the view was
created. A view created on available at startup would basically have the option
of polling/iterating over all items added to available, just on its own
schedule. So we would do nothing to maintain allocatingFrom or active, we would
just poll/remove items from their queue as necessary, based on their own
criteria.
> 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)
