Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 14 Oct 2015 21:18:06 +0000 (UTC)
From: "Ariel Weisberg (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12901570.1443615261000.41636.1444857486300@Atlassian.JIRA>
In-Reply-To: <JIRA.12901570.1443615261000@Atlassian.JIRA>
References: <JIRA.12901570.1443615261000@Atlassian.JIRA>
 <JIRA.12901570.1443615261139@arcas>
Subject: [jira] [Commented] (CASSANDRA-10421) Potential issue with
 LogTransaction as it only checks in a single directory for files
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Ariel Weisberg commented on CASSANDRA-10421:
--------------------------------------------

I think this does what we talked about where generally speaking if anything goes wrong LogFile.verify will return false and then LogTransaction.removeUnfinishedLeftovers won't do anything. The only attempt we make to be a hero is when it's just the last record that has minor disagreement that indicates missing or partial commit in one file.

bq. Most likely a corrupt sstable exception will halt start-up depending on disk failure policy.
Would this be what happens? We don't validate checksums of entire files at startup. Or is there a flag somewhere else that allows us to know which files are incomplete?

I just noticed that it seems to open each file every time to append a record? Since each record is only one table seems like that could end up being a little slow although most transactions won't touch that many tables so maybe it's not an issue. It syncs the folder descriptor every time it writes to a file? Seems like the folder only needs to be synced once when the file is created or is that done as a side effect for other operations? Is the intent to sync the file for each record and not the directory?

LogFile.deleteRecords() applies records of a specific type? Just based on the name I thought it was modifying the log contents somehow. Seems like it and the chain of delegating calls should be named something else like applyRecords.

Can you add a comment that the LogFile.records is a LinkedHashSet because it must be order preserving? When I saw it floating around without the LHS type and just Set I was confused. Wouldn't want to it change into something that is not order preserving later on.

> 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 rc2
>
>
> 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)