cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10109) Windows dtest 3.0: failures
Date Thu, 27 Aug 2015 13:06:46 GMT


Benedict commented on CASSANDRA-10109:

bq. That's already separate from listing files

They currently share the logic for corroborating the transaction log file integrity, which
is too pessimistic for this proposal

I think while we're here we should consider refactoring the verification a little, to perform
it all in one-pass, as currently the control flow is a little confusing, and this change could
worsen that. I _think_ it would be clearer to load all of the information we have (including
any exceptions encountered loading a Record), annotate the Record with that information, and
then iterate over that in one go, applying all of our logic in a more clearly declarative
method. Right now it's scattered across at least four methods, involving some counterintuitive
control flow from exception handling and {{isLast}} flag.

bq. {{SSTableReader}} needs the tidier. We need to find a place for the tidier to make it
package private. Shall I move it to LT?

Sounds like a good idea

> 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