cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5241) Fix forceBlockingFlush
Date Sat, 16 Feb 2013 20:19:12 GMT

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

Brandon Williams commented on CASSANDRA-5241:
---------------------------------------------

I encountered the looping once before 5151 was reverted, but also before this was committed.
 I haven't seen it since so I'm inclined to think it was 5151.
                
> Fix forceBlockingFlush
> ----------------------
>
>                 Key: CASSANDRA-5241
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5241
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Marcus Eriksson
>             Fix For: 1.2.2
>
>         Attachments: 0001-CASSANDRA-5241-wait-for-flushing-to-complete-before-.patch
>
>
> ForceBlockingFlush doesn't guarantee that after the call, every that the thread has written
prior to the call will be fully flushed. At least not in the case of concurrent flushes, because
if 2 threads flush roughly at the same time, one will have it's forceBlockingFlush call return
immediately because the memtable will be clean (even though some of the thread writes may
have not be fully flushed yet).
> I think this is very fragile and make it easy to have hard to find races and so we should
fix it. Typically a forceFlush that see a clean memtable could submit a dummy task in the
postFlushExecutor and wait for that.

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