cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Branimir Lambov (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12956) CL is not replayed on custom 2i exception
Date Thu, 01 Dec 2016 10:05:58 GMT


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 [here|]
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:
>             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|]
in commit log is already committed or no. Information about the sstables is taken from [live
sstables on disk|].

This message was sent by Atlassian JIRA

View raw message