[ https://issues.apache.org/jira/browse/CASSANDRA-11693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15302665#comment-15302665 ]
Yuki Morishita commented on CASSANDRA-11693: -------------------------------------------- I haven't reproduced this in local yet, but from the log files attached, I figured out what's going on. I think the failure is happening when C* flushes table to range-aware JBOD and one of them end up 0 bytes (so no SSTable created on that disk). {code} DEBUG [PerDiskMemtableFlushWriter_2:1] 2016-05-24 11:03:20,528 Memtable.java:447 - Completed flushing /mnt/tmp/dtest-7b4ZHQ/test/node1/data2/ks/users-1f027430219f11e6944229accea9bb00/mb-3-big-Data.db (0.000KiB) for commitlog position ReplayPosition(segmentId=1464087795410, position=50933) {code} After this, internal SSTable counter is incremented to 4, and scrub will produce SSTable 4 and 5. However, there are only 1 and 2 SSTables before scrub, the test expects SSTables 3 and 4 will be present after scrub by incrementing current SSTable file's generation from file name ({{increase_sstable_generations()}}). I'm still trying to figure out how to fix test, but since currently there is no way to get what the next SSTable generation will be, assinging tokens to the node manually so there won't be zero byte SSTable created to the disk. > dtest failure in scrub_test.TestScrubIndexes.test_scrub_static_table > -------------------------------------------------------------------- > > Key: CASSANDRA-11693 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11693 > Project: Cassandra > Issue Type: Bug > Reporter: Russ Hatch > Assignee: Yuki Morishita > Labels: dtest > Fix For: 3.x > > Attachments: node1.log, node1_debug.log > > > intermittent failure: > http://cassci.datastax.com/job/trunk_offheap_dtest/166/testReport/scrub_test/TestScrubIndexes/test_scrub_static_table/ > looks distinct from another reported failure on this test for windows > (CASSANDRA-11284) -- This message was sent by Atlassian JIRA (v6.3.4#6332)