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

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

It's ready to commit but I am not sure we should limit this to trunk. 

I'm sorry I did not check the category of this ticket until now, and so far 
I've treated it as an improvement since the patch provided is on trunk. 
Typically however, a major bug goes to 2.2+. I think in this case though, we 
can make an exception and commit it only to 3.0+, since the 2.2 and 3.0 
branches are very divergent and I don't think it's worth creating a new patch 
for 2.2. 

[~iamaleksey] or [~slebresne] which branch do you think we should commit this 
ticket to? 

> 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