[ 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org