cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10181) Deadlock flushing tables with CUSTOM indexes
Date Tue, 25 Aug 2015 21:31:46 GMT


Sam Tunnicliffe commented on CASSANDRA-10181:

I think this has always been an issue, it probably hasn't been a problem until now as we enforced
a check in {{SIM#addIndexedColumn}} that a custom index didn't extend {{AbstractSimplePerColumnSecondaryIndex}}.
Aside from that though, I think if one had been sufficiently motivated to write one, I think
a CFS backed custom index would have deadlocked earlier versions too. 

In the linked branch, I've modified the post flush task to force flush non-CFS backed indexes,
rather than all custom indexes. I was expected to have to modify {{CFS#concatWithIndexes}}
to so that it would include CFS backed custom indexes in the actual flush task but it was
already doing so, which is another latent bug (although now it's actually the right thing
to do). The branch is built on your patch from CASSANDRA-10180.

* [3.0 branch|]
* [trunk branch|]

CI Tests:
* [3.0 testall|]
* [3.0 dtest|]
* [trunk testall|]
* [trunk dtest|]

> Deadlock flushing tables with CUSTOM indexes
> --------------------------------------------
>                 Key: CASSANDRA-10181
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Tyler Hobbs
>            Assignee: Sam Tunnicliffe
>             Fix For: 3.0 beta 2
>         Attachments: flush-deadlock-repro.txt
> In 3.0, if a table with a CUSTOM secondary index is force flushed, Cassandra will deadlock
while attempting to perform a blocking flush on the tables backing the secondary indexes.
> The basic problem is that the base table's post-flush task ends up waiting on the post-flush
task for the secondary index to complete.  However, since the post-flush executor is single-threaded,
this results in a deadlock.
> Here's the partial stacktrace for the base table part of this (line numbers may not be
100% accurate):
> {noformat}
> org.apache.cassandra.db.ColumnFamilyStore.forceBlockingFlush(
> 	at org.apache.cassandra.index.internal.CustomIndex.lambda$getBlockingFlushTask$0(
> 	at org.apache.cassandra.index.internal.CustomIndex$$Lambda$95/
> 	at
> 	at$DirectExecutorService.execute(
> 	at java.util.concurrent.AbstractExecutorService.submit(
> 	at
> 	at
> 	at org.apache.cassandra.index.SecondaryIndexManager.lambda$executeAllBlocking$39(
> 	at org.apache.cassandra.index.SecondaryIndexManager$$Lambda$94/25774682.accept(Unknown
> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(
> 	at$Head.forEach(
> 	at org.apache.cassandra.index.SecondaryIndexManager.executeAllBlocking(
> 	at org.apache.cassandra.index.SecondaryIndexManager.flushIndexesBlocking(
> 	at org.apache.cassandra.index.SecondaryIndexManager.flushAllCustomIndexesBlocking(
> 	at org.apache.cassandra.db.ColumnFamilyStore$
> {noformat}
> First, note that the base of this stacktrace is in CFS$, which means it's
running on the post-flush executor.  When {{CFS.forceBlockingFlush()}} is called on the secondary
index table, we end up blocking on another task that's submitted to the post-flush executor.
 Since that executor is single-threaded and is already running the base table task, this results
in deadlock.
> The attached patch includes a unit test and custom secondary index class (basically just
KeysIndex) to reproduce the issue.

This message was sent by Atlassian JIRA

View raw message