[
https://issues.apache.org/jira/browse/CASSANDRA-10109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728857#comment-14728857
]
Benedict commented on CASSANDRA-10109:
--------------------------------------
bq. So what do we do with this final corrupt record then: is it "UNKNOWN",
which means transaction always in progress
It's only in progress if all of the other files are present, in which case
treating it as such seems completely safe. The worst case scenario I can see is
a transaction that's in the process of being committed, we fail to read the
commit record, and see all the old files are present, filter out the new files,
and then the old files get deleted before the client uses them. But as
discussed this is always a risk, no matter how we do things. Attempting to
parse corrupted records, on the other hand, seems a little worrisome to me.
What if it's corrupted due to disk failure mid-write, and the transaction is
actually being aborted? Incredibly unlikely, I'll grant, but there are probably
other failure scenarios.
> 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)
