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 Thu, 22 May 2014 22:43:03 GMT


Benedict commented on CASSANDRA-6572:

bq. Added a small optimisation, BBs used for creating the data array in QR#allocate(String)
are now recycled where the largest buffer created is stored, when a bigger one is required
it gets allocated and replaces the older one.

Instead of this, it is better to simply write the data directly to the QQ; you can wrap the
appropriate range in a ByteBuffer and return the ByteBuffer from the allocate() method (null
indicating there wasn't enough room)

# Your QQ recycling code is broken. This should only be performed by the flushing thread,
once we know the flush has finished, or if we fail to swap the QQ (i.e. if line 85 returns
# you should use getAndSet() on line 87, the result being the value pos should take
# I wouldn't introduce a special interface for AccessibleKeyspace, and I wouldn't consider
batch statements to be magically safe. Batch mutations have a set of CFs they maintain of
their modifications, you can check these for system keyspaces, and if _any_ are present avoid
logging the whole batch. We don't want to stuff up the system keyspaces somehow on replay.
I would suggest potentially introducing a boolean method to CQLStatement that returns true
if the statement is safe to log; there are a small number of abstract classes that would need
implementations (AuthStmt, CFStmt, ModStmt)

It occurs to me, on top of logging the thread id as Jonathan suggests, we also need to log
the client session id as well, else "use" statements could cause absolute chaos. This means
we may need to log disconnect of client sessions as well as a special record to permit state

> 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