[
https://issues.apache.org/jira/browse/CASSANDRA-11687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-11687:
------------------------------------
Status: Open (was: Patch Available)
What is probably happening here is that the second rebuild is completing before
the first, so the first rebuild fails while the second succeeds, but we expect
the second rebuild to fail.
I think we should modify the test to insert more data (10k or 100k keys) with
stress and set {{streaming_throughput_mb_per_sec=1}} similar to bootstrap and
replace_address tests, trigger the first rebuild and
{{watch_log_for("rebuilding from")}}, and then trigger the second rebuild and
expect it to fail to make this more deterministic.
> dtest failure in rebuild_test.TestRebuild.simple_rebuild_test
> -------------------------------------------------------------
>
> Key: CASSANDRA-11687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11687
> Project: Cassandra
> Issue Type: Bug
> Reporter: Russ Hatch
> Assignee: Yuki Morishita
> Labels: dtest
>
> single failure on most recent run (3.0 no-vnode)
> {noformat}
> concurrent rebuild should not be allowed, but one rebuild command should have
> succeeded.
> {noformat}
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/217/testReport/rebuild_test/TestRebuild/simple_rebuild_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #217
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
