[jira] [Commented] (CASSANDRA-8766) SSTableRewriter opens all sstables as early before completing the compaction

["Joshua McKenzie (JIRA)" <ji...@apache.org>]

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

Joshua McKenzie commented on CASSANDRA-8766:
--------------------------------------------

Renaming is our latest pain point on Windows - the current algorithm's expectation of 1: Open SSTR, 2: finish() on writer and rename it (while reader is open), then 3: open final SSTR and replace will fail on step 2 on Windows (and currently does - see CASSANDRA-8535).  This works on trunk but fails on 2.1 and will fail once we get back to mmap'ed on the read path on Windows.

My current thought is for 8535 to work around the problem by having a code-path specific to Windows where we truly bypass the early re-open behavior entirely, and down the road I can convert the check for isWindows to isWindows + mmap'ed index files (mmap'ed reader would again break early re-open on Windows).  It's little extra complexity to have a branching path for Windows however since we're looking specifically to stabilize this code in 2.1 it made sense to me to keep it completely independent.

One thing I was never really clear on: w/regards to the early re-open mechanics, is there a reason we create hard-links to the SSTable we're writing and rely on the file-system (renaming) for tracking which files are successfully compacted (vs. say, sharing the original handle and using system tables or some other tracking mechanism)?  Both of those design choices make the early re-open mechanic pretty dicey on Windows due to the pickiness surrounding those operations and the fact that we're actively using those files during the time window we're trying those ops.

On a related note (but likely different ticket) - I get the feeling we could better separate concerns w/how we handle FinishTypes in SSTableWriter.  Currently the casing in finish() and close() feels like we're trying to shove multiple branching logical paths into a single method which tends towards brittleness and is also harder to reason about than is necessary.

> SSTableRewriter opens all sstables as early before completing the compaction
> ----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-8766
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8766
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Benedict
>            Priority: Minor
>             Fix For: 2.1.4
>
>
> In CASSANDRA-8320, we made the rewriter call switchWriter() inside of finish(); in CASSANDRA-8124 was made switchWriter() open its data as EARLY. This combination means we no longer honour disabling of early opening, which is potentially a problem on windows for the deletion of the contents (which is why we disable early opening on Windows).
> I've commented on CASSANDRA-8124, as I suspect I'm missing something about this. Although I have no doubt the old behaviour of opening as TMP file reduced the window for problems, and opening as TMPLINK now does the same, it's not entirely clear to me its the right fix (though it may be) since we shouldn't be susceptible to this window anyway? Either way, we perhaps need to come up with something else, because this could potentially break windows support. Perhaps if we simply did not swap in the TMPLINK file so that it never actually get mapped, it would perhaps be enough. [~JoshuaMcKenzie], WDYT?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)