cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuki Morishita (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11693) dtest failure in scrub_test.TestScrubIndexes.test_scrub_static_table
Date Thu, 26 May 2016 18:44:12 GMT


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).

DEBUG [PerDiskMemtableFlushWriter_2:1] 2016-05-24 11:03:20,528 - 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)

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:
>             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:
> looks distinct from another reported failure on this test for windows (CASSANDRA-11284)

This message was sent by Atlassian JIRA

View raw message