cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10421) Potential issue with LogTransaction as it only checks in a single directory for files
Date Fri, 23 Oct 2015 00:43:27 GMT


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:

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:
>             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()|]}}
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
> cc [~Stefania]

This message was sent by Atlassian JIRA

View raw message