Branimir Lambov commented on CASSANDRA-12956:

Looking at the 3.X patch, as flush threads waiting for post-flush waiting for 
flush threads is a recipe for disaster (poor performance and deadlocks in 
particular), I would much prefer the 2i flush to be done on a different thread. 
In particular, as the flush runnables doing the actual work proceed on their 
per-disk executors, the flush thread itself 
 looks like a better candidate.

Could the inverse of the current problem also cause issues (i.e. 2i flushing 
without the data being in sstables)? It appears that the 2i flush also needs to 
eventually become transactional -- doing the above would make that easier too.

> CL is not replayed on custom 2i exception
> -----------------------------------------
>                 Key: CASSANDRA-12956
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12956
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Alex Petrov
>            Assignee: Alex Petrov
>            Priority: Critical
> If during the node shutdown / drain the custom (non-cf) 2i throws an 
> exception, CommitLog will get correctly preserved (segments won't get 
> discarded because segment tracking is correct). 
> However, when it gets replayed on node startup,  we're making a decision 
> whether or not to replay the commit log. CL segment starts getting replayed, 
> since there are non-discarded segments and during this process we're checking 
> whether there every [individual 
> mutation|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L215]
>  in commit log is already committed or no. Information about the sstables is 
> taken from [live sstables on 
> disk|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L250-L256].

This message was sent by Atlassian JIRA

Reply via email to