[
https://issues.apache.org/jira/browse/CASSANDRA-9530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15299281#comment-15299281
]
Stefania commented on CASSANDRA-9530:
-------------------------------------
OK, so we'll commit to 3.0+. For 2.1/2.2, as [~ifesdjeen] pointed out above,
compression will detect corruption making this patch less critical, given that
compression is typically enabled in the pre 3.0 world.
Whilst the multiplexed tests are clean, unfortunately we have many failures
across utests and dtests. I'm pretty sure they are not related to this patch
but it is hard to check that every single failing tests also fails on unpatched
branches when there are so many. Therefore, I've applied the patches this
morning to the latest 3.0/3.7/trunk branches and I am rerunning CI in the hope
to shake some of the failures:
||3.0||3.7||trunk||
|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-9530-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-9530-3.7-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-9530-testall/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-9530-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-9530-3.7-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-9530-dtest/]|
> 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)
