[
https://issues.apache.org/jira/browse/CASSANDRA-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14312765#comment-14312765
]
Joshua McKenzie commented on CASSANDRA-8766:
--------------------------------------------
bq. but we should ensure we never "open early' unless we really are opening
early
While this hasn't proven to be an issue on other platforms I agree - it
introduces unnecessary complexity and isn't particularly honest.
bq. It seems like the cleanup isn't working correctly
Agreed - we should probably hammer out the why of this rather than further
complicating SSTRW.
bq. The only way to ensure it can work without interruption is to use a hard
link
I'm not clear on why we couldn't just use the original TMP while it's written
rather than a hard-link to it - there's probably something obvious I'm missing.
I agree on the "don't change the paradigm until 3.0" regardless.
bq. I have the exact opposite view...
Fair enough - I wasn't that familiar with this code in its earlier incarnation
so it's certainly possible the other approach afforded less clear code.
> 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)
