[
https://issues.apache.org/jira/browse/CASSANDRA-11905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-11905:
-----------------------------------------
Status: Patch Available (was: Open)
The fix is pretty simple, we just have to grab the read order and pass it to
{{queryMemtableAndDisk}}, and that's exactly what I did for 3.0 to optimize for
minimum amount of change. On 3.7 however, I took a slightly more aggressive
approach that should hopefully protect against that kind of mistake: I removed
the {{queryMemtableAndDisk}} method that was taking an {{OpOrder.Group}},
leaving only the one taking a {{ReadExecutionController}}, which should in
itself prevent mistakenly passing a write order. But I also make a few (minor
overall) additions to {{ReadExecutionController}} so we even validate that the
controller we use has been properly taken on the right table (to typically
prevent misusing a base table {{OpOrder.Group}} to read on an index table).
|| 3.0 || 3.7 ||
| [utests|http://cassci.datastax.com/job/pcmanus-11905-3.0-testall/] |
[utests|http://cassci.datastax.com/job/pcmanus-11905-3.7-testall/] |
| [dtests|http://cassci.datastax.com/job/pcmanus-11905-3.0-dtest/] |
[dtests|http://cassci.datastax.com/job/pcmanus-11905-3.7-dtest/] |
Note that tests haven't yet run as of this writing, and I didn't started trunk
cause it's basically the same as 3.7 right now.
I'll note that since that's a fairly serious bug (probably don't reproduce
often, but could make us remove a sstable that is still being read, potentially
hard-crashing a node if things are mmapped) and since 3.6 hasn't been voted on
yet, we might want to consider including that fix.
> Index building fails to start CFS.readOrdering when reading
> -----------------------------------------------------------
>
> Key: CASSANDRA-11905
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11905
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Critical
> Fix For: 3.0.x, 3.x
>
>
> This code for indexing partition when building index in 3.0 is:
> {noformat}
> SinglePartitionReadCommand cmd =
> SinglePartitionReadCommand.fullPartitionRead(cfs.metadata,
> FBUtilities.nowInSeconds(), key);
> try (OpOrder.Group opGroup = cfs.keyspace.writeOrder.start();
> UnfilteredRowIterator partition = cmd.queryMemtableAndDisk(cfs,
> opGroup))
> {
> cfs.indexManager.indexPartition(partition, opGroup, indexes,
> cmd.nowInSec());
> }
> {noformat}
> which is clearly incorrect as the {{OpOrder}} that {{queryMemtableAndDisk}}
> expects is the one from {{cfs.readOrdering}}, not the one for writes on the
> keyspace.
> This wasn't a problem prior to 3.0 as the similar code was using the pager,
> which ended up properly taking the read {{OpOrder}} internally but I messed
> this up in CASSANDRA-8099.
> Thanks to [~Stefania] for pointing that out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
