[
https://issues.apache.org/jira/browse/CASSANDRA-10109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728662#comment-14728662
]
Stefania commented on CASSANDRA-10109:
--------------------------------------
The four failing unit tests are due to a change in behavior introduced by the
simplifications when parsing records and checksums. Whereas before we would try
very hard to parse the record, parsing the type even when everything else was
corrupt, now we give up immediately. This means that the tests with a corrupt
final commit record (the ones failing) previously had a transaction considered
completed but now have a transaction considered in progress (because the commit
record is of type unknown now). So the decision is really what to do if we
cannot parse the checksum or part of the record, try to parse the type or not?
In terms of refactoring I am not opposed:
bq. Combined both atomic/non-atomic DirectoryStream paths
I left them separated just because I followed to the letter your algo, so OK to
have them together, we just scan the directory twice on Linux but the code is
cleaner and easier to test.
bq. Split out all of the inner classes into their own files
I think this was long overdue. Should we have a dedicated package inside
lifecycle?
bq. Merged the TransactionFile and TransactionData classes into LogFile, and
moved the resource management out into the TransactionLog (which is all that
needs it)
It made sense to have them separate when we had two log files, now that we have
only one log file, then the separation doesn't make much sense any longer.
bq. Merged the checksum portion of the log file lines with the Record
functionality, so all parsing is in one place
bq. Moved all of the validation logic into one place, including checksum
verification
OK - but see comment above re failing tests.
bq. Made validation throw no exceptions, only log and return the result, for
consideration of the caller
Sounds good.
bq. Made extensive use of streams where possible and clarity was helped, since
these are all low traffic codepaths.
That's fine, the code is more readable. I just need to get used to using the
stream API more extensively.
I can fix up the remaining tests, just let me know if a final corrupt record
should be considered unknown or commit/abort, etc.
> 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)
