cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Javier Canillas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CASSANDRA-1379) Uncached row reads may block cached reads
Date Tue, 18 Jan 2011 01:56:45 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Javier Canillas updated CASSANDRA-1379:
---------------------------------------

    Attachment: CASSANDRA-1379.patch

This issue has been around my head for some time and since we are using Cassandra on live
environment (not exactly 0.7 version) I have taken the time to make a patch for you to check.
Here you will find some roadmap of my change:

Since Table.getRow was checking if the asked Key was in the RowCache before going directly
into the Memtables and SSTables, I have made another method called getCachedRow that only
checks for the key on the RowCache. If its not there, then a null object (actually a Row.Cf
= null) is returned. If you see the code, you will notice that I didn't remove the Cache check
on the Table.getRow since I prefer a double check on cache, than a second miss if, for some
reason, someone put that row on cache after first check.

Getting that in mind, I have added another public method to ReadCommand and implemented on
SliceByNamesReadCommand and SliceFromReadCommand. This new method is actually only calling
the Table.getCachedRow instead of Table.getRow.

Doing so, now I went straight to see ReadVerbHandler, and I cloned it for a new ReadCacheVerbHandler
(then I turned ReadVerbHandler into an abstract class and created a ReadPhyisicalVerbHandler
to avoid duplicate code). This new class (ReadCacheVerbHandler) will call the ReadCommand.getCachedRow,
if this method returns a Row with cf equals to null, then the command must be forwarded to
another Stage in order to fulfill the requirements by making a physical read. This new stage
was named PHYSICAL_READ and a new verb (PHYSICAL_READ) was created. The new stage was actually
cloned from READ Stage (please check if this stage needs further tunning). 
In order to be able to manipulate the original message to change the Verb, ReadCommand.makeReadMessage
was changed and extended to support overrides on messageId and Verb itself.
So, after getting an empty result on a cache search, the read command is forwarded into the
PHYSICAL_READ stage (freeing a READ thread), and it is the last one that actually respond
the row; otherwise, the cached row is returned.

Sorry for the large response and my bad english, I tried to explain the main idea, but you
probably will understand all this mechanism by inspecting the code.

Long life to Cassandra!

> Uncached row reads may block cached reads
> -----------------------------------------
>
>                 Key: CASSANDRA-1379
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1379
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: David King
>            Priority: Minor
>             Fix For: 0.7.1
>
>         Attachments: CASSANDRA-1379.patch
>
>
> The cap on the number of concurrent reads appears to cap the *total* number of concurrent
reads instead of just capping the reads that are bound for disk. That is, given N concurrent
readers if all of them are busy waiting on disk, even reads that can be served from the row
cache will block waiting for them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message