[jira] [Updated] (CASSANDRA-1379) Uncached row reads may block cached reads

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

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

Jonathan Ellis updated CASSANDRA-1379:
--------------------------------------

    Fix Version/s:     (was: 0.8.3)

bq. what branch was the patch against originally?

It would have been trunk-as-of-shortly-after-0.7-release, so it would probably come closest to applying to the 0.7 branch today.

bq. shouldn't the fix version be the next major release for a change this large?

Agreed.

I've been trying to figure out why this ticket makes me uncomfortable, and I think I've figured it out: assuming each client has identical request distribution, which is the case for almost all applications, pulling the cache check out to a separate stage won't actually help clients progress any more when you are i/o bound, since once they issue a request-not-in-cache they have to wait for the physical read stage anyway.

So while there's a certain ideological purity of having cache check on a separate stage, in reality it doesn't actually help you, while still adding a fair amount of complexity to the read path.

> 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
>            Assignee: Javier Canillas
>            Priority: Minor
>         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.
For more information on JIRA, see: http://www.atlassian.com/software/jira