[ 
https://issues.apache.org/jira/browse/CASSANDRA-9530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15299648#comment-15299648
 ] 

Stefania commented on CASSANDRA-9530:
-------------------------------------

I've reviewed all the failures of the last run I launched. We need to take a 
look at [this 
one|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-9530-testall/lastCompletedBuild/testReport/org.apache.cassandra.db.compaction/BlacklistingCompactionsTest/testBlacklistingWithLeveledCompactionStrategy/]
 and [this 
one|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-9530-testall/lastCompletedBuild/testReport/junit.framework/TestSuite/org_apache_cassandra_index_sasi_SASIIndexTest/].
 

The second one doesn't seem related but it pretty much reliably fails on our 
3.7 and trunk patches and passes on the unpatched branches.



> SSTable corruption can trigger OOM
> ----------------------------------
>
>                 Key: CASSANDRA-9530
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9530
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Alex Petrov
>
> If a sstable is corrupted so that the length of a given is bogus, we'll still 
> happily try to allocate a buffer of that bogus size to read the value, which 
> can easily lead to an OOM.
> We should probably protect against this. In practice, a given value can be so 
> big since it's limited by the protocol frame size in the first place. Maybe 
> we could add a max_value_size_in_mb setting and we'd considered a sstable 
> corrupted if it was containing a value bigger than that.
> I'll note that this ticket would be a good occasion to improve 
> {{BlacklistingCompactionsTest}}. Typically, it currently generate empty 
> values which makes it pretty much impossible to get the problem described 
> here. And as described in CASSANDRA-9478, it also doesn't test properly for 
> thing like early opening of compaction results. We could try to randomize as 
> much of the parameters of this test as possible to make it more likely to 
> catch any type of corruption that could happen.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to