cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3430) Break Big Compaction Lock apart
Date Tue, 19 Mar 2013 10:57:16 GMT

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

Sylvain Lebresne commented on CASSANDRA-3430:
---------------------------------------------

bq. This shouldn't be necessary for correctness

Actually, I think it is. Using DataTracker.getCompacting doesn't fix the race I was talking
about (though it reduces the window for the race somewhat). Because (again, without the synchronized),
you can still have a task that is between the isActive check and the markCompacting call while
runWithCompactionsDisabled run. So this task could mark the sstable compacting after runWithCompactionsDisabled
has done his checks and is going to call the Callable. Even if said compaction will get cancelled,
it might still prevent a major compaction to compact some sstable for instance.

That being said, I do believe the synchronzation of pause and getNextBackgroundTask fixes
it (and indeed makes it easier to reason about). Maybe we'd want a comment reminding us of
that?

However, with that last version I have LeveledCompactionStrategyTest and StreamingTransferTest
that timeout, while they don't without. I checked, and they do pass with the timeout raised,
so they are not blocked per-se. However, while StreamingTransferTest takes 20 seconds on my
machine on cassandra-1.2, it completed in 335 seconds on 3430-4, so something is wrong. From
jconsole, it just seems it was taking an awful lot of time applying the mutations in testRandomSSTableTransfer
(LeveledCompactionStrategyTest also completed with a higher timeout and went from 23s in 1.2
to 61s with 3430-4).

As a side note, forgot to mention in my previous comment that in CM.interruptCompactionFor,
the new interruptRepairs boolean is added as a parameter but never used in the method (and
the method javadoc still pretends it's doing some waiting :)).

                
> Break Big Compaction Lock apart
> -------------------------------
>
>                 Key: CASSANDRA-3430
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3430
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Minor
>              Labels: compaction
>             Fix For: 2.0
>
>         Attachments: 3430-1.0.txt, 3430-1.1.txt, 3430-v2.txt, 3430-v3.txt
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message