[
https://issues.apache.org/jira/browse/CASSANDRA-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858007#action_12858007
]
Ted Zlatanov commented on CASSANDRA-995:
----------------------------------------
My complete schema, although only Status and Property are used. Sorry I edited
the original but it was not substantially different.
./cassidy.pl -server X -port 9170 -keyspace system 'kdefine HB3-prod
org.apache.cassandra.locator.RackUnawareStrategy 2
org.apache.cassandra.locator.EndPointSnitch'
./cassidy.pl -server X -port 9170 -keyspace HB3-prod 'fdefine Status Super
LongType BytesType comment=statuschanges,row_cache_size=0,key_cache_size=20000'
./cassidy.pl -server X -port 9170 -keyspace HB3-prod 'fdefine Property Super
LongType BytesType comment=statuschanges,row_cache_size=0,key_cache_size=20000'
./cassidy.pl -server X -port 9170 -keyspace HB3-prod 'fdefine Analysis Super
LongType BytesType comment=statuschanges,row_cache_size=0,key_cache_size=20000'
./cassidy.pl -server X -port 9170 -keyspace HB3-prod 'fdefine Relationships
Super LongType BytesType
comment=statuschanges,row_cache_size=0,key_cache_size=20000'
./cassidy.pl -server X -port 9170 -keyspace HB3-prod 'fdefine Knowledge Super
LongType BytesType comment=statuschanges,row_cache_size=0,key_cache_size=20000'
./cassidy.pl -server X -port 9170 -keyspace system 'kdefine CM
org.apache.cassandra.locator.RackUnawareStrategy 2
org.apache.cassandra.locator.EndPointSnitch'
./cassidy.pl -server X -port 9170 -keyspace CM 'fdefine Inventory Super
LongType BytesType comment=statuschanges,row_cache_size=0,key_cache_size=20000'
When I tried to trigger the error manually with cassidy with just a few inserts
like this (the below inserts test=abc into SC 0 in the Status CF):
./cassidy.pl -server X -port 9170 -keyspace HB3-prod 'ins Status testkey 0
test=abc'
./cassidy.pl -server X -port 9170 -keyspace HB3-prod 'get Status testkey 0'
the problem doesn't happen. I don't know how much data causes it. My typical
writes that trigger this, over a minute, are about 20-30 columns per
supercolumn, about 2500 keys, about 5 SCs per key. I can reliably trigger it
with a one-minute population run.
Thanks and I hope this is enough information to replicate the bug. If not I'll
try to give you more including a better test case.
> restarting node crashes with NPE when, while replaying the commitlog, the
> cfMetaData is requested
> -------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-995
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7
> Environment: SVN rev 935070
> Reporter: Ted Zlatanov
> Assignee: Gary Dusbabek
> Priority: Critical
> Fix For: 0.7
>
> Attachments: crashlog-995
>
>
> Removing the commitlog directory completely fixes this. I can reliably
> reproduce it by 1) starting and configuring a schema with one keyspace, one
> super CF with LongType supercolumns; 2) inserting data; 3) shutting down and
> restarting the node.
> Here's my schema expressed in cassidy.pl, should be obvious what the
> parameters are:
> ./cassidy.pl -server X -port Y -keyspace system 'kdefine test
> org.apache.cassandra.locator.RackUnawareStrategy 2
> org.apache.cassandra.locator.EndPointSnitch'
> ./cassidy.pl -server X -port Y -keyspace test 'fdefine Status Super LongType
> BytesType comment=statuschanges,row_cache_size=0,key_cache_size=20000'
> The problem seems to be related to CASSANDRA-44 as it happens when the CF
> metadata is requested but I don't know what's causing it.
> 10/04/16 15:25:11 INFO commitlog.CommitLog: Replaying
> /home/cassandra/commitlog/CommitLog-1271449410100.log,
> /home/cassandra/commitlog/CommitLog-1271449378151.log,
> /home/cassandra/commitlog/CommitLog-1271449415800.log
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:160)
> Caused by: java.lang.NullPointerException
> at org.apache.cassandra.db.Table.<init>(Table.java:261)
> at org.apache.cassandra.db.Table.open(Table.java:102)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:233)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:172)
> at
> org.apache.cassandra.thrift.CassandraDaemon.setup(CassandraDaemon.java:104)
> at
> org.apache.cassandra.thrift.CassandraDaemon.init(CassandraDaemon.java:151)
> ... 5 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
