[
https://issues.apache.org/jira/browse/CASSANDRA-7437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14041235#comment-14041235
]
Benedict commented on CASSANDRA-7437:
-------------------------------------
Patch [here|https://github.com/belliottsmith/cassandra/tree/7437]
> Drop Keyspace and ColumnFamily can raise assertions inside of forceRecycleAll
> still
> -----------------------------------------------------------------------------------
>
> Key: CASSANDRA-7437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7437
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Priority: Minor
> Fix For: 2.1 rc2
>
>
> I've noticed on unit test output that there are still assertions being raised
> here, so I've taken a torch to the code path to make damned certain it cannot
> happen in future
> # We now wait for all running reads on a column family or writes on the
> keyspace during a dropCf call
> # We wait for all appends to the prior commit log segments before recycling
> them
> # We pass the list of dropped Cfs into the CL.forceRecycle call so that they
> can be markedClean definitely after they have been marked finished
> # Finally, to prevent any possibility of this still happening causing any
> negative consequences, I've suppressed the assertion in favour of an error
> log message, as the assertion would break correct program flow for the drop
> and potentially result in undefined behaviour
> (in actuality there is the slightest possibility still of a race condition on
> read of a secondary index that causes a repair driven write, but this is a
> really tiny race window, as I force wait for all reads after unlinking the
> CF, so it would have to be a read that grabbed the CFS reference before it
> was dropped, but hadn't quite started its read op yet).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
