cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6572) Workload recording / playback
Date Wed, 21 May 2014 19:52:40 GMT


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

View raw message