[ https://issues.apache.org/jira/browse/CASSANDRA-10971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15143072#comment-15143072 ]
Jonathan Ellis edited comment on CASSANDRA-10971 at 2/22/16 3:31 PM: --------------------------------------------------------------------- (IMO this should be 3.x only since we have not observed it to happen in the wild.) Edit: but I'm fine with doing it in 3.0.x as well. was (Author: jbellis): (IMO this should be 3.x only since we have not observed it to happen in the wild.) > Compressed commit log has no backpressure and can OOM > ----------------------------------------------------- > > Key: CASSANDRA-10971 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10971 > Project: Cassandra > Issue Type: Improvement > Components: Local Write-Read Paths > Reporter: Ariel Weisberg > Assignee: Ariel Weisberg > Fix For: 3.x > > > I validated this via a unit test that slowed the ability of the log to drain > to the filesystem. The compressed commit log will keep allocating buffers > pending compression until it OOMs. > I have a fix that am not very happy with because the whole signal a thread to > allocate a segment that depends on a resource that may not be available > results in some obtuse usage of {{CompleatableFuture}} to rendezvous > available buffers with {{CommitLogSegmentManager}} thread waiting to finish > constructing a new segment. The {{CLSM}} thread is in turn signaled by the > thread(s) that actually wants to write to the next segment, but aren't able > to do it themselves. -- This message was sent by Atlassian JIRA (v6.3.4#6332)