[
https://issues.apache.org/jira/browse/CASSANDRA-11043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe resolved CASSANDRA-11043.
-----------------------------------------
Resolution: Fixed
Reproduced In: (was: 3.0.5, 3.5)
The problem here is that queries involving indexes should always be executed as
a {{PartitionRangeReadCommand}}. When the statement restrictions are processed,
we don't set the {{usesSecondaryIndexing}} flag if custom expressions are
present, which we should do. If the flag were set, then we'd never get into the
situation described here. We encountered a similar problem on CASSANDRA-11310
recently, and as I mentioned in [the comment
there|https://issues.apache.org/jira/browse/CASSANDRA-11310?focusedCommentId=15245922&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15245922],
although we could (and most likely will) move to enable 2i usage on single
partition reads, we need to do that in controlled way to ensure we don't
violate an assumptions being made about the read command. In the meantime, I've
opened CASSANDRA-11617 to fix the bug with custom expressions.
> Secondary indexes doesn't properly validate custom expressions
> --------------------------------------------------------------
>
> Key: CASSANDRA-11043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11043
> Project: Cassandra
> Issue Type: Bug
> Components: CQL, Local Write-Read Paths
> Reporter: Andrés de la Peña
> Assignee: Sam Tunnicliffe
> Labels: 2i, index, validation
> Fix For: 3.4, 3.0.4
>
> Attachments: test-index.zip
>
>
> It seems that
> [CASSANDRA-7575|https://issues.apache.org/jira/browse/CASSANDRA-7575] is
> broken in Cassandra 3.x. As stated in the secondary indexes' API
> documentation, custom index implementations should perform any validation of
> query expressions at {{Index#searcherFor(ReadCommand)}}, throwing an
> {{InvalidRequestException}} if the expressions are not valid. I assume these
> validation errors should produce an {{InvalidRequest}} error on cqlsh, or
> raise an {{InvalidQueryException}} on Java driver. However, when
> {{Index#searcherFor(ReadCommand)}} throws its {{InvalidRequestException}}, I
> get this cqlsh output:
> {noformat}
> Traceback (most recent call last):
> File "bin/cqlsh.py", line 1246, in perform_simple_statement
> result = future.result()
> File
> "/Users/adelapena/stratio/platform/src/cassandra-3.2.1/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py",
> line 3122, in result
> raise self._final_exception
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation
> failed - received 0 responses and 1 failures" info={'failures': 1,
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {noformat}
> I attach a dummy index implementation to reproduce the error:
> {noformat}
> CREATE KEYSPACE test with replication = {'class' : 'SimpleStrategy',
> 'replication_factor' : '1' };
> CREATE TABLE test.test (id int PRIMARY KEY, value varchar);
> CREATE CUSTOM INDEX test_index ON test.test() USING 'com.stratio.TestIndex';
> SELECT * FROM test.test WHERE expr(test_index,'ok');
> SELECT * FROM test.test WHERE expr(test_index,'error');
> {noformat}
> This is specially problematic when using Cassandra Java Driver, because one
> of these server exceptions can produce subsequent queries fail (even if they
> are valid) with a no host available exception.
> Maybe the validation method added with
> [CASSANDRA-7575|https://issues.apache.org/jira/browse/CASSANDRA-7575] should
> be restored, unless there is a way to properly manage the exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
