[
https://issues.apache.org/jira/browse/CASSANDRA-9752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106942#comment-15106942
]
Philip Thompson commented on CASSANDRA-9752:
--------------------------------------------
I would be comfortable, but only if we're sure that the OOM is acceptable? Do
we have an accurate accounting of how much RAM these need with vnodes, and if
we're okay with that amount?
> incremental repair dtest flaps on 2.2
> --------------------------------------
>
> Key: CASSANDRA-9752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9752
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jim Witschey
>
> {{incremental_repair_test.py:TestIncRepair.multiple_subsequent_repair_test}}
> flaps on 2.2. It's hard to tell what failures are repair-specific, but there
> are a few distinct failures I've seen recently:
> - [an NPE in
> StorageService|http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest/143/testReport/junit/incremental_repair_test/TestIncRepair/multiple_subsequent_repair_test/]
> - [an NPE in
> SSTableRewriter|http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest/135/testReport/junit/incremental_repair_test/TestIncRepair/multiple_subsequent_repair_test/].
> I believe this is related to CASSANDRA-9730, but someone should confirm this.
> - [an on-disk data size that is too
> large|http://cassci.datastax.com/view/cassandra-2.2/job/cassandra-2.2_dtest/133/testReport/junit/incremental_repair_test/TestIncRepair/multiple_subsequent_repair_test/]
> You can find the test itself [here on
> GitHub|https://github.com/riptano/cassandra-dtest/blob/master/incremental_repair_test.py#L206]
> and run it with the command
> {code}
> CASSANDRA_VERSION=git:trunk nosetests
> incremental_repair_test.py:TestIncRepair.multiple_subsequent_repair_test
> {code}
> Assigning [~yukim], since you're the repair person, but feel free to reassign
> to whoever's appropriate.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
