cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10109) Windows dtest 3.0: failures
Date Thu, 03 Sep 2015 10:39:46 GMT


Stefania commented on CASSANDRA-10109:

bq. a lister could quite reasonably encounter corruption twice in a row just due to tearing
of writes

As in a record gets written only partially? I guess I agree in this case.

bq. In which case I think I would prefer to just apply the behaviour we decided on for cleanup
to listers as well (i.e. ignore the txn log entirely in the event it does not validate - but
leave that validation logic as is).

OK but if the last record is corrupt at the moment the validation passes. So what do we do
with this final corrupt record then: is it "UNKNOWN", which means transaction always in progress,
or do we attempt to at least read the first word, the record type, to determine if it is ABORT

> Windows dtest 3.0: failures
> ---------------------------------------
>                 Key: CASSANDRA-10109
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Joshua McKenzie
>            Assignee: Stefania
>              Labels: Windows
>             Fix For: 3.0.0 rc1
> Errors locally are different than CI from yesterday. Yesterday on CI we have timeouts
and general node hangs. Today on all 3 tests when run locally I see:
> {noformat}
> Traceback (most recent call last):
>   File "c:\src\cassandra-dtest\", line 532, in tearDown
>     raise AssertionError('Unexpected error in %s node log: %s' % (, errors))
> AssertionError: Unexpected error in node1 node log: ['ERROR [main] 2015-08-17 16:53:43,120 - This platform does not support atomic directory streams (SecureDirectoryStream);
race conditions when loading sstable files could occurr']
> {noformat}
> This traces back to the commit for CASSANDRA-7066 today by [~Stefania] and [~benedict].
 Stefania - care to take this ticket and also look further into whether or not we're going
to have issues with 7066 on Windows? That error message certainly *sounds* like it's not a
good thing.

This message was sent by Atlassian JIRA

View raw message