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

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

bq. It would break the SegmentedFile contract
Ah, there it is.  Yeah - I wasn't looking at that component as a potential 
relief for our pain on Windows - rather just something that nagged at me I 
hadn't quite worked out the reasoning for.  Thanks for clearing that up!

Back to the topic at hand:
bq. Perhaps if we simply did not swap in the TMPLINK file so that it never 
actually get mapped, it would perhaps be enough.
I believe the specific change to relying on switchWriter in finish from 
CASSANDRA-8320 should probably be modified to something similar to it's 
previous incarnation but with respect to the abort issue brought up in 8320.  
That would make 8535 unnecessary and potentially keep us on a single code-path 
which we all strongly prefer.

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

Reply via email to