[
https://issues.apache.org/jira/browse/CASSANDRA-13363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128589#comment-16128589
]
Sam Tunnicliffe commented on CASSANDRA-13363:
---------------------------------------------
[~zhaoyan]
bq.the index is designed as lazy load , load once , and not set at construction
time, so I think its load may be very hard
This was true at one point, but in CASSANDRA-10215 that changed so that we
could avoid performing the lookup to determine which index to use multiple
times during the query execution. That patch was didn't really go far enough
though (which is my bad), as [~iamaleksey] points out there are several
shortcomings with it; it shouldn't be using {{Optional}}, the field should be
final and so forth.
However, there is also another issue at play here. Queries with secondary
indexes were historically always executed as partition range queries, as their
results can span multiple partitions. Even when a partition key restriction is
present, we convert the query to a range read command and the index field *is*
always set at construction time (in {{SelectStatement::getRangeCommand}}), so
it is never lazily loaded. There is a related bug though, CASSANDRA-11617,
which causes queries with a partition key restriction && a custom index
expression to be executed as single partition read command. When these are
created (in {{SelectStatement::getSliceCommands}}), we *don't* ensure that the
index is loaded at construction time (because we weren't expecting any query
with an index to generate such a command). So in this case, the lazy loading
happens when the command is executed locally, leading to the race causing the
serialization issues you're seeing.
bq.What about removing index from the readcommand‘s serialize?
This would partially undo CASSANDRA-10215 and require each replica to figure
out which index to use, which is potentially expensive (relatively) and
unnecesary.
So to cut a long story short, [~iamaleksey]'s diagnosis and solution are
correct, making sure that where an index is appropriate it gets set on the read
command during construction is the right way to fix this. The more thorough
refactoring, which should have been done in CASSANDRA-10215, is also a good
idea.
> java.lang.ArrayIndexOutOfBoundsException: null
> ----------------------------------------------
>
> Key: CASSANDRA-13363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13363
> Project: Cassandra
> Issue Type: Bug
> Environment: CentOS 6, Cassandra 3.10
> Reporter: Artem Rokhin
> Assignee: zhaoyan
> Priority: Critical
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Constantly see this error in the log without any additional information or a
> stack trace.
> {code}
> Exception in thread Thread[MessagingService-Incoming-/10.0.1.26,5,main]
> {code}
> {code}
> java.lang.ArrayIndexOutOfBoundsException: null
> {code}
> Logger: org.apache.cassandra.service.CassandraDaemon
> Thrdead: MessagingService-Incoming-/10.0.1.12
> Method: uncaughtException
> File: CassandraDaemon.java
> Line: 229
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
