[
https://issues.apache.org/jira/browse/CASSANDRA-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14005147#comment-14005147
]
Benedict commented on CASSANDRA-6572:
-------------------------------------
bq. Why do we want to store completed QQs onto the CLQ used for storing failed
pre-flush CAS
Because they're both empty and we can reuse them (resetting their position to
zero) without allocating new QQs. It's not a failedFlushQueue, it's a recycled
queue
Some comments:
# In QQ.allocate, no need to check pos + size > 0; just assert that pos > 0 on
insert (pos < 0 would break even with your extra check)
# Do not compareAndSet the first queue in an assert; if assertions are disabled
it won't happen
# No need to define q outside of your loop
# Need to compareAndSet() the QQ position to the end of the queue before
flushing; should do this after CASing q to a new QQ, so that you have exclusive
access for flushing q, so the position you get is definitely the end position.
# It's a little neater to have your position >= 0 clause first, so you can
simply return, and don't need a large nested if with a continue at the end
# Looks like runFlush() is no longer needed
# QQ.limit is unnecessary
# QQ.logPosition should be final
> Workload recording / playback
> -----------------------------
>
> Key: CASSANDRA-6572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6572
> Project: Cassandra
> Issue Type: New Feature
> Components: Core, Tools
> Reporter: Jonathan Ellis
> Assignee: Lyuben Todorov
> Fix For: 2.1.1
>
> Attachments: 6572-trunk.diff
>
>
> "Write sample mode" gets us part way to testing new versions against a real
> world workload, but we need an easy way to test the query side as well.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
