cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "tzach (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9628) "Unknown keyspace system_traces" exception when using nodetool on a new cluster
Date Tue, 23 Jun 2015 05:59:01 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14597215#comment-14597215
] 

tzach commented on CASSANDRA-9628:
----------------------------------

Retry with 2.1.6 and I see the same results.
More details on my setup:
* EC2, m3.large servers, with ubuntu 14.04
* Oracle Java 7 from ppa:webupd8team/java
* Installing Cassandra from deb http://debian.datastax.com/community stable main
* A cluster of two servers, both are seeds

When running nodetool status right after install I get (on both server)
{code}
ubuntu@ip-172-31-31-37:~$ nodetool status
error: Unknown keyspace system_traces
-- StackTrace --
java.lang.AssertionError: Unknown keyspace system_traces
	at org.apache.cassandra.db.Keyspace.<init>(Keyspace.java:272)
	at org.apache.cassandra.db.Keyspace.open(Keyspace.java:121)
	at org.apache.cassandra.db.Keyspace.open(Keyspace.java:98)
	at org.apache.cassandra.service.StorageService.getRangesForEndpoint(StorageService.java:3046)
	at org.apache.cassandra.service.StorageService.effectiveOwnership(StorageService.java:3954)
	at org.apache.cassandra.service.StorageService.effectiveOwnership(StorageService.java:175)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
	at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
	at sun.rmi.transport.Transport$2.run(Transport.java:202)
	at sun.rmi.transport.Transport$2.run(Transport.java:199)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:198)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:567)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.access$400(TCPTransport.java:619)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:684)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:681)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:681)
	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:745)
{code}

To bypass I start a cqlsh, and input what ever:
{code}
cqlsh 172.31.31.37
Connected to CassandraCluster at 172.31.31.37:9042.
[cqlsh 5.0.1 | Cassandra 2.1.6 | CQL spec 3.2.0 | Native protocol v3]
Use HELP for help.
cqlsh>  create keyspace temp WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor'
: 2 };
cqlsh> exit
{code}

After that, nodetool works fine:
{code}
$ nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address       Load       Tokens  Owns    Host ID                               Rack
UN  172.31.31.37  111.7 KB   256     ?       f52193fa-8937-44f8-ab06-b6cf4024544b  rack1
UN  172.31.31.38  107.04 KB  256     ?       518a2fa3-27c9-4643-acae-6f78b2ff2613  rack1

Note: Non-system keyspaces don't have the same replication settings, effective ownership information
is meaningless
{code}


> "Unknown keyspace system_traces" exception when using nodetool on a new cluster
> -------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-9628
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9628
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: tzach
>            Priority: Minor
>
> When creating a new cluster from scratch,  nodetool status fails on system_traces as
follow
> {code}
> $ nodetool status
> error: Unknown keyspace system_traces
> -- StackTrace --
> java.lang.AssertionError: Unknown keyspace system_traces
> 	at org.apache.cassandra.db.Keyspace.<init>(Keyspace.java:270)
> 	at org.apache.cassandra.db.Keyspace.open(Keyspace.java:119)
> 	at org.apache.cassandra.db.Keyspace.open(Keyspace.java:96)
> ...
> {code}
> the problem disappear when creating an empty keyspace
> {code}
> cqlsh> create keyspace temp WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor'
: 2 };
> {code}
> My guess is system_traces initialization complete only after any data insertion.
> Before it does, any attempt to read  from it either from nodetool, cqlsh or streaming
to a new node will fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message