[
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
