[
https://issues.apache.org/jira/browse/CASSANDRA-8639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035228#comment-15035228
]
T Jake Luciani commented on CASSANDRA-8639:
-------------------------------------------
{code}
public static long MAX_OUTSTANDING_REPLAY_BYTES =
Long.getLong("cassandra.commitlog_max_outstanding_replay_bytes", 1024 * 64);
{code}
64k is pretty small limit I would make it 64Mb
bq. Are you talking about CommitLogReplayer.blockForWrites() which is invoked
from CommitLog.recover()? I think that is already covered.
You are right.
bq. Does clearing the data before replay and then checking for it afterwards
accomplish that? Unless you think that clearUnsafe() might not work
Yes that's what I'd like to verify., that the clear actually works. Just a nit.
If you address those and squash + rebase I'll commit.
> Can OOM on CL replay with dense mutations
> -----------------------------------------
>
> Key: CASSANDRA-8639
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8639
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Reporter: T Jake Luciani
> Assignee: Ariel Weisberg
> Priority: Minor
> Fix For: 2.1.x
>
>
> If you write dense mutations with many clustering keys, the replay of the CL
> can quickly overwhelm a node on startup. This looks to be caused by the fact
> we only ensure there are 1000 mutations in flight at a time. but those
> mutations could have thousands of cells in them.
> A better approach would be to limit the CL replay to the amount of memory in
> flight using cell.unsharedHeapSize()
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
