[
https://issues.apache.org/jira/browse/CASSANDRA-5779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-5779.
-----------------------------------------
Resolution: Fixed
Fix Version/s: 1.2.7
Assignee: Sylvain Lebresne
bq. However, I suppose that NPE is not good anyway, I'd rather prefer to get
"table doesn't exist" message
I agree with you in theory. Ideally, we'd want to throw a meaningful error
message for the query. However, the problem here is that you dropped the
keyspace concurrently of inserting in that keyspace. And making sure we catch
such race properly in all cases would, while probably possible, be prohibitive
performance wise for queries (and distribution makes this even worst). It's
just not worse it.
So at the end of the day, concurrently dropping a table/keyspace while
requesting it (reads or writes) is just not supported you should synchonize
client side to avoid it.
For what it's worth, I've committed a small change (commit
86a077a190a1cec89112b9f1fd991f0fe06d2423) so that this case shouldn't happen
anymore. Instead, in that same situation, an assertion error would get
triggered that should at least have a more meaningful error message. And so
I'll consider this "fixed". But:
# this will still not be an error returned to the client. So really, you should
synchronize client side.
# I do not pretend that a race between a keyspace drop and inserts can't yield
a NPE anywhere else in the code.
> sudden NPE while accessing Cassandra with CQL driver
> ----------------------------------------------------
>
> Key: CASSANDRA-5779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5779
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.6
> Reporter: Irina Chernushina
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 1.2.7
>
>
> java.lang.NullPointerException at
> org.apache.cassandra.db.RowMutation.addOrGet(RowMutation.java:153)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement.mutationForKey(UpdateStatement.java:216)
> at
> org.apache.cassandra.cql3.statements.UpdateStatement.getMutations(UpdateStatement.java:133)
> at
> org.apache.cassandra.cql3.statements.BatchStatement.getMutations(BatchStatement.java:99)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:118)
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:128)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:87)
> at
> org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:287)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
> at
> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:793)
> at
> org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:45)
> at
> org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:69)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
