[
https://issues.apache.org/jira/browse/CASSANDRA-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438996#comment-13438996
]
Jonathan Ellis commented on CASSANDRA-4533:
-------------------------------------------
Hmm, I don't think this quite works because it still means we can skip saving
cache for CF X when CF Y is being flushed.
I think the problem this code is trying to solve, over a basic executor +
queue, is multiple tasks for X getting queued up while (say) compaction is
sucking a lot of i/o, then firing off those cache-save tasks for X faster than
the defined saving period when it speeds up.
I guess we could make it a Pair<CF, CacheType>?
TBH this is probably premature optimization, if your cache period is so
frequent that multiple queued tasks is a problem, then you should just fix
that. I'd be okay with just ripping this out. Alternatively, we could have
the task check to see if the last-saved cache is older than M minutes before
overwriting it, similar to how normal background compaction submissions are a
no-op if it turns out there's nothing to do by the time we execute the task.
> Multithreaded cache saving can skip caches
> ------------------------------------------
>
> Key: CASSANDRA-4533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4533
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.8.0
> Reporter: Zhu Han
> Assignee: Yuki Morishita
> Priority: Trivial
> Fix For: 1.1.5
>
> Attachments: 4533-1.1.txt
>
>
> Cassandra flushes the key and row cache to disk periodically. It also uses a
> atomic flag in flushInProgress to enforce single cache writer at any time.
> However, the cache saving task could be submitted to CompactionManager
> concurrently, as long as the number of worker thread in CompactionManager is
> larger than 1.
> Due to the effect of above atomic flag, only one cache will be written out to
> disk. Other writer are cancelled when the flag is true.
> I observe the situation in Cassandra 1.0. If nothing is changed, the problem
> should remain in Cassandra 1.1, either.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
