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

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

bq. I left them separated just because I followed to the letter your algo, so 
OK to have them together,

Yes, I realise I suggested the opposite, and honestly it's on a knife's edge 
which is better. In this case I felt the code came out significantly cleaner, 
but I don't feel strongly about it.

bq. I can fix up the remaining tests, just let me know if a final corrupt 
record should be considered unknown or commit/abort, etc.

Well, like I say, I think that needs a little consideration. It's not clear to 
me what the correct behaviour from the POV of a file lister would be with a 
corrupted commit/abort record, and mismatched other records. In the case of 
cleanup we have decided to abort and treat everything as "final" - but in this 
case, we're just asking for a list of files. We can easily encounter temporary 
corruption, but we already account for that in the algorithm, so this would 
have to be real corruption. Given the prior opinions expressed about assuming 
everything should be left as real data in this case, I wonder if we shouldn't 
just ignore the whole txn log in this case as well; the user will have the 
error messages to work from, after all. What are your thoughts about this?

> 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.0 rc1
>
>
> 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