[ 
https://issues.apache.org/jira/browse/CASSANDRA-10109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700906#comment-14700906
 ] 

Benedict commented on CASSANDRA-10109:
--------------------------------------

Reading the Windows documentation it does look like there really are no 
guarantees. At least, it states absolutely no guarantees. The files are each 
returned by independent method calls, leaving me with even less confidence if 
they don't state it outright.

So, yes, I'd say the best thing we can do is to read all of the files in the 
directory into a buffer, then read all of the transaction files we encounter, 
and then classify the transaction files based on presence of all old files. If 
some are missing, then we assume the transaction has been committed; if all are 
present we assume it's in progress. We should make behaviour in the case of 
missing files optional, as in many cases missing the new files would be fine, I 
suspect. There's always the risk that a file is deleted after it's found and 
returned, so the user has to be robust to that. All we care about is ensuring 
we return a consistent snapshot, or a subset thereof.

> Windows dtest 3.0: ttl_test.py failures
> ---------------------------------------
>
>                 Key: CASSANDRA-10109
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10109
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Joshua McKenzie
>            Assignee: Stefania
>              Labels: Windows
>             Fix For: 3.0.x
>
>
> ttl_test.py:TestTTL.update_column_ttl_with_default_ttl_test2
> ttl_test.py:TestTTL.update_multiple_columns_ttl_test
> ttl_test.py:TestTTL.update_single_column_ttl_test
> 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\dtest.py", line 532, in tearDown
>     raise AssertionError('Unexpected error in %s node log: %s' % (node.name, 
> errors))
> AssertionError: Unexpected error in node1 node log: ['ERROR [main] 2015-08-17 
> 16:53:43,120 NoSpamLogger.java:97 - 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
(v6.3.4#6332)

Reply via email to