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

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

bq. So the MAX_ATTEMPTS loop is gone totally right?
bq. Here you mean the COMMIT/ABORT record?

Right

bq. Here you mean just return the final and temporary files that we have found 
in the first sweep right, basically what we are doing at the moment?

I mean that we would apply this specific transaction log as a filter to the 
listing, as per its commit/abort flag, not worrying at all about 
presence/absence.

bq. Do we still return tmp files from the first run anyway?

Here I mean we would simply not filter the listing based on this txn log; if 
it's missing, any temporary files should have been deleted, and our clients 
have to be robust to missing files. We could post-filter our results to only 
present files if we wanted, but I'd prefer we harden our clients to missing 
files, since that's always going to be a risk.

bq. We scrub the data directories pretty early, so any left over transactions 
won't be present during startup and the listing will simply not find any txn 
logs and just return the data files we found.

I mean the startup procedure that cleans up transaction logs. This is the only 
process we require to be really paranoid, and should have a special status, 
since it's at risk of corrupting data.

bq. Actually it's true as long as TransactionLog is only used by 
LifecycleTransaction.

We should probably enforce that, by making the class package-private, 
commenting this fact, and ensuring any behaviour is accessed through LT.

> 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