cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T Jake Luciani (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7437) Ensure writes have completed after dropping a table, before recycling commit log segments (CASSANDRA-7437)
Date Tue, 26 Aug 2014 15:38:57 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110842#comment-14110842
] 

T Jake Luciani commented on CASSANDRA-7437:
-------------------------------------------

Overall looks good.

Nit. Your testcase should create multiple keyspaces/tables since the bug is when commitlog
contains more than one.  I understand the test happens be including the system keyspace now
but the test should be more explicit.

>  Ensure writes have completed after dropping a table, before recycling commit log segments
(CASSANDRA-7437)
> -----------------------------------------------------------------------------------------------------------
>
>                 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.0
>
>         Attachments: 7437.log, 7437.round2.txt, 7437_test.py
>
>
> 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).- In fact
this is also safe, as these modifications all grab a write op from the Keyspace, which has
to happen before they get the CFS, and also because we drop the data before waiting for reads
to finish on the CFS.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message