[
https://issues.apache.org/jira/browse/CASSANDRA-10421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14970203#comment-14970203
]
Stefania commented on CASSANDRA-10421:
--------------------------------------
bq. Can you update the Windows branch so we can see how it does on Windows
before committing?
Windows branch updated and jobs are scheduled:
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10421-windows-3.0-utest_win32/
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10421-windows-3.0-dtest_win32/
bq. The first was the bad assumption in LogRecord.getExistingFiles, which
caused it to throw, which exposed the missing exception handling in Memtable
(leaking the transaction) which exposed the fact that leaked transactions when
cleaned up by the garbage collector fail to cleanup due to an incorrect
assertion.
Your 100% correct. This once again highlights how beneficial testing this
component with failure injection would be. Another example is CASSANDRA-10538.
bq. So when you fixed the assertion you call abort. What happens if a
transaction commits, but isn't closed and that leads to the commit followed by
an abort? Or is closing the only way to get a commit?
If a transaction commits then it is completed and we will not call abort. I
think the only risk is if we throw an exception in the commit operation _after
writing to file and before updating the records in memory_, in which case we
would end up with a corrupt file as you said. But after CASSANDRA-10538 is
applied, we will update the records just after writing to file, so this should
be safe.
> Potential issue with LogTransaction as it only checks in a single directory
> for files
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-10421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10421
> Project: Cassandra
> Issue Type: Bug
> Reporter: Marcus Eriksson
> Assignee: Stefania
> Priority: Blocker
> Fix For: 3.0.0
>
>
> When creating a new LogTransaction we try to create the new logfile in the
> same directory as the one we are writing to, but as we use
> {{[directories.getDirectoryForNewSSTables()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogTransaction.java#L125]}}
> this might end up in "any" of the configured data directories. If it does,
> we will not be able to clean up leftovers as we check for files in the same
> directory as the logfile was created:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogRecord.java#L163
> cc [~Stefania]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
