[jira] [Created] (CASSANDRA-14016) Doc of read_repair_chance and dclocal_read_repair_chance default values is wrong
tzach created CASSANDRA-14016:
-
Summary: Doc of read_repair_chance and dclocal_read_repair_chance
default values is wrong
Key: CASSANDRA-14016
URL: https://issues.apache.org/jira/browse/CASSANDRA-14016
Project: Cassandra
Issue Type: Bug
Components: Documentation and Website
Reporter: tzach
Priority: Trivial
In the documentation, default values for
read_repair_chance is 0.1
dclocal_read_repair_chance is 0.0
source: http://cassandra.apache.org/doc/latest/cql/ddl.html#other-table-options
In the code, the default values are the other way around
{quote}
public static final double DEFAULT_READ_REPAIR_CHANCE = 0.0;
public static final double DEFAULT_DCLOCAL_READ_REPAIR_CHANCE = 0.1;
{quote}
source:
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/TableParams.java#L63-L64
--
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
[jira] [Commented] (CASSANDRA-9628) "Unknown keyspace system_traces" exception when using nodetool on a new cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15043770#comment-15043770
]
tzach commented on CASSANDRA-9628:
--
Just tried, and failed to reproduce the issue so I cant give an accurate
answer.
As far as I remember the issue was not limited to the first few minutes.
> "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: Tools
>Reporter: tzach
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 2.1.x
>
>
> 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.(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)
[jira] [Commented] (CASSANDRA-8099) Refactor and modernize the storage engine
[
https://issues.apache.org/jira/browse/CASSANDRA-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14624538#comment-14624538
]
tzach commented on CASSANDRA-8099:
--
Thanks Sylvain, I missed that.
Refactor and modernize the storage engine
-
Key: CASSANDRA-8099
URL: https://issues.apache.org/jira/browse/CASSANDRA-8099
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Fix For: 3.0 beta 1
Attachments: 8099-nit
The current storage engine (which for this ticket I'll loosely define as the
code implementing the read/write path) is suffering from old age. One of the
main problem is that the only structure it deals with is the cell, which
completely ignores the more high level CQL structure that groups cell into
(CQL) rows.
This leads to many inefficiencies, like the fact that during a reads we have
to group cells multiple times (to count on replica, then to count on the
coordinator, then to produce the CQL resultset) because we forget about the
grouping right away each time (so lots of useless cell names comparisons in
particular). But outside inefficiencies, having to manually recreate the CQL
structure every time we need it for something is hindering new features and
makes the code more complex that it should be.
Said storage engine also has tons of technical debt. To pick an example, the
fact that during range queries we update {{SliceQueryFilter.count}} is pretty
hacky and error prone. Or the overly complex ways {{AbstractQueryPager}} has
to go into to simply remove the last query result.
So I want to bite the bullet and modernize this storage engine. I propose to
do 2 main things:
# Make the storage engine more aware of the CQL structure. In practice,
instead of having partitions be a simple iterable map of cells, it should be
an iterable list of row (each being itself composed of per-column cells,
though obviously not exactly the same kind of cell we have today).
# Make the engine more iterative. What I mean here is that in the read path,
we end up reading all cells in memory (we put them in a ColumnFamily object),
but there is really no reason to. If instead we were working with iterators
all the way through, we could get to a point where we're basically
transferring data from disk to the network, and we should be able to reduce
GC substantially.
Please note that such refactor should provide some performance improvements
right off the bat but it's not it's primary goal either. It's primary goal is
to simplify the storage engine and adds abstraction that are better suited to
further optimizations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8099) Refactor and modernize the storage engine
[
https://issues.apache.org/jira/browse/CASSANDRA-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14624257#comment-14624257
]
tzach commented on CASSANDRA-8099:
--
looks like this change undoes the fix for CASSANDRA-4858.
Is this correct? intentional?
Refactor and modernize the storage engine
-
Key: CASSANDRA-8099
URL: https://issues.apache.org/jira/browse/CASSANDRA-8099
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Fix For: 3.0 beta 1
Attachments: 8099-nit
The current storage engine (which for this ticket I'll loosely define as the
code implementing the read/write path) is suffering from old age. One of the
main problem is that the only structure it deals with is the cell, which
completely ignores the more high level CQL structure that groups cell into
(CQL) rows.
This leads to many inefficiencies, like the fact that during a reads we have
to group cells multiple times (to count on replica, then to count on the
coordinator, then to produce the CQL resultset) because we forget about the
grouping right away each time (so lots of useless cell names comparisons in
particular). But outside inefficiencies, having to manually recreate the CQL
structure every time we need it for something is hindering new features and
makes the code more complex that it should be.
Said storage engine also has tons of technical debt. To pick an example, the
fact that during range queries we update {{SliceQueryFilter.count}} is pretty
hacky and error prone. Or the overly complex ways {{AbstractQueryPager}} has
to go into to simply remove the last query result.
So I want to bite the bullet and modernize this storage engine. I propose to
do 2 main things:
# Make the storage engine more aware of the CQL structure. In practice,
instead of having partitions be a simple iterable map of cells, it should be
an iterable list of row (each being itself composed of per-column cells,
though obviously not exactly the same kind of cell we have today).
# Make the engine more iterative. What I mean here is that in the read path,
we end up reading all cells in memory (we put them in a ColumnFamily object),
but there is really no reason to. If instead we were working with iterators
all the way through, we could get to a point where we're basically
transferring data from disk to the network, and we should be able to reduce
GC substantially.
Please note that such refactor should provide some performance improvements
right off the bat but it's not it's primary goal either. It's primary goal is
to simplify the storage engine and adds abstraction that are better suited to
further optimizations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9628) Unknown keyspace system_traces exception when using nodetool on a new cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14597282#comment-14597282
]
tzach commented on CASSANDRA-9628:
--
One more thing:
During installation, I
* explicitly stop Cassandra service
* rm -rf /var/lib/cassandra/data/system/*
* rm -rf /var/lib/cassandra/data/commitlog/*
* update the cassandra.yaml
* restart the service
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)
[jira] [Commented] (CASSANDRA-9628) Unknown keyspace system_traces exception when using nodetool on a new cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Created] (CASSANDRA-9628) Unknown keyspace system_traces exception when using nodetool on a new cluster
tzach created CASSANDRA-9628:
Summary: 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)
