git commit: Update version, news, license, ... for 1.1.5 release
Updated Branches:
refs/heads/cassandra-1.1 2cd73633b - acaa52465
Update version, news, license, ... for 1.1.5 release
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/acaa5246
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/acaa5246
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/acaa5246
Branch: refs/heads/cassandra-1.1
Commit: acaa52465554e82519fc312d3fcff586f55ee36e
Parents: 2cd7363
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 6 08:57:57 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 6 08:57:57 2012 +0200
--
CHANGES.txt|5
NEWS.txt | 18 +++
build.xml |2 +-
debian/changelog |6 +
.../db/columniterator/ISSTableColumnIterator.java | 18 +++
5 files changed, 48 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/acaa5246/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 04fa0bf..b33b2c3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -9,6 +9,11 @@
* Change nodetool setcachecapcity to manipulate global caches (CASSANDRA-4563)
* (cql3) fix setting compaction strategy (CASSANDRA-4597)
* fix broken system.schema_* timestamps on system startup (CASSANDRA-4561)
+ * fix wrong skip of cache saving (CASSANDRA-4533)
+ * Avoid NPE when lost+found is in data dir (CASSANDRA-4572)
+ * Respect five-minute flush moratorium after initial CL replay
(CASSANDRA-4474)
+ * Adds ntp as recommended in debian packaging (CASSANDRA-4606)
+ * Configurable transport in CF Record{Reader|Writer} (CASSANDRA-4558)
Merged from 1.0:
* increase Xss to 160k to accomodate latest 1.6 JVMs (CASSANDRA-4602)
* fix toString of hint destination tokens (CASSANDRA-4568)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/acaa5246/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index a127ead..ad22610 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -9,6 +9,24 @@ upgrade, just in case you need to roll back to the previous
version.
by version X, but the inverse is not necessarily the case.)
+1.1.5
+=
+
+Upgrading
+-
+- Nothing specific to this release, but please see 1.1 if you are upgrading
+ from a previous version.
+
+
+1.1.4
+=
+
+Upgrading
+-
+- Nothing specific to this release, but please see 1.1 if you are upgrading
+ from a previous version.
+
+
1.1.3
=
http://git-wip-us.apache.org/repos/asf/cassandra/blob/acaa5246/build.xml
--
diff --git a/build.xml b/build.xml
index 10dbecc..b498d12 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
property name=debuglevel value=source,lines,vars/
!-- default version and SCM information --
-property name=base.version value=1.1.4/
+property name=base.version value=1.1.5/
property name=scm.connection
value=scm:git://git.apache.org/cassandra.git/
property name=scm.developerConnection
value=scm:git://git.apache.org/cassandra.git/
property name=scm.url
value=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree/
http://git-wip-us.apache.org/repos/asf/cassandra/blob/acaa5246/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 9c6bfdc..8e6b389 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (1.1.5) unstable; urgency=low
+
+ * New release
+
+ -- Sylvain Lebresne slebre...@apache.org Thu, 06 Sep 2012 08:53:50 +0200
+
cassandra (1.1.4) unstable; urgency=low
* New release
http://git-wip-us.apache.org/repos/asf/cassandra/blob/acaa5246/src/java/org/apache/cassandra/db/columniterator/ISSTableColumnIterator.java
--
diff --git
a/src/java/org/apache/cassandra/db/columniterator/ISSTableColumnIterator.java
b/src/java/org/apache/cassandra/db/columniterator/ISSTableColumnIterator.java
index 4da4c0a..0b6a652 100644
---
a/src/java/org/apache/cassandra/db/columniterator/ISSTableColumnIterator.java
+++
b/src/java/org/apache/cassandra/db/columniterator/ISSTableColumnIterator.java
@@ -1,3 +1,21 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License,
Git Push Summary
Updated Tags: refs/tags/1.1.5-tentative [created] acaa52465
[jira] [Commented] (CASSANDRA-4602) Stack Size on Sun JVM 1.6.0_33 must be at least 160k
[
https://issues.apache.org/jira/browse/CASSANDRA-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449551#comment-13449551
]
Omid Aladini commented on CASSANDRA-4602:
-
Apparently this is due to HotSpot fix 7059899 [1] on 1.6.0_34 that increased
StackShadowPages's default to 20, since a change in socketWrite's native
implementation required more stack space. Increased StackShadowPages might
require increased stack size (-Xss) [2] so that upon a call to a native method,
there would be at least StackShadowPages stack space available.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7059899
[2] http://www.oracle.com/technetwork/java/javase/crashes-137240.html
Stack Size on Sun JVM 1.6.0_33 must be at least 160k
Key: CASSANDRA-4602
URL: https://issues.apache.org/jira/browse/CASSANDRA-4602
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Ubuntu 10.04
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01, mixed mode)
Reporter: Aaron Morton
Assignee: Jonathan Ellis
Fix For: 1.0.12, 1.1.5
Attachments: 4602.txt
I started a fresh Cassandra 1.1.4 install with Sun JVM 1.6.35.
On startup I got this in output.log
{noformat}
The stack size specified is too small, Specify at least 160k
Cannot create Java VM
Service exit with a return value of 1
{noformat}
Remembering CASSANDRA-4275 I monkeyed around and started the JVM with
-Xss160k the same as Java 7. I then got
{code:java}
ERROR [WRITE-/192.168.1.12] 2012-08-31 01:43:29,865
AbstractCassandraDaemon.java (line 134) Exception in thread
Thread[WRITE-/192.168.1.12,5,main]
java.lang.StackOverflowError
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(Unknown Source)
at java.net.SocketOutputStream.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
at java.io.BufferedOutputStream.flush(Unknown Source)
at java.io.DataOutputStream.flush(Unknown Source)
at
org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:156)
at
org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:126)
{code}
Same as CASSANDRA-4442
At which point I dropped back to Java 6.33.
CASSANDRA-4457 bumped the stack size to 180 for java 7, should we also do
this for Java 6.33+ ?
--
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
[jira] [Updated] (CASSANDRA-4612) cql error with ORDER BY when using IN
[
https://issues.apache.org/jira/browse/CASSANDRA-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4612:
---
Component/s: Core
Affects Version/s: 1.2.0
Fix Version/s: 1.2.0 beta 1
cql error with ORDER BY when using IN
-
Key: CASSANDRA-4612
URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: ubuntu, cassandra trunk (commit
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.2.0 beta 1
{code}
CREATE TABLE test(
my_id varchar,
col1 int,
value varchar,
PRIMARY KEY (my_id, col1)
);
INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}
The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
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
[jira] [Updated] (CASSANDRA-4377) CQL3 column value validation bug
[
https://issues.apache.org/jira/browse/CASSANDRA-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4377:
Attachment: 4377-2.txt
On Pavel's patch:
* I'm not a fan of logging a warning (or to log anything really) if someone has
CQL3 CFs. We're trying to push CQL3 as a good thing, let's not log anything
that could be interpreted as if something was wrong/abnormal.
* The check is excluding composite CF without any ColumnDefinition while it
shouldn't.
Attaching a v2 that:
* Fix the two remarks above.
* Rename the check as isThriftIncompatible. I think it's more about detecting
CF definitions that cannot be exploided fully by thrift rather than
discriminate between what is a thrift CF and CQL3 CF. Especially since the
intersection between those two notions is not empty.
* Ship the changes to ThriftValidation from my first patch, though modified a
bit to be more generic and handle correctly collections. I'll note that this
part makes validation potentially iterate over all ColumnDefinition for
composite CF, but that's not really an issue since composite CF created on the
thrift side are almost guaranteed to have no ColumnDefinition.
CQL3 column value validation bug
Key: CASSANDRA-4377
URL: https://issues.apache.org/jira/browse/CASSANDRA-4377
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.1.1
Reporter: Nick Bailey
Assignee: Pavel Yaskevich
Labels: cql3
Fix For: 1.2.0
Attachments: 4377-2.txt, 4377.txt, CASSANDRA-4377.patch
{noformat}
cqlsh create keyspace test with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor = 1;
cqlsh use test;
cqlsh:test CREATE TABLE stats (
... gid blob,
... period int,
... tid blob,
... sumint,
... uniques blob,
... PRIMARY KEY(gid, period, tid)
... );
cqlsh:test describe columnfamily stats;
CREATE TABLE stats (
gid blob PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=text AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write='true' AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';
{noformat}
You can see in the above output that the stats cf is created with the column
validator set to text, but neither of the non primary key columns defined are
text. It should either be setting metadata for those columns or not setting a
default validator or some combination of the two.
--
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
[jira] [Updated] (CASSANDRA-4612) cql error with ORDER BY when using IN
[
https://issues.apache.org/jira/browse/CASSANDRA-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4612:
---
Attachment: CASSANDRA-4612.patch
fixed problem related to determining position when single 'order by' condition
is used and added a check to prevent users from ordering by columns which are
not included in the select clause.
cql error with ORDER BY when using IN
-
Key: CASSANDRA-4612
URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: ubuntu, cassandra trunk (commit
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.2.0 beta 1
Attachments: CASSANDRA-4612.patch
{code}
CREATE TABLE test(
my_id varchar,
col1 int,
value varchar,
PRIMARY KEY (my_id, col1)
);
INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}
The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
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
[jira] [Commented] (CASSANDRA-4377) CQL3 column value validation bug
[
https://issues.apache.org/jira/browse/CASSANDRA-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449582#comment-13449582
]
Pavel Yaskevich commented on CASSANDRA-4377:
bq. I'm not a fan of logging a warning (or to log anything really) if someone
has CQL3 CFs. We're trying to push CQL3 as a good thing, let's not log anything
that could be interpreted as if something was wrong/abnormal.
Wouldn't that create confusion when some CFs are visible through Thrift and
some are not or do we rely on that users should know what is so special about
CQL3 CFs?
CQL3 column value validation bug
Key: CASSANDRA-4377
URL: https://issues.apache.org/jira/browse/CASSANDRA-4377
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.1.1
Reporter: Nick Bailey
Assignee: Pavel Yaskevich
Labels: cql3
Fix For: 1.2.0
Attachments: 4377-2.txt, 4377.txt, CASSANDRA-4377.patch
{noformat}
cqlsh create keyspace test with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor = 1;
cqlsh use test;
cqlsh:test CREATE TABLE stats (
... gid blob,
... period int,
... tid blob,
... sumint,
... uniques blob,
... PRIMARY KEY(gid, period, tid)
... );
cqlsh:test describe columnfamily stats;
CREATE TABLE stats (
gid blob PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=text AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write='true' AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';
{noformat}
You can see in the above output that the stats cf is created with the column
validator set to text, but neither of the non primary key columns defined are
text. It should either be setting metadata for those columns or not setting a
default validator or some combination of the two.
--
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
[jira] [Commented] (CASSANDRA-4377) CQL3 column value validation bug
[
https://issues.apache.org/jira/browse/CASSANDRA-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449586#comment-13449586
]
Sylvain Lebresne commented on CASSANDRA-4377:
-
bq. Wouldn't that create confusion when some CFs are visible through Thrift and
some are not
I'm not saying this shouldn't be documented at all, but merely that it's a
documentation issue and as such logging it at each startup is not the right
place.
CQL3 column value validation bug
Key: CASSANDRA-4377
URL: https://issues.apache.org/jira/browse/CASSANDRA-4377
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.1.1
Reporter: Nick Bailey
Assignee: Pavel Yaskevich
Labels: cql3
Fix For: 1.2.0
Attachments: 4377-2.txt, 4377.txt, CASSANDRA-4377.patch
{noformat}
cqlsh create keyspace test with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor = 1;
cqlsh use test;
cqlsh:test CREATE TABLE stats (
... gid blob,
... period int,
... tid blob,
... sumint,
... uniques blob,
... PRIMARY KEY(gid, period, tid)
... );
cqlsh:test describe columnfamily stats;
CREATE TABLE stats (
gid blob PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=text AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write='true' AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';
{noformat}
You can see in the above output that the stats cf is created with the column
validator set to text, but neither of the non primary key columns defined are
text. It should either be setting metadata for those columns or not setting a
default validator or some combination of the two.
--
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
[jira] [Commented] (CASSANDRA-4377) CQL3 column value validation bug
[
https://issues.apache.org/jira/browse/CASSANDRA-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449588#comment-13449588
]
Pavel Yaskevich commented on CASSANDRA-4377:
If everyone else is ok with that, lgtm.
CQL3 column value validation bug
Key: CASSANDRA-4377
URL: https://issues.apache.org/jira/browse/CASSANDRA-4377
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.1.1
Reporter: Nick Bailey
Assignee: Pavel Yaskevich
Labels: cql3
Fix For: 1.2.0
Attachments: 4377-2.txt, 4377.txt, CASSANDRA-4377.patch
{noformat}
cqlsh create keyspace test with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor = 1;
cqlsh use test;
cqlsh:test CREATE TABLE stats (
... gid blob,
... period int,
... tid blob,
... sumint,
... uniques blob,
... PRIMARY KEY(gid, period, tid)
... );
cqlsh:test describe columnfamily stats;
CREATE TABLE stats (
gid blob PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.BytesType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=text AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write='true' AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';
{noformat}
You can see in the above output that the stats cf is created with the column
validator set to text, but neither of the non primary key columns defined are
text. It should either be setting metadata for those columns or not setting a
default validator or some combination of the two.
--
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
[jira] [Updated] (CASSANDRA-4578) Dead lock in mutation stage when many concurrent writes to few columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4578:
Attachment: 4578.txt
Attaching patch to use a callback (as it avoids creating lots of thread that
just spend time waiting on a condition) to send back the response from CMVH.
Dead lock in mutation stage when many concurrent writes to few columns
--
Key: CASSANDRA-4578
URL: https://issues.apache.org/jira/browse/CASSANDRA-4578
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.0
Environment: 15 cassandra instances
CentOS5
8 Core 64GB Memory
java version 1.6.0_33
Java(TM) SE Runtime Environment (build 1.6.0_33-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode)
Reporter: Suguru Namura
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.1.6
Attachments: 4578.txt, threaddump-1344957574788.tdump
When I send many request to increment counters to few counter columns,
sometimes mutation stage cause dead lock. When it happened, all of mutation
threads are locked and do not accept updates any more.
{noformat}
MutationStage:432 - Thread t@1389
java.lang.Thread.State: TIMED_WAITING
at java.lang.Object.wait(Native Method)
- waiting on b90b45b (a org.apache.cassandra.utils.SimpleCondition)
at java.lang.Object.wait(Object.java:443)
at java.util.concurrent.TimeUnit.timedWait(TimeUnit.java:292)
at
org.apache.cassandra.utils.SimpleCondition.await(SimpleCondition.java:54)
at
org.apache.cassandra.service.AbstractWriteResponseHandler.get(AbstractWriteResponseHandler.java:55)
at
org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:51)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- locked 4b1b0a6f (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
{noformat}
--
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
[jira] [Commented] (CASSANDRA-4602) Stack Size on Sun JVM 1.6.0_33 must be at least 160k
[
https://issues.apache.org/jira/browse/CASSANDRA-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449638#comment-13449638
]
Jonathan Ellis commented on CASSANDRA-4602:
---
Thanks, Omid!
Stack Size on Sun JVM 1.6.0_33 must be at least 160k
Key: CASSANDRA-4602
URL: https://issues.apache.org/jira/browse/CASSANDRA-4602
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Ubuntu 10.04
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01, mixed mode)
Reporter: Aaron Morton
Assignee: Jonathan Ellis
Fix For: 1.0.12, 1.1.5
Attachments: 4602.txt
I started a fresh Cassandra 1.1.4 install with Sun JVM 1.6.35.
On startup I got this in output.log
{noformat}
The stack size specified is too small, Specify at least 160k
Cannot create Java VM
Service exit with a return value of 1
{noformat}
Remembering CASSANDRA-4275 I monkeyed around and started the JVM with
-Xss160k the same as Java 7. I then got
{code:java}
ERROR [WRITE-/192.168.1.12] 2012-08-31 01:43:29,865
AbstractCassandraDaemon.java (line 134) Exception in thread
Thread[WRITE-/192.168.1.12,5,main]
java.lang.StackOverflowError
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(Unknown Source)
at java.net.SocketOutputStream.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
at java.io.BufferedOutputStream.flush(Unknown Source)
at java.io.DataOutputStream.flush(Unknown Source)
at
org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:156)
at
org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:126)
{code}
Same as CASSANDRA-4442
At which point I dropped back to Java 6.33.
CASSANDRA-4457 bumped the stack size to 180 for java 7, should we also do
this for Java 6.33+ ?
--
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
[jira] [Updated] (CASSANDRA-4612) cql error with ORDER BY when using IN
[
https://issues.apache.org/jira/browse/CASSANDRA-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4612:
--
Reviewer: slebresne (was: jbellis)
cql error with ORDER BY when using IN
-
Key: CASSANDRA-4612
URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: ubuntu, cassandra trunk (commit
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.2.0 beta 1
Attachments: CASSANDRA-4612.patch
{code}
CREATE TABLE test(
my_id varchar,
col1 int,
value varchar,
PRIMARY KEY (my_id, col1)
);
INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}
The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
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
[jira] [Updated] (CASSANDRA-2293) Rewrite nodetool help
[ https://issues.apache.org/jira/browse/CASSANDRA-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-2293: --- Attachment: 0002-Jira-CASSANDRA-2293-Rewrite-nodetool-help.patch adding version 0002 as settraceprobability was added to nodetool. Also, I cleaned up my imports as per the cassandra code style wiki page Rewrite nodetool help - Key: CASSANDRA-2293 URL: https://issues.apache.org/jira/browse/CASSANDRA-2293 Project: Cassandra Issue Type: Improvement Components: Core, Documentation website Affects Versions: 0.8 beta 1 Reporter: Aaron Morton Assignee: Jason Brown Priority: Minor Fix For: 1.2.1 Attachments: 0001-Jira-CASSANDRA-2293-Rewrite-nodetool-help.patch, 0002-Jira-CASSANDRA-2293-Rewrite-nodetool-help.patch Once CASSANDRA-2008 is through and we are happy with the approach I would like to write similar help for nodetool. Both command line help of the form nodetool help and nodetool help command. -- 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
[jira] [Updated] (CASSANDRA-4532) NPE when trying to select a slice from a composite table
[
https://issues.apache.org/jira/browse/CASSANDRA-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4532:
Attachment: 4532.txt
Attaching (trivial) patch to fix the validation issue (the request is invalid
because it mixes an equal and inequal on the same ctime column).
For the record, a valid request that does the equivalent of a thrift sliceRange
would be:
{noformat}
SELECT * FROM compositetest WHERE ctime=12345679 and ctime=12345680 limit 3;
{noformat}
If you further want to restrict the result to those column where key='key3',
you'd have to do it client side (but that would be the same with thrift).
NPE when trying to select a slice from a composite table
Key: CASSANDRA-4532
URL: https://issues.apache.org/jira/browse/CASSANDRA-4532
Project: Cassandra
Issue Type: Bug
Components: API, Core
Affects Versions: 1.1.3
Environment: Cassandra 1.1.3 (2 nodes) on a single host - mac osx
Reporter: basanth gowda
Priority: Minor
Labels: Slice, cql, cql3
Fix For: 1.1.6
Attachments: 4532.txt
I posted this question on StackOverflow, because i need a solution.
Created a table with :
{noformat}
create table compositetest(m_id ascii,i_id int,l_id ascii,body ascii, PRIMARY
KEY(m_id,i_id,l_id));
{noformat}
wanted to slice the results returned, so did something like below, not sure
if its the right way. The first one returns data perfectly as expected,
second one to get the next 3 columns closes the transport of my cqlsh
{noformat}
cqlsh:testkeyspace1 select * from compositetest where i_id=3 limit 3;
m_id | i_id | l_id | body
--+--+--+--
m1 |1 | l1 | b1
m1 |2 | l2 | b2
m2 |1 | l1 | b1
cqlsh:testkeyspace1 Was trying to write something for slice range.
TSocket read 0 bytes
{noformat}
Is there a way to achieve what I am doing here, it would be good if some
meaning ful error is sent back, instead of cqlsh closing the transport.
On the server side I see the following error.
{noformat}
ERROR [Thrift:3] 2012-08-12 15:15:24,414 CustomTThreadPoolServer.java (line
204) Error occurred during processing of message.
java.lang.NullPointerException
at
org.apache.cassandra.cql3.statements.SelectStatement$Restriction.setBound(SelectStatement.java:1277)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.updateRestriction(SelectStatement.java:1151)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1001)
at
org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:215)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1237)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
{noformat}
With ThriftClient I get :
{noformat}
org.apache.thrift.transport.TTransportException
at
org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
at
org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:129)
at
org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:101)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
at
org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:378)
at
org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:297)
at
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:204)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:69)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_execute_cql_query(Cassandra.java:1402)
at
org.apache.cassandra.thrift.Cassandra$Client.execute_cql_query(Cassandra.java:1388)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent
[jira] [Assigned] (CASSANDRA-4532) NPE when trying to select a slice from a composite table
[
https://issues.apache.org/jira/browse/CASSANDRA-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne reassigned CASSANDRA-4532:
---
Assignee: Sylvain Lebresne
NPE when trying to select a slice from a composite table
Key: CASSANDRA-4532
URL: https://issues.apache.org/jira/browse/CASSANDRA-4532
Project: Cassandra
Issue Type: Bug
Components: API, Core
Affects Versions: 1.1.3
Environment: Cassandra 1.1.3 (2 nodes) on a single host - mac osx
Reporter: basanth gowda
Assignee: Sylvain Lebresne
Priority: Minor
Labels: Slice, cql, cql3
Fix For: 1.1.6
Attachments: 4532.txt
I posted this question on StackOverflow, because i need a solution.
Created a table with :
{noformat}
create table compositetest(m_id ascii,i_id int,l_id ascii,body ascii, PRIMARY
KEY(m_id,i_id,l_id));
{noformat}
wanted to slice the results returned, so did something like below, not sure
if its the right way. The first one returns data perfectly as expected,
second one to get the next 3 columns closes the transport of my cqlsh
{noformat}
cqlsh:testkeyspace1 select * from compositetest where i_id=3 limit 3;
m_id | i_id | l_id | body
--+--+--+--
m1 |1 | l1 | b1
m1 |2 | l2 | b2
m2 |1 | l1 | b1
cqlsh:testkeyspace1 Was trying to write something for slice range.
TSocket read 0 bytes
{noformat}
Is there a way to achieve what I am doing here, it would be good if some
meaning ful error is sent back, instead of cqlsh closing the transport.
On the server side I see the following error.
{noformat}
ERROR [Thrift:3] 2012-08-12 15:15:24,414 CustomTThreadPoolServer.java (line
204) Error occurred during processing of message.
java.lang.NullPointerException
at
org.apache.cassandra.cql3.statements.SelectStatement$Restriction.setBound(SelectStatement.java:1277)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.updateRestriction(SelectStatement.java:1151)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1001)
at
org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:215)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1237)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
{noformat}
With ThriftClient I get :
{noformat}
org.apache.thrift.transport.TTransportException
at
org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
at
org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:129)
at
org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:101)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
at
org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:378)
at
org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:297)
at
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:204)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:69)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_execute_cql_query(Cassandra.java:1402)
at
org.apache.cassandra.thrift.Cassandra$Client.execute_cql_query(Cassandra.java:1388)
{noformat}
--
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
[jira] [Commented] (CASSANDRA-4532) NPE when trying to select a slice from a composite table
[
https://issues.apache.org/jira/browse/CASSANDRA-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449681#comment-13449681
]
Jonathan Ellis commented on CASSANDRA-4532:
---
+1
NPE when trying to select a slice from a composite table
Key: CASSANDRA-4532
URL: https://issues.apache.org/jira/browse/CASSANDRA-4532
Project: Cassandra
Issue Type: Bug
Components: API, Core
Affects Versions: 1.1.3
Environment: Cassandra 1.1.3 (2 nodes) on a single host - mac osx
Reporter: basanth gowda
Assignee: Sylvain Lebresne
Priority: Minor
Labels: Slice, cql, cql3
Fix For: 1.1.6
Attachments: 4532.txt
I posted this question on StackOverflow, because i need a solution.
Created a table with :
{noformat}
create table compositetest(m_id ascii,i_id int,l_id ascii,body ascii, PRIMARY
KEY(m_id,i_id,l_id));
{noformat}
wanted to slice the results returned, so did something like below, not sure
if its the right way. The first one returns data perfectly as expected,
second one to get the next 3 columns closes the transport of my cqlsh
{noformat}
cqlsh:testkeyspace1 select * from compositetest where i_id=3 limit 3;
m_id | i_id | l_id | body
--+--+--+--
m1 |1 | l1 | b1
m1 |2 | l2 | b2
m2 |1 | l1 | b1
cqlsh:testkeyspace1 Was trying to write something for slice range.
TSocket read 0 bytes
{noformat}
Is there a way to achieve what I am doing here, it would be good if some
meaning ful error is sent back, instead of cqlsh closing the transport.
On the server side I see the following error.
{noformat}
ERROR [Thrift:3] 2012-08-12 15:15:24,414 CustomTThreadPoolServer.java (line
204) Error occurred during processing of message.
java.lang.NullPointerException
at
org.apache.cassandra.cql3.statements.SelectStatement$Restriction.setBound(SelectStatement.java:1277)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.updateRestriction(SelectStatement.java:1151)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1001)
at
org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:215)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1237)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
{noformat}
With ThriftClient I get :
{noformat}
org.apache.thrift.transport.TTransportException
at
org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
at
org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:129)
at
org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:101)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
at
org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:378)
at
org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:297)
at
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:204)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:69)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_execute_cql_query(Cassandra.java:1402)
at
org.apache.cassandra.thrift.Cassandra$Client.execute_cql_query(Cassandra.java:1388)
{noformat}
--
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
[jira] [Commented] (CASSANDRA-4612) cql error with ORDER BY when using IN
[
https://issues.apache.org/jira/browse/CASSANDRA-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449705#comment-13449705
]
Sylvain Lebresne commented on CASSANDRA-4612:
-
The fix for the case where there is only one ordered column lgtm but this
doesn't handle the CompositeComparator case.
cql error with ORDER BY when using IN
-
Key: CASSANDRA-4612
URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: ubuntu, cassandra trunk (commit
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.2.0 beta 1
Attachments: CASSANDRA-4612.patch
{code}
CREATE TABLE test(
my_id varchar,
col1 int,
value varchar,
PRIMARY KEY (my_id, col1)
);
INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}
The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
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
[jira] [Commented] (CASSANDRA-4612) cql error with ORDER BY when using IN
[
https://issues.apache.org/jira/browse/CASSANDRA-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449706#comment-13449706
]
Sylvain Lebresne commented on CASSANDRA-4612:
-
Also, I believe this affect 1.1 as well, so I would suggest fixing it there.
cql error with ORDER BY when using IN
-
Key: CASSANDRA-4612
URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: ubuntu, cassandra trunk (commit
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.2.0 beta 1
Attachments: CASSANDRA-4612.patch
{code}
CREATE TABLE test(
my_id varchar,
col1 int,
value varchar,
PRIMARY KEY (my_id, col1)
);
INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}
The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
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
[jira] [Created] (CASSANDRA-4624) ORDER BY validation is not restrictive enough
Sylvain Lebresne created CASSANDRA-4624: --- Summary: ORDER BY validation is not restrictive enough Key: CASSANDRA-4624 URL: https://issues.apache.org/jira/browse/CASSANDRA-4624 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 beta 1 We're not able to do order by on anything that is a key range. However, we only refuse queries that have an empty where clause, but that doesn't exclude all key ranges at all. -- 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
[jira] [Updated] (CASSANDRA-4624) ORDER BY validation is not restrictive enough
[ https://issues.apache.org/jira/browse/CASSANDRA-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4624: Attachment: 4624.txt ORDER BY validation is not restrictive enough - Key: CASSANDRA-4624 URL: https://issues.apache.org/jira/browse/CASSANDRA-4624 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.3 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Fix For: 1.1.6, 1.2.0 beta 1 Attachments: 4624.txt We're not able to do order by on anything that is a key range. However, we only refuse queries that have an empty where clause, but that doesn't exclude all key ranges at all. -- 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
[jira] [Updated] (CASSANDRA-4624) ORDER BY validation is not restrictive enough
[ https://issues.apache.org/jira/browse/CASSANDRA-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4624: Affects Version/s: (was: 1.2.0 beta 1) 1.1.3 Fix Version/s: 1.1.6 ORDER BY validation is not restrictive enough - Key: CASSANDRA-4624 URL: https://issues.apache.org/jira/browse/CASSANDRA-4624 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.3 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Fix For: 1.1.6, 1.2.0 beta 1 Attachments: 4624.txt We're not able to do order by on anything that is a key range. However, we only refuse queries that have an empty where clause, but that doesn't exclude all key ranges at all. -- 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
git commit: fix potential NPE with both equal and unequal restriction
Updated Branches: refs/heads/cassandra-1.1 acaa52465 - 8e03f7bdf fix potential NPE with both equal and unequal restriction patch by slebresne; reviewed by jbellis for CASSANDRA-4532 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8e03f7bd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8e03f7bd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8e03f7bd Branch: refs/heads/cassandra-1.1 Commit: 8e03f7bdf26558dc397628c885c5b6ab0cfde3e0 Parents: acaa524 Author: Sylvain Lebresne sylv...@datastax.com Authored: Thu Sep 6 16:56:29 2012 +0200 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Thu Sep 6 16:56:29 2012 +0200 -- CHANGES.txt|3 +++ .../cassandra/cql3/statements/SelectStatement.java |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8e03f7bd/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index b33b2c3..6e72892 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,6 @@ +1.1.6 + * (cql3) fix potential NPE with both equal and unequal restriction (CASSANDRA-4532) + 1.1.5 * add SecondaryIndex.reload API (CASSANDRA-4581) * use millis + atomicint for commitlog segment creation instead of http://git-wip-us.apache.org/repos/asf/cassandra/blob/8e03f7bd/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java -- diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java index 0c34eb0..dd00c5c 100644 --- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java +++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java @@ -1274,6 +1274,9 @@ public class SelectStatement implements CQLStatement break; } +if (bounds == null) +throw new InvalidRequestException(String.format(%s cannot be restricted by both an equal and an inequal relation, name)); + if (bounds[b.idx] != null) throw new InvalidRequestException(String.format(Invalid restrictions found on %s, name)); bounds[b.idx] = t;
[jira] [Updated] (CASSANDRA-4612) cql error with ORDER BY when using IN
[
https://issues.apache.org/jira/browse/CASSANDRA-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4612:
---
Affects Version/s: (was: 1.2.0)
1.1.4
Fix Version/s: (was: 1.2.0 beta 1)
1.1.6
cql error with ORDER BY when using IN
-
Key: CASSANDRA-4612
URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.4
Environment: ubuntu, cassandra trunk (commit
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.6
Attachments: CASSANDRA-4612.patch
{code}
CREATE TABLE test(
my_id varchar,
col1 int,
value varchar,
PRIMARY KEY (my_id, col1)
);
INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}
The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
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
[jira] [Commented] (CASSANDRA-4624) ORDER BY validation is not restrictive enough
[ https://issues.apache.org/jira/browse/CASSANDRA-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449727#comment-13449727 ] Jonathan Ellis commented on CASSANDRA-4624: --- +1 ORDER BY validation is not restrictive enough - Key: CASSANDRA-4624 URL: https://issues.apache.org/jira/browse/CASSANDRA-4624 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.3 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Fix For: 1.1.6, 1.2.0 beta 1 Attachments: 4624.txt We're not able to do order by on anything that is a key range. However, we only refuse queries that have an empty where clause, but that doesn't exclude all key ranges at all. -- 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
[jira] [Updated] (CASSANDRA-4612) cql error with ORDER BY when using IN
[
https://issues.apache.org/jira/browse/CASSANDRA-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4612:
---
Attachment: (was: CASSANDRA-4612.patch)
cql error with ORDER BY when using IN
-
Key: CASSANDRA-4612
URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.4
Environment: ubuntu, cassandra trunk (commit
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.6
Attachments: CASSANDRA-4612.patch
{code}
CREATE TABLE test(
my_id varchar,
col1 int,
value varchar,
PRIMARY KEY (my_id, col1)
);
INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}
The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
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
[jira] [Updated] (CASSANDRA-4612) cql error with ORDER BY when using IN
[
https://issues.apache.org/jira/browse/CASSANDRA-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4612:
---
Attachment: CASSANDRA-4612.patch
ported to 1.1 and added composite support.
cql error with ORDER BY when using IN
-
Key: CASSANDRA-4612
URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.4
Environment: ubuntu, cassandra trunk (commit
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.6
Attachments: CASSANDRA-4612.patch
{code}
CREATE TABLE test(
my_id varchar,
col1 int,
value varchar,
PRIMARY KEY (my_id, col1)
);
INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}
The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
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
[jira] [Commented] (CASSANDRA-4490) Improve IAuthority interface by introducing fine-grained access permissions and grant/revoke commands.
[ https://issues.apache.org/jira/browse/CASSANDRA-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449732#comment-13449732 ] Yuki Morishita commented on CASSANDRA-4490: --- Hmm, if LIST GRANTS command is expected to return list of Permission, then I think you should change method signature of listPermissions to return ListPermission or some other CollectionPermission. It would describe API more precisely. Improve IAuthority interface by introducing fine-grained access permissions and grant/revoke commands. -- Key: CASSANDRA-4490 URL: https://issues.apache.org/jira/browse/CASSANDRA-4490 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1.6 Attachments: 4490-v3.txt, CASSANDRA-4490.patch, CASSANDRA-4490-v2.patch In order to improve IAuthority interface I propose to add the following new permissions: USE, SELECT, CREATE, ALTER, DROP, UPDATE, DELETE, ALL, NONE. And the following new commands to the CQL 3.0 which would give users possibility (with appropriate implementation) to dynamically change user's rights to access system objects: GRANT permission ON resource TO user [WITH GRANT OPTION]; REVOKE permission ON resource FROM user_name; LIST GRANTS FOR user; // Not 'SHOW' because it's reserved for cqlsh for commands like 'show cluster' where resource is Keyspace or ColumnFamily (initially, but extendable to indexes or configration options in the future), and permission is listed above. To keep the system backward compatible with old authorization interface implementations Permission class would include the mappings of the new to old permissions: READ - USE, SELECT WRITE - USE, CREATE, ALTER, DROP, UPDATE, DELETE -- 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
[jira] [Commented] (CASSANDRA-4490) Improve IAuthority interface by introducing fine-grained access permissions and grant/revoke commands.
[ https://issues.apache.org/jira/browse/CASSANDRA-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449737#comment-13449737 ] Pavel Yaskevich commented on CASSANDRA-4490: It's not only permission but rather resource, permission and grant_option for now, but it's not final list of fields as it depends on IAuthority implementation. Improve IAuthority interface by introducing fine-grained access permissions and grant/revoke commands. -- Key: CASSANDRA-4490 URL: https://issues.apache.org/jira/browse/CASSANDRA-4490 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1.6 Attachments: 4490-v3.txt, CASSANDRA-4490.patch, CASSANDRA-4490-v2.patch In order to improve IAuthority interface I propose to add the following new permissions: USE, SELECT, CREATE, ALTER, DROP, UPDATE, DELETE, ALL, NONE. And the following new commands to the CQL 3.0 which would give users possibility (with appropriate implementation) to dynamically change user's rights to access system objects: GRANT permission ON resource TO user [WITH GRANT OPTION]; REVOKE permission ON resource FROM user_name; LIST GRANTS FOR user; // Not 'SHOW' because it's reserved for cqlsh for commands like 'show cluster' where resource is Keyspace or ColumnFamily (initially, but extendable to indexes or configration options in the future), and permission is listed above. To keep the system backward compatible with old authorization interface implementations Permission class would include the mappings of the new to old permissions: READ - USE, SELECT WRITE - USE, CREATE, ALTER, DROP, UPDATE, DELETE -- 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
[jira] [Updated] (CASSANDRA-4237) Add back 0.8-style memtable_lifetime feature
[ https://issues.apache.org/jira/browse/CASSANDRA-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-4237: -- Attachment: (was: 4237.txt) Add back 0.8-style memtable_lifetime feature Key: CASSANDRA-4237 URL: https://issues.apache.org/jira/browse/CASSANDRA-4237 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 1.0.0 Reporter: Jonathan Ellis Assignee: Yuki Morishita Priority: Minor Fix For: 1.2.0 Back in 0.8 we had a memtable_lifetime_in_minutes setting. We got rid of it in 1.0 when we added CASSANDRA-2427, which is a better way to ensure flushing on low-activity memtables. However, at the same time we also added the ability to disable durable writes. So it's entirely possible to configure a low-activity memtable, that isn't part of the commitlog. So, we should add back a memtable lifetime setting. An additional motive is pointed out by http://www.fsl.cs.sunysb.edu/~pshetty/socc11-gtssl.pdf: if you have a *high* activity columnfamily, and don't require absolute durability, the commitlog is redundant if you are flushing faster than the commitlog sync period. So, disabling durable writes but setting memtable lifetime to the same as the commitlog sync would be a reasonable optimization. Thus, when we add back memtable lifetime, I think we should measure it in seconds or possibly even milliseconds (to match commitlog_sync_period) rather than minutes. -- 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
[jira] [Updated] (CASSANDRA-4237) Add back 0.8-style memtable_lifetime feature
[ https://issues.apache.org/jira/browse/CASSANDRA-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-4237: -- Attachment: 4237.txt OK, this attached version schedules flush at Memtable creation when memtable_flush_period_in_ms is set, and it tries to keep flushing at the same interval after memtable is expired. Add back 0.8-style memtable_lifetime feature Key: CASSANDRA-4237 URL: https://issues.apache.org/jira/browse/CASSANDRA-4237 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 1.0.0 Reporter: Jonathan Ellis Assignee: Yuki Morishita Priority: Minor Fix For: 1.2.0 Attachments: 4237.txt Back in 0.8 we had a memtable_lifetime_in_minutes setting. We got rid of it in 1.0 when we added CASSANDRA-2427, which is a better way to ensure flushing on low-activity memtables. However, at the same time we also added the ability to disable durable writes. So it's entirely possible to configure a low-activity memtable, that isn't part of the commitlog. So, we should add back a memtable lifetime setting. An additional motive is pointed out by http://www.fsl.cs.sunysb.edu/~pshetty/socc11-gtssl.pdf: if you have a *high* activity columnfamily, and don't require absolute durability, the commitlog is redundant if you are flushing faster than the commitlog sync period. So, disabling durable writes but setting memtable lifetime to the same as the commitlog sync would be a reasonable optimization. Thus, when we add back memtable lifetime, I think we should measure it in seconds or possibly even milliseconds (to match commitlog_sync_period) rather than minutes. -- 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
git commit: Improve ORDER BY validation (CQL3)
Updated Branches:
refs/heads/cassandra-1.1 8e03f7bdf - 4177b58f1
Improve ORDER BY validation (CQL3)
patch by slebresne; reviewed by jbellis for CASSANDRA-4624
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4177b58f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4177b58f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4177b58f
Branch: refs/heads/cassandra-1.1
Commit: 4177b58f1099cb9f8de87b9432014b0afac90da0
Parents: 8e03f7b
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 6 17:42:40 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 6 17:42:40 2012 +0200
--
CHANGES.txt|2 ++
.../cassandra/cql3/statements/SelectStatement.java |4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4177b58f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6e72892..4a5bfe9 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,7 @@
1.1.6
* (cql3) fix potential NPE with both equal and unequal restriction
(CASSANDRA-4532)
+ * (cql3) improves ORDER BY validation (CASSANDRA-4624)
+
1.1.5
* add SecondaryIndex.reload API (CASSANDRA-4581)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4177b58f/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index dd00c5c..1d0918e 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -1070,8 +1070,8 @@ public class SelectStatement implements CQLStatement
if (!stmt.parameters.orderings.isEmpty())
{
-if (whereClause.isEmpty())
-throw new InvalidRequestException(ORDER BY is only
supported in combination with WHERE clause.);
+if (stmt.isKeyRange())
+throw new InvalidRequestException(ORDER BY is only
supported when the partition key is restricted by an EQ or an IN.);
Boolean[] reversedMap = new Boolean[cfDef.columns.size()];
int i = 0;
[2/4] git commit: Improve ORDER BY validation (CQL3)
Improve ORDER BY validation (CQL3)
patch by slebresne; reviewed by jbellis for CASSANDRA-4624
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4177b58f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4177b58f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4177b58f
Branch: refs/heads/trunk
Commit: 4177b58f1099cb9f8de87b9432014b0afac90da0
Parents: 8e03f7b
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 6 17:42:40 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 6 17:42:40 2012 +0200
--
CHANGES.txt|2 ++
.../cassandra/cql3/statements/SelectStatement.java |4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4177b58f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6e72892..4a5bfe9 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,7 @@
1.1.6
* (cql3) fix potential NPE with both equal and unequal restriction
(CASSANDRA-4532)
+ * (cql3) improves ORDER BY validation (CASSANDRA-4624)
+
1.1.5
* add SecondaryIndex.reload API (CASSANDRA-4581)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4177b58f/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index dd00c5c..1d0918e 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -1070,8 +1070,8 @@ public class SelectStatement implements CQLStatement
if (!stmt.parameters.orderings.isEmpty())
{
-if (whereClause.isEmpty())
-throw new InvalidRequestException(ORDER BY is only
supported in combination with WHERE clause.);
+if (stmt.isKeyRange())
+throw new InvalidRequestException(ORDER BY is only
supported when the partition key is restricted by an EQ or an IN.);
Boolean[] reversedMap = new Boolean[cfDef.columns.size()];
int i = 0;
[3/4] git commit: fix potential NPE with both equal and unequal restriction
fix potential NPE with both equal and unequal restriction patch by slebresne; reviewed by jbellis for CASSANDRA-4532 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8e03f7bd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8e03f7bd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8e03f7bd Branch: refs/heads/trunk Commit: 8e03f7bdf26558dc397628c885c5b6ab0cfde3e0 Parents: acaa524 Author: Sylvain Lebresne sylv...@datastax.com Authored: Thu Sep 6 16:56:29 2012 +0200 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Thu Sep 6 16:56:29 2012 +0200 -- CHANGES.txt|3 +++ .../cassandra/cql3/statements/SelectStatement.java |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8e03f7bd/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index b33b2c3..6e72892 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,6 @@ +1.1.6 + * (cql3) fix potential NPE with both equal and unequal restriction (CASSANDRA-4532) + 1.1.5 * add SecondaryIndex.reload API (CASSANDRA-4581) * use millis + atomicint for commitlog segment creation instead of http://git-wip-us.apache.org/repos/asf/cassandra/blob/8e03f7bd/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java -- diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java index 0c34eb0..dd00c5c 100644 --- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java +++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java @@ -1274,6 +1274,9 @@ public class SelectStatement implements CQLStatement break; } +if (bounds == null) +throw new InvalidRequestException(String.format(%s cannot be restricted by both an equal and an inequal relation, name)); + if (bounds[b.idx] != null) throw new InvalidRequestException(String.format(Invalid restrictions found on %s, name)); bounds[b.idx] = t;
[4/4] git commit: Update version, news, license, ... for 1.1.5 release
Update version, news, license, ... for 1.1.5 release
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/acaa5246
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/acaa5246
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/acaa5246
Branch: refs/heads/trunk
Commit: acaa52465554e82519fc312d3fcff586f55ee36e
Parents: 2cd7363
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 6 08:57:57 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Thu Sep 6 08:57:57 2012 +0200
--
CHANGES.txt|5
NEWS.txt | 18 +++
build.xml |2 +-
debian/changelog |6 +
.../db/columniterator/ISSTableColumnIterator.java | 18 +++
5 files changed, 48 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/acaa5246/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 04fa0bf..b33b2c3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -9,6 +9,11 @@
* Change nodetool setcachecapcity to manipulate global caches (CASSANDRA-4563)
* (cql3) fix setting compaction strategy (CASSANDRA-4597)
* fix broken system.schema_* timestamps on system startup (CASSANDRA-4561)
+ * fix wrong skip of cache saving (CASSANDRA-4533)
+ * Avoid NPE when lost+found is in data dir (CASSANDRA-4572)
+ * Respect five-minute flush moratorium after initial CL replay
(CASSANDRA-4474)
+ * Adds ntp as recommended in debian packaging (CASSANDRA-4606)
+ * Configurable transport in CF Record{Reader|Writer} (CASSANDRA-4558)
Merged from 1.0:
* increase Xss to 160k to accomodate latest 1.6 JVMs (CASSANDRA-4602)
* fix toString of hint destination tokens (CASSANDRA-4568)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/acaa5246/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index a127ead..ad22610 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -9,6 +9,24 @@ upgrade, just in case you need to roll back to the previous
version.
by version X, but the inverse is not necessarily the case.)
+1.1.5
+=
+
+Upgrading
+-
+- Nothing specific to this release, but please see 1.1 if you are upgrading
+ from a previous version.
+
+
+1.1.4
+=
+
+Upgrading
+-
+- Nothing specific to this release, but please see 1.1 if you are upgrading
+ from a previous version.
+
+
1.1.3
=
http://git-wip-us.apache.org/repos/asf/cassandra/blob/acaa5246/build.xml
--
diff --git a/build.xml b/build.xml
index 10dbecc..b498d12 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
property name=debuglevel value=source,lines,vars/
!-- default version and SCM information --
-property name=base.version value=1.1.4/
+property name=base.version value=1.1.5/
property name=scm.connection
value=scm:git://git.apache.org/cassandra.git/
property name=scm.developerConnection
value=scm:git://git.apache.org/cassandra.git/
property name=scm.url
value=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree/
http://git-wip-us.apache.org/repos/asf/cassandra/blob/acaa5246/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 9c6bfdc..8e6b389 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (1.1.5) unstable; urgency=low
+
+ * New release
+
+ -- Sylvain Lebresne slebre...@apache.org Thu, 06 Sep 2012 08:53:50 +0200
+
cassandra (1.1.4) unstable; urgency=low
* New release
http://git-wip-us.apache.org/repos/asf/cassandra/blob/acaa5246/src/java/org/apache/cassandra/db/columniterator/ISSTableColumnIterator.java
--
diff --git
a/src/java/org/apache/cassandra/db/columniterator/ISSTableColumnIterator.java
b/src/java/org/apache/cassandra/db/columniterator/ISSTableColumnIterator.java
index 4da4c0a..0b6a652 100644
---
a/src/java/org/apache/cassandra/db/columniterator/ISSTableColumnIterator.java
+++
b/src/java/org/apache/cassandra/db/columniterator/ISSTableColumnIterator.java
@@ -1,3 +1,21 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+
[1/4] git commit: Merge branch 'cassandra-1.1' into trunk
Updated Branches: refs/heads/trunk 0e3a9a55e - 42c55896b Merge branch 'cassandra-1.1' into trunk Conflicts: CHANGES.txt NEWS.txt build.xml Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/42c55896 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/42c55896 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/42c55896 Branch: refs/heads/trunk Commit: 42c55896b9b5e9f506eb009b28884108d6ad41ef Parents: 0e3a9a5 4177b58 Author: Sylvain Lebresne sylv...@datastax.com Authored: Thu Sep 6 17:54:17 2012 +0200 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Thu Sep 6 17:54:17 2012 +0200 -- CHANGES.txt|7 +- NEWS.txt | 18 +++ debian/changelog |6 + .../cassandra/cql3/statements/SelectStatement.java |7 - .../db/columniterator/ISSTableColumnIterator.java | 18 +++ 5 files changed, 53 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/42c55896/CHANGES.txt -- diff --cc CHANGES.txt index b08117d,4a5bfe9..ec4992c --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,56 -1,6 +1,56 @@@ - 1.2-dev -1.1.6 - * (cql3) fix potential NPE with both equal and unequal restriction (CASSANDRA-4532) - * (cql3) improves ORDER BY validation (CASSANDRA-4624) ++1.2-beta1 + * include message initiation time to replicas so they can more + accurately drop timed-out requests (CASSANDRA-2858) + * fix clientutil.jar dependencies (CASSANDRA-4566) + * optimize WriteResponse (CASSANDRA-4548) + * new metrics (CASSANDRA-4009) + * redesign KEYS indexes to avoid read-before-write (CASSANDRA-2897) + * debug tracing (CASSANDRA-1123) + * parallelize row cache loading (CASSANDRA-4282) + * Make compaction, flush JBOD-aware (CASSANDRA-4292) + * run local range scans on the read stage (CASSANDRA-3687) + * clean up ioexceptions (CASSANDRA-2116) + * add disk_failure_policy (CASSANDRA-2118) + * Introduce new json format with row level deletion (CASSANDRA-4054) + * remove redundant name column from schema_keyspaces (CASSANDRA-4433) + * improve nodetool ring handling of multi-dc clusters (CASSANDRA-3047) + * update NTS calculateNaturalEndpoints to be O(N log N) (CASSANDRA-3881) + * add UseCondCardMark XX jvm settings on jdk 1.7 (CASSANDRA-4366) + * split up rpc timeout by operation type (CASSANDRA-2819) + * rewrite key cache save/load to use only sequential i/o (CASSANDRA-3762) + * update MS protocol with a version handshake + broadcast address id + (CASSANDRA-4311) + * multithreaded hint replay (CASSANDRA-4189) + * add inter-node message compression (CASSANDRA-3127) + * remove COPP (CASSANDRA-2479) + * Track tombstone expiration and compact when tombstone content is + higher than a configurable threshold, default 20% (CASSANDRA-3442, 4234) + * update MurmurHash to version 3 (CASSANDRA-2975) + * (CLI) track elapsed time for `delete' operation (CASSANDRA-4060) + * (CLI) jline version is bumped to 1.0 to properly support + 'delete' key function (CASSANDRA-4132) + * Save IndexSummary into new SSTable 'Summary' component (CASSANDRA-2392, 4289) + * Add support for range tombstones (CASSANDRA-3708) + * Improve MessagingService efficiency (CASSANDRA-3617) + * Avoid ID conflicts from concurrent schema changes (CASSANDRA-3794) + * Set thrift HSHA server thread limit to unlimited by default (CASSANDRA-4277) + * Avoids double serialization of CF id in RowMutation messages + (CASSANDRA-4293) + * stream compressed sstables directly with java nio (CASSANDRA-4297) + * Support multiple ranges in SliceQueryFilter (CASSANDRA-3885) + * Add column metadata to system column families (CASSANDRA-4018) + * (cql3) Always use composite types by default (CASSANDRA-4329) + * (cql3) Add support for set, map and list (CASSANDRA-3647) + * Validate date type correctly (CASSANDRA-4441) + * (cql3) Allow definitions with only a PK (CASSANDRA-4361) + * (cql3) Add support for row key composites (CASSANDRA-4179) + * improve DynamicEndpointSnitch by using reservoir sampling (CASSANDRA-4038) + * (cql3) Add support for 2ndary indexes (CASSANDRA-3680) + * (cql3) fix defining more than one PK to be invalid (CASSANDRA-4477) + * remove schema agreement checking from all external APIs (Thrift, CQL and CQL3) (CASSANDRA-4487) + * add Murmur3Partitioner and make it default for new installations (CASSANDRA-3772) + * (cql3) update pseudo-map syntax to use map syntax (CASSANDRA-4497) + * Finer grained exceptions hierarchy and provides error code with exceptions (CASSANDRA-3979) 1.1.5
[jira] [Comment Edited] (CASSANDRA-4532) NPE when trying to select a slice from a composite table
[
https://issues.apache.org/jira/browse/CASSANDRA-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449764#comment-13449764
]
basanth gowda edited comment on CASSANDRA-4532 at 9/7/12 3:00 AM:
--
Sylvian,
Thanks for the fix, May be I should have opened the ticket differently. My main
issue is not that the connection on cqlsh was getting closed (because of NPE)
or exception being thrown in thrift client. To adopt CQL3 mainstream slice with
paging is need, I saw some other ticket, where this proposal was there.
Main reason I opened the ticket was for not being able to slice (rather no
syntax support for that, to continue where the last query left off). This is a
piece of code that was written using Hector and my assumption is the filtering
was done on server side. We are using this in production. I modified attributes
(to get rid of proprietary stuff, so may be broken, but should give an idea of
what I was trying to do with CQL3)
long cStartTime = 0L;
long startTime = System.nanoTime();
boolean fetchNextBatch = true;
int totalKeysFetched = 0;
String lastKeyFetched = null;
long cEndTime = Some Time in Millis;
while(fetchNextBatch) {
fetchNextBatch = false;
int pageSize = 3; //Just for demonstration
SliceQueryObject,DynamicComposite,String sliceQuery =
HFactory.createSliceQuery(keyspace,KEY
SERIALIZER,DynamicCompositeSerializer.get(),StringSerializer.get());
sliceQuery.setKey(C);
sliceQuery.setColumnFamily(SOME CF NAME);
DynamicComposite startRange = new DynamicComposite();
startRange.addComponent(cStartTime,LongSerializer.get()); //For
the first fetch - this will be 0L
startRange.addComponent(lastKeyFetched,StringSerializer.get());
// this will be null for first fetch
DynamicComposite endRange = new DynamicComposite();
endRange.addComponent(new Long(cEndTime), LongSerializer.get(),
LongType, AbstractComposite.ComponentEquality.LESS_THAN_EQUAL);
//Add another config if we need columnPageSize
sliceQuery.setRange(startRange,endRange,false,pageSize);
long start = System.nanoTime();
QueryResultColumnSliceDynamicComposite, String result =
sliceQuery.execute();
float t = (float)((System.nanoTime() - start)/100);
System.out.println(TIME FOR QUERY : + t + MILLI SECONDS);
ColumnSliceDynamicComposite, String cs = result.get();
ListHColumnDynamicComposite,String compositeList =
cs.getColumns();
for(int i =0;icompositeList.size();i++) {
HColumnDynamicComposite, String col =
compositeList.get(i);
cStartTime = col.getName().get(0,LongSerializer.get());
//This will be the cTime for the start range of the next query
lastKeyFetched =
col.getName().get(1,StringSerializer.get()); //In the start range for the next
query, this key will be used.
keyTimeMap.put(lastKeyFetched,scheduleStartTime);
totalKeysFetched ++;
}
//Process Fetched Data
fetchNextBatch = compositeList.size() == pageSize; // If the
number of records retrieved is equal to the page size, then there are probably
more records left
}
was (Author: basu76):
Sylvian,
Thanks for the fix, May be I should have opened the ticket differently. My main
issue is not that the connection on cqlsh was getting closed (because of NPE)
or exception being thrown in thrift client. To adopt CQL3 mainstream slice with
paging is need, I saw some other ticket, where this proposal was there.
Main reason I opened the ticket was for not being able to slice (rather no
syntax support for that, to continue where the last query left off). This is a
piece of code that was written using Hector and my assumption is the filtering
was done on server side. We are using this in production. I modified attributes
(to get rid of proprietary stuff, so may be broken, but should give an idea of
what I was trying to do with CQL3)
long cStartTime = 0L;
long startTime = System.nanoTime();
boolean fetchNextBatch = true;
int totalKeysFetched = 0;
String lastKeyFetched = null;
long cEndTime = Some Time in Millis;
while(fetchNextBatch) {
fetchNextBatch = false;
int pageSize = 3; //Just for demonstration
SliceQueryObject,DynamicComposite,String sliceQuery =
[jira] [Commented] (CASSANDRA-4532) NPE when trying to select a slice from a composite table
[
https://issues.apache.org/jira/browse/CASSANDRA-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449764#comment-13449764
]
basanth gowda commented on CASSANDRA-4532:
--
Sylvian,
Thanks for the fix, May be I should have opened the ticket differently. My main
issue is not that the connection on cqlsh was getting closed (because of NPE)
or exception being thrown in thrift client. To adopt CQL3 mainstream slice with
paging is need, I saw some other ticket, where this proposal was there.
Main reason I opened the ticket was for not being able to slice (rather no
syntax support for that, to continue where the last query left off). This is a
piece of code that was written using Hector and my assumption is the filtering
was done on server side. We are using this in production. I modified attributes
(to get rid of proprietary stuff, so may be broken, but should give an idea of
what I was trying to do with CQL3)
long cStartTime = 0L;
long startTime = System.nanoTime();
boolean fetchNextBatch = true;
int totalKeysFetched = 0;
String lastKeyFetched = null;
long cEndTime = Some Time in Millis;
while(fetchNextBatch) {
fetchNextBatch = false;
int pageSize = 3; //Just for demonstration
SliceQueryObject,DynamicComposite,String sliceQuery =
HFactory.createSliceQuery(keyspace,cassCFConfig.getKeySerializer(),DynamicCompositeSerializer.get(),StringSerializer.get());
sliceQuery.setKey(C);
sliceQuery.setColumnFamily(SOME CF NAME);
DynamicComposite startRange = new DynamicComposite();
startRange.addComponent(cStartTime,LongSerializer.get()); //For
the first fetch - this will be 0L
startRange.addComponent(lastKeyFetched,StringSerializer.get());
// this will be null for first fetch
DynamicComposite endRange = new DynamicComposite();
endRange.addComponent(new Long(cEndTime), LongSerializer.get(),
LongType, AbstractComposite.ComponentEquality.LESS_THAN_EQUAL);
//Add another config if we need columnPageSize
sliceQuery.setRange(startRange,endRange,false,pageSize);
long start = System.nanoTime();
QueryResultColumnSliceDynamicComposite, String result =
sliceQuery.execute();
float t = (float)((System.nanoTime() - start)/100);
System.out.println(TIME FOR QUERY : + t + MILLI SECONDS);
ColumnSliceDynamicComposite, String cs = result.get();
ListHColumnDynamicComposite,String compositeList =
cs.getColumns();
for(int i =0;icompositeList.size();i++) {
HColumnDynamicComposite, String col =
compositeList.get(i);
cStartTime = col.getName().get(0,LongSerializer.get());
//This will be the cTime for the start range of the next query
lastKeyFetched =
col.getName().get(1,StringSerializer.get()); //In the start range for the next
query, this key will be used.
keyTimeMap.put(lastKeyFetched,scheduleStartTime);
totalKeysFetched ++;
}
//Process Fetched Data
fetchNextBatch = compositeList.size() == pageSize; // If the
number of records retrieved is equal to the page size, then there are probably
more records left
}
NPE when trying to select a slice from a composite table
Key: CASSANDRA-4532
URL: https://issues.apache.org/jira/browse/CASSANDRA-4532
Project: Cassandra
Issue Type: Bug
Components: API, Core
Affects Versions: 1.1.3
Environment: Cassandra 1.1.3 (2 nodes) on a single host - mac osx
Reporter: basanth gowda
Assignee: Sylvain Lebresne
Priority: Minor
Labels: Slice, cql, cql3
Fix For: 1.1.6
Attachments: 4532.txt
I posted this question on StackOverflow, because i need a solution.
Created a table with :
{noformat}
create table compositetest(m_id ascii,i_id int,l_id ascii,body ascii, PRIMARY
KEY(m_id,i_id,l_id));
{noformat}
wanted to slice the results returned, so did something like below, not sure
if its the right way. The first one returns data perfectly as expected,
second one to get the next 3 columns closes the transport of my cqlsh
{noformat}
cqlsh:testkeyspace1 select * from compositetest where i_id=3 limit 3;
m_id | i_id | l_id | body
--+--+--+--
m1 |1 | l1 | b1
m1 |2 | l2 | b2
m2 |1 | l1 | b1
cqlsh:testkeyspace1 Was trying to write something for slice range.
TSocket read 0
[jira] [Comment Edited] (CASSANDRA-4532) NPE when trying to select a slice from a composite table
[
https://issues.apache.org/jira/browse/CASSANDRA-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449764#comment-13449764
]
basanth gowda edited comment on CASSANDRA-4532 at 9/7/12 3:01 AM:
--
Sylvain,
Thanks for the fix, May be I should have opened the ticket differently. My main
issue is not that the connection on cqlsh was getting closed (because of NPE)
or exception being thrown in thrift client. To adopt CQL3 mainstream slice with
paging is need, I saw some other ticket, where this proposal was there.
Main reason I opened the ticket was for not being able to slice (rather no
syntax support for that, to continue where the last query left off). This is a
piece of code that was written using Hector and my assumption is the filtering
was done on server side. We are using this in production. I modified attributes
(to get rid of proprietary stuff, so may be broken, but should give an idea of
what I was trying to do with CQL3)
long cStartTime = 0L;
long startTime = System.nanoTime();
boolean fetchNextBatch = true;
int totalKeysFetched = 0;
String lastKeyFetched = null;
long cEndTime = Some Time in Millis;
while(fetchNextBatch) {
fetchNextBatch = false;
int pageSize = 3; //Just for demonstration
SliceQueryObject,DynamicComposite,String sliceQuery =
HFactory.createSliceQuery(keyspace,KEY
SERIALIZER,DynamicCompositeSerializer.get(),StringSerializer.get());
sliceQuery.setKey(C);
sliceQuery.setColumnFamily(SOME CF NAME);
DynamicComposite startRange = new DynamicComposite();
startRange.addComponent(cStartTime,LongSerializer.get()); //For
the first fetch - this will be 0L
startRange.addComponent(lastKeyFetched,StringSerializer.get());
// this will be null for first fetch
DynamicComposite endRange = new DynamicComposite();
endRange.addComponent(new Long(cEndTime), LongSerializer.get(),
LongType, AbstractComposite.ComponentEquality.LESS_THAN_EQUAL);
//Add another config if we need columnPageSize
sliceQuery.setRange(startRange,endRange,false,pageSize);
long start = System.nanoTime();
QueryResultColumnSliceDynamicComposite, String result =
sliceQuery.execute();
float t = (float)((System.nanoTime() - start)/100);
System.out.println(TIME FOR QUERY : + t + MILLI SECONDS);
ColumnSliceDynamicComposite, String cs = result.get();
ListHColumnDynamicComposite,String compositeList =
cs.getColumns();
for(int i =0;icompositeList.size();i++) {
HColumnDynamicComposite, String col =
compositeList.get(i);
cStartTime = col.getName().get(0,LongSerializer.get());
//This will be the cTime for the start range of the next query
lastKeyFetched =
col.getName().get(1,StringSerializer.get()); //In the start range for the next
query, this key will be used.
keyTimeMap.put(lastKeyFetched,scheduleStartTime);
totalKeysFetched ++;
}
//Process Fetched Data
fetchNextBatch = compositeList.size() == pageSize; // If the
number of records retrieved is equal to the page size, then there are probably
more records left
}
was (Author: basu76):
Sylvian,
Thanks for the fix, May be I should have opened the ticket differently. My main
issue is not that the connection on cqlsh was getting closed (because of NPE)
or exception being thrown in thrift client. To adopt CQL3 mainstream slice with
paging is need, I saw some other ticket, where this proposal was there.
Main reason I opened the ticket was for not being able to slice (rather no
syntax support for that, to continue where the last query left off). This is a
piece of code that was written using Hector and my assumption is the filtering
was done on server side. We are using this in production. I modified attributes
(to get rid of proprietary stuff, so may be broken, but should give an idea of
what I was trying to do with CQL3)
long cStartTime = 0L;
long startTime = System.nanoTime();
boolean fetchNextBatch = true;
int totalKeysFetched = 0;
String lastKeyFetched = null;
long cEndTime = Some Time in Millis;
while(fetchNextBatch) {
fetchNextBatch = false;
int pageSize = 3; //Just for demonstration
SliceQueryObject,DynamicComposite,String sliceQuery =
HFactory.createSliceQuery(keyspace,KEY
[jira] [Created] (CASSANDRA-4625) ValidationExecutor Exception During Nodetool Repair
Jason Wellonen created CASSANDRA-4625: - Summary: ValidationExecutor Exception During Nodetool Repair Key: CASSANDRA-4625 URL: https://issues.apache.org/jira/browse/CASSANDRA-4625 Project: Cassandra Issue Type: Bug Environment: Cassandar v1.1.4, 4 nodes, 2 data centers, RF = 2 (each dc). RHEL 6.3 x86_64, Oracle Java 1.7.0_07 Reporter: Jason Wellonen Attachments: cassandraerror.txt After using the stress utility to create 10m rows in the Standard1 CF, I then started a nodetool -pr repair Keyspace1, which generated a ValidationExecutor expection (attached). CF description (25 columns): CREATE TABLE Standard1 ( KEY blob PRIMARY KEY ) WITH comment='' AND comparator=ascii AND read_repair_chance=0.10 AND gc_grace_seconds=864000 AND default_validation=blob AND min_compaction_threshold=4 AND max_compaction_threshold=32 AND replicate_on_write='false' AND compaction_strategy_class='LeveledCompactionStrategy' AND compaction_strategy_options:sstable_size_in_mb='5' AND compression_parameters:chunk_length_kb='64' AND compression_parameters:sstable_compression='SnappyCompressor'; -- 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
[jira] [Updated] (CASSANDRA-4625) ValidationExecutor Exception During Nodetool Repair
[ https://issues.apache.org/jira/browse/CASSANDRA-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Wellonen updated CASSANDRA-4625: -- Attachment: cassandraerror.txt ValidationExecutor Exception During Nodetool Repair --- Key: CASSANDRA-4625 URL: https://issues.apache.org/jira/browse/CASSANDRA-4625 Project: Cassandra Issue Type: Bug Environment: Cassandar v1.1.4, 4 nodes, 2 data centers, RF = 2 (each dc). RHEL 6.3 x86_64, Oracle Java 1.7.0_07 Reporter: Jason Wellonen Attachments: cassandraerror.txt After using the stress utility to create 10m rows in the Standard1 CF, I then started a nodetool -pr repair Keyspace1, which generated a ValidationExecutor expection (attached). CF description (25 columns): CREATE TABLE Standard1 ( KEY blob PRIMARY KEY ) WITH comment='' AND comparator=ascii AND read_repair_chance=0.10 AND gc_grace_seconds=864000 AND default_validation=blob AND min_compaction_threshold=4 AND max_compaction_threshold=32 AND replicate_on_write='false' AND compaction_strategy_class='LeveledCompactionStrategy' AND compaction_strategy_options:sstable_size_in_mb='5' AND compression_parameters:chunk_length_kb='64' AND compression_parameters:sstable_compression='SnappyCompressor'; -- 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
[jira] [Resolved] (CASSANDRA-4625) ValidationExecutor Exception During Nodetool Repair
[ https://issues.apache.org/jira/browse/CASSANDRA-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4625. --- Resolution: Duplicate fixed in CASSANDRA-4587 ValidationExecutor Exception During Nodetool Repair --- Key: CASSANDRA-4625 URL: https://issues.apache.org/jira/browse/CASSANDRA-4625 Project: Cassandra Issue Type: Bug Environment: Cassandar v1.1.4, 4 nodes, 2 data centers, RF = 2 (each dc). RHEL 6.3 x86_64, Oracle Java 1.7.0_07 Reporter: Jason Wellonen Attachments: cassandraerror.txt After using the stress utility to create 10m rows in the Standard1 CF, I then started a nodetool -pr repair Keyspace1, which generated a ValidationExecutor expection (attached). CF description (25 columns): CREATE TABLE Standard1 ( KEY blob PRIMARY KEY ) WITH comment='' AND comparator=ascii AND read_repair_chance=0.10 AND gc_grace_seconds=864000 AND default_validation=blob AND min_compaction_threshold=4 AND max_compaction_threshold=32 AND replicate_on_write='false' AND compaction_strategy_class='LeveledCompactionStrategy' AND compaction_strategy_options:sstable_size_in_mb='5' AND compression_parameters:chunk_length_kb='64' AND compression_parameters:sstable_compression='SnappyCompressor'; -- 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
[jira] [Commented] (CASSANDRA-4532) NPE when trying to select a slice from a composite table
[
https://issues.apache.org/jira/browse/CASSANDRA-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449799#comment-13449799
]
Sylvain Lebresne commented on CASSANDRA-4532:
-
@basanth Slices are definitely supported in CQL3, the query I gave you earlier
involves a slice for instance. In a fair amount of cases, paging within a
Cassandra row is also pretty simple to do in CQL3 too. It is true that in some
cases it's not completely as easy as in thrift. For those last cases,
CASSANDRA-4415 should provide a solution.
If you questions on how to translate some piece thrift code to CQL3, you're
definitively welcome to ask them but please use the user mailing list for such
inquiries.
NPE when trying to select a slice from a composite table
Key: CASSANDRA-4532
URL: https://issues.apache.org/jira/browse/CASSANDRA-4532
Project: Cassandra
Issue Type: Bug
Components: API, Core
Affects Versions: 1.1.3
Environment: Cassandra 1.1.3 (2 nodes) on a single host - mac osx
Reporter: basanth gowda
Assignee: Sylvain Lebresne
Priority: Minor
Labels: Slice, cql, cql3
Fix For: 1.1.6
Attachments: 4532.txt
I posted this question on StackOverflow, because i need a solution.
Created a table with :
{noformat}
create table compositetest(m_id ascii,i_id int,l_id ascii,body ascii, PRIMARY
KEY(m_id,i_id,l_id));
{noformat}
wanted to slice the results returned, so did something like below, not sure
if its the right way. The first one returns data perfectly as expected,
second one to get the next 3 columns closes the transport of my cqlsh
{noformat}
cqlsh:testkeyspace1 select * from compositetest where i_id=3 limit 3;
m_id | i_id | l_id | body
--+--+--+--
m1 |1 | l1 | b1
m1 |2 | l2 | b2
m2 |1 | l1 | b1
cqlsh:testkeyspace1 Was trying to write something for slice range.
TSocket read 0 bytes
{noformat}
Is there a way to achieve what I am doing here, it would be good if some
meaning ful error is sent back, instead of cqlsh closing the transport.
On the server side I see the following error.
{noformat}
ERROR [Thrift:3] 2012-08-12 15:15:24,414 CustomTThreadPoolServer.java (line
204) Error occurred during processing of message.
java.lang.NullPointerException
at
org.apache.cassandra.cql3.statements.SelectStatement$Restriction.setBound(SelectStatement.java:1277)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.updateRestriction(SelectStatement.java:1151)
at
org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1001)
at
org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:215)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1237)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
{noformat}
With ThriftClient I get :
{noformat}
org.apache.thrift.transport.TTransportException
at
org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
at
org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:129)
at
org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:101)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
at
org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:378)
at
org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:297)
at
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:204)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:69)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_execute_cql_query(Cassandra.java:1402)
at
[Cassandra Wiki] Update of ThirdPartySupport by TylerHobbs
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The ThirdPartySupport page has been changed by TylerHobbs:
http://wiki.apache.org/cassandra/ThirdPartySupport?action=diffrev1=35rev2=36
Comment:
Update datastax logo to the latest version
{{http://www.acunu.com/uploads/1/1/5/5/11559475/1335714080.png}}
[[http://www.acunu.com|Acunu]] are world experts in Apache Cassandra and
beyond. Some of the most challenging Cassandra deployments already rely on
Acunu's technology, training and support. The Acunu Data Platform supercharges
and simplifies Apache Cassandra -- it's business-ready, deploys out-of-the box
and offers rock-solid performance and reliability.
[[http://www.acunu.com/products/choosing-cassandra/|Get a 90-day free trial]]
and [[http://www.acunu.com/products/choosing-cassandra/|find out more]].
- {{http://www.datastax.com/sites/all/themes/datastax20110201/logo.png}}
[[http://datastax.com|Datastax]], the commercial leader in Apache Cassandra™
offers products and services that make it easy for customers to build, deploy
and operate elastically scalable and cloud-optimized applications and data
services. [[http://datastax.com|DataStax]] has over 100 customers, including
leaders such as Netflix, Cisco, Rackspace, HP, Constant Contact and
[[http://www.datastax.com/cassandrausers|more]], and spanning verticals
including web, financial services, telecommunications, logistics and government.
+ {{http://www.datastax.com/wp-content/themes/datastax-custom/images/logo.png}}
[[http://datastax.com|Datastax]], the commercial leader in Apache Cassandra™
offers products and services that make it easy for customers to build, deploy
and operate elastically scalable and cloud-optimized applications and data
services. [[http://datastax.com|DataStax]] has over 100 customers, including
leaders such as Netflix, Cisco, Rackspace, HP, Constant Contact and
[[http://www.datastax.com/cassandrausers|more]], and spanning verticals
including web, financial services, telecommunications, logistics and government.
Other companies:
[jira] [Commented] (CASSANDRA-4612) cql error with ORDER BY when using IN
[
https://issues.apache.org/jira/browse/CASSANDRA-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449823#comment-13449823
]
Sylvain Lebresne commented on CASSANDRA-4612:
-
I believe that removing the Order by currently only support the ordering of
columns following their declared order in the PRIMARY KEY is buggy because it
still doesn't work in the case where the key restriction is an EQ (i.e. not an
IN). That is, we can remove it but in that case we must change the condition at
the top of orderResults() so that we go through the 'CompositeComparator' path
if the keyRestriction is an EQ and the requested orderings are not in the same
order that in the PK definition. Not a bad idea though.
Some minor nits:
* We can provide the size when allocating the typesWithPositions list. I would
have split typesWithPositions in two lists as this reduce the number of
allocation needed (because you avoid all the Pair but also because you can use
int[] for the positions) and in that case wouldn't really complicate the code
anyway.
* In getColumnPositionInSelect, we could use a by-index for loop and directly
return the current index when we find the name. That way we can throw an
assertion if we didn't find the name at all since that shouldn't happen anyway
(tiny bonus: iteration by index on ArrayList is slightly cheaper as it avoids
the iterator allocation).
cql error with ORDER BY when using IN
-
Key: CASSANDRA-4612
URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.4
Environment: ubuntu, cassandra trunk (commit
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.6
Attachments: CASSANDRA-4612.patch
{code}
CREATE TABLE test(
my_id varchar,
col1 int,
value varchar,
PRIMARY KEY (my_id, col1)
);
INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}
The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly,
[jira] [Commented] (CASSANDRA-4612) cql error with ORDER BY when using IN
[
https://issues.apache.org/jira/browse/CASSANDRA-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449891#comment-13449891
]
Pavel Yaskevich commented on CASSANDRA-4612:
Looks like its's just not my day today, I will fix keyRestriction thing and
nits asap.
cql error with ORDER BY when using IN
-
Key: CASSANDRA-4612
URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.4
Environment: ubuntu, cassandra trunk (commit
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.6
Attachments: CASSANDRA-4612.patch
{code}
CREATE TABLE test(
my_id varchar,
col1 int,
value varchar,
PRIMARY KEY (my_id, col1)
);
INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}
The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
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
[jira] [Commented] (CASSANDRA-4104) Cassandra appears to hang when JNA enabled and heapsize free memory
[
https://issues.apache.org/jira/browse/CASSANDRA-4104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449975#comment-13449975
]
Martin Mokry commented on CASSANDRA-4104:
-
I have noticed if the memory is low enough 128M cheap VPS, nothing even gets
printed and no logs are created.
While cassandra-env.sh seems to check validity of configuration (HEAP_NEWSIZE
and MAX_HEAP_SIZE), maybe it should check for values that end up being so low
the system obviously cannot support cassandra.
Cassandra appears to hang when JNA enabled and heapsize free memory
-
Key: CASSANDRA-4104
URL: https://issues.apache.org/jira/browse/CASSANDRA-4104
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.8
Reporter: Joaquin Casares
Priority: Minor
Labels: datastax_qa
When JNA is enabled heapsize is larger than free memory, all that is printed
out is the classpath, then the printouts stop.
If you hit enter again, you get the commandline, but no Cassandra process is
running.
Tested on both OpenJDK and Oracle Java.
{noformat}
datastax@datastax-image:~/repos/cassandra$ free -m
total used free sharedbuffers cached
Mem: 2008740 1267 0 3 54
-/+ buffers/cache:682 1326
Swap:0 0 0
datastax@datastax-image:~/repos/cassandra$ sudo bin/cassandra
datastax@datastax-image:~/repos/cassandra$ INFO 14:31:32,520 Logging
initialized
INFO 14:31:32,533 JVM vendor/version: Java HotSpot(TM) 64-Bit Server
VM/1.6.0_31
INFO 14:31:32,534 Heap size: 1247805440/1247805440
INFO 14:31:32,534 Classpath:
bin/../conf:bin/../build/classes/main:bin/../build/classes/thrift:bin/../lib/antlr-3.2.jar:bin/../lib/avro-1.4.0-fixes.jar:bin/../lib/avro-1.4.0-sources-fixes.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/compress-lzf-0.8.4.jar:bin/../lib/concurrentlinkedhashmap-lru-1.2.jar:bin/../lib/guava-r08.jar:bin/../lib/high-scale-lib-1.1.2.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jamm-0.2.5.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/jna.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/libthrift-0.6.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.6.1.jar:bin/../lib/slf4j-log4j12-1.6.1.jar:bin/../lib/snakeyaml-1.6.jar:bin/../lib/snappy-java-1.0.4.1.jar:bin/../lib/jamm-0.2.5.jar
datastax@datastax-image:~/repos/cassandra$ ps auwx | grep cass
datastax 18374 1.0 0.0 13448 904 pts/2S+ 14:32 0:00 grep
--color=auto cass
{noformat}
--
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
[jira] [Commented] (CASSANDRA-4237) Add back 0.8-style memtable_lifetime feature
[ https://issues.apache.org/jira/browse/CASSANDRA-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449984#comment-13449984 ] Jonathan Ellis commented on CASSANDRA-4237: --- Hmm, I think this means that if perform a scheduled forceFlush but it's clean, we don't schedule another flush attempt. Maybe brute force every 10s isn't so bad? Bonus: accomodates changing the period via mbean for free (which we should allow), without having to try to retrieve a ScheduledTask and cancel it. Add back 0.8-style memtable_lifetime feature Key: CASSANDRA-4237 URL: https://issues.apache.org/jira/browse/CASSANDRA-4237 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 1.0.0 Reporter: Jonathan Ellis Assignee: Yuki Morishita Priority: Minor Fix For: 1.2.0 Attachments: 4237.txt Back in 0.8 we had a memtable_lifetime_in_minutes setting. We got rid of it in 1.0 when we added CASSANDRA-2427, which is a better way to ensure flushing on low-activity memtables. However, at the same time we also added the ability to disable durable writes. So it's entirely possible to configure a low-activity memtable, that isn't part of the commitlog. So, we should add back a memtable lifetime setting. An additional motive is pointed out by http://www.fsl.cs.sunysb.edu/~pshetty/socc11-gtssl.pdf: if you have a *high* activity columnfamily, and don't require absolute durability, the commitlog is redundant if you are flushing faster than the commitlog sync period. So, disabling durable writes but setting memtable lifetime to the same as the commitlog sync would be a reasonable optimization. Thus, when we add back memtable lifetime, I think we should measure it in seconds or possibly even milliseconds (to match commitlog_sync_period) rather than minutes. -- 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
[jira] [Commented] (CASSANDRA-4104) Cassandra appears to hang when JNA enabled and heapsize free memory
[
https://issues.apache.org/jira/browse/CASSANDRA-4104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449986#comment-13449986
]
Brandon Williams commented on CASSANDRA-4104:
-
bq. nothing even gets printed and no logs are created
Are you running {{bin/cassandra -f}} or just {{bin/cassandra}}?
Cassandra appears to hang when JNA enabled and heapsize free memory
-
Key: CASSANDRA-4104
URL: https://issues.apache.org/jira/browse/CASSANDRA-4104
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.8
Reporter: Joaquin Casares
Priority: Minor
Labels: datastax_qa
When JNA is enabled heapsize is larger than free memory, all that is printed
out is the classpath, then the printouts stop.
If you hit enter again, you get the commandline, but no Cassandra process is
running.
Tested on both OpenJDK and Oracle Java.
{noformat}
datastax@datastax-image:~/repos/cassandra$ free -m
total used free sharedbuffers cached
Mem: 2008740 1267 0 3 54
-/+ buffers/cache:682 1326
Swap:0 0 0
datastax@datastax-image:~/repos/cassandra$ sudo bin/cassandra
datastax@datastax-image:~/repos/cassandra$ INFO 14:31:32,520 Logging
initialized
INFO 14:31:32,533 JVM vendor/version: Java HotSpot(TM) 64-Bit Server
VM/1.6.0_31
INFO 14:31:32,534 Heap size: 1247805440/1247805440
INFO 14:31:32,534 Classpath:
bin/../conf:bin/../build/classes/main:bin/../build/classes/thrift:bin/../lib/antlr-3.2.jar:bin/../lib/avro-1.4.0-fixes.jar:bin/../lib/avro-1.4.0-sources-fixes.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/compress-lzf-0.8.4.jar:bin/../lib/concurrentlinkedhashmap-lru-1.2.jar:bin/../lib/guava-r08.jar:bin/../lib/high-scale-lib-1.1.2.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jamm-0.2.5.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/jna.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/libthrift-0.6.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.6.1.jar:bin/../lib/slf4j-log4j12-1.6.1.jar:bin/../lib/snakeyaml-1.6.jar:bin/../lib/snappy-java-1.0.4.1.jar:bin/../lib/jamm-0.2.5.jar
datastax@datastax-image:~/repos/cassandra$ ps auwx | grep cass
datastax 18374 1.0 0.0 13448 904 pts/2S+ 14:32 0:00 grep
--color=auto cass
{noformat}
--
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
[jira] [Commented] (CASSANDRA-4578) Dead lock in mutation stage when many concurrent writes to few columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13449997#comment-13449997
]
Jonathan Ellis commented on CASSANDRA-4578:
---
Would prefer to have the callback final in constructor to make it more clear
that it doesn't get changed during processing, otherwise +1
Dead lock in mutation stage when many concurrent writes to few columns
--
Key: CASSANDRA-4578
URL: https://issues.apache.org/jira/browse/CASSANDRA-4578
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.0
Environment: 15 cassandra instances
CentOS5
8 Core 64GB Memory
java version 1.6.0_33
Java(TM) SE Runtime Environment (build 1.6.0_33-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode)
Reporter: Suguru Namura
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.1.6
Attachments: 4578.txt, threaddump-1344957574788.tdump
When I send many request to increment counters to few counter columns,
sometimes mutation stage cause dead lock. When it happened, all of mutation
threads are locked and do not accept updates any more.
{noformat}
MutationStage:432 - Thread t@1389
java.lang.Thread.State: TIMED_WAITING
at java.lang.Object.wait(Native Method)
- waiting on b90b45b (a org.apache.cassandra.utils.SimpleCondition)
at java.lang.Object.wait(Object.java:443)
at java.util.concurrent.TimeUnit.timedWait(TimeUnit.java:292)
at
org.apache.cassandra.utils.SimpleCondition.await(SimpleCondition.java:54)
at
org.apache.cassandra.service.AbstractWriteResponseHandler.get(AbstractWriteResponseHandler.java:55)
at
org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:51)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- locked 4b1b0a6f (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
{noformat}
--
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
[jira] [Commented] (CASSANDRA-4493) Fix update of CF comparator (including adding new collections)
[ https://issues.apache.org/jira/browse/CASSANDRA-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450005#comment-13450005 ] Jonathan Ellis commented on CASSANDRA-4493: --- +1 Fix update of CF comparator (including adding new collections) -- Key: CASSANDRA-4493 URL: https://issues.apache.org/jira/browse/CASSANDRA-4493 Project: Cassandra Issue Type: Bug Components: Core Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 1.2.0 Attachments: 0001-Flush-after-CFStore-reload.txt, 0002-Fix-ALTER-logic.txt Updating the comparator of a column family (which is authorized if the new comparator is compatible with the old one, and that includes adding a new component to a CompositeType, or adding a new collection to a CQL3 table) doesn't completely work. The problem is that even if we change the comparator in CFMetada, the old comparator will still be aliased by the current memtable. This means updates (that expect the new comparator) will fail until a new memtable is created. -- 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
[jira] [Updated] (CASSANDRA-4612) cql error with ORDER BY when using IN
[
https://issues.apache.org/jira/browse/CASSANDRA-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4612:
---
Attachment: CASSANDRA-4612-v2.patch
v2 with nits fixed and order restriction reverted to original state after
discussion with Jonathan.
cql error with ORDER BY when using IN
-
Key: CASSANDRA-4612
URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.4
Environment: ubuntu, cassandra trunk (commit
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.6
Attachments: CASSANDRA-4612.patch, CASSANDRA-4612-v2.patch
{code}
CREATE TABLE test(
my_id varchar,
col1 int,
value varchar,
PRIMARY KEY (my_id, col1)
);
INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}
The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
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
[jira] [Created] (CASSANDRA-4626) Multiple values for CurrentLocal Node ID
Aaron Morton created CASSANDRA-4626:
---
Summary: Multiple values for CurrentLocal Node ID
Key: CASSANDRA-4626
URL: https://issues.apache.org/jira/browse/CASSANDRA-4626
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.11
Reporter: Aaron Morton
From this email thread
http://www.mail-archive.com/user@cassandra.apache.org/msg24677.html
There are multiple columns for the CurrentLocal row in NodeIdInfo:
{noformat}
[default@system] list NodeIdInfo ;
Using default limit of 100
...
---
RowKey: 43757272656e744c6f63616c
= (column=01efa5d0-e133-11e1--51be601cd0ff, value=0a1020d2,
timestamp=1344414498989)
= (column=92109b80-ea0a-11e1--51be601cd0af, value=0a1020d2,
timestamp=1345386691897)
{noformat}
SystemTable.getCurrentLocalNodeId() throws an assertion that occurs when the
static constructor for o.a.c.utils.NodeId is in the stack.
The impact is a java.lang.NoClassDefFoundError when accessing a particular CF
(I assume on with counters) on a particular node.
Cannot see an obvious cause in the code.
--
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
[jira] [Updated] (CASSANDRA-3929) Support row size limits
[ https://issues.apache.org/jira/browse/CASSANDRA-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-3929: Attachment: 3929_b.txt retain the columns at the front of the row. This patch needs to add tombstoning of columns on flush as well, as suggested by jbellis. (in progress) Support row size limits --- Key: CASSANDRA-3929 URL: https://issues.apache.org/jira/browse/CASSANDRA-3929 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Dave Brosius Priority: Minor Labels: ponies Fix For: 1.2.1 Attachments: 3929_b.txt, 3929.txt We currently support expiring columns by time-to-live; we've also had requests for keeping the most recent N columns in a row. -- 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
[jira] [Updated] (CASSANDRA-3929) Support row size limits
[ https://issues.apache.org/jira/browse/CASSANDRA-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-3929: Attachment: 3929_c.txt Support row size limits --- Key: CASSANDRA-3929 URL: https://issues.apache.org/jira/browse/CASSANDRA-3929 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Dave Brosius Priority: Minor Labels: ponies Fix For: 1.2.1 Attachments: 3929_b.txt, 3929_c.txt, 3929.txt We currently support expiring columns by time-to-live; we've also had requests for keeping the most recent N columns in a row. -- 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
[jira] [Commented] (CASSANDRA-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450196#comment-13450196 ] paul cannon commented on CASSANDRA-4480: Okay, everything looks good at this point, except that when I stop an existing node and start it again, I still receive a TOPOLOGY_CHANGE - NEW_NODE event after the two STATUS_CHANGE - UP events, even though the up'd node was previously known. Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 Attachments: 4480.txt, 4480-v2.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- 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
[jira] [Commented] (CASSANDRA-3979) Consider providing error code with exceptions (and documenting them)
[ https://issues.apache.org/jira/browse/CASSANDRA-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450225#comment-13450225 ] paul cannon commented on CASSANDRA-3979: Ok to close this one? Consider providing error code with exceptions (and documenting them) Key: CASSANDRA-3979 URL: https://issues.apache.org/jira/browse/CASSANDRA-3979 Project: Cassandra Issue Type: Sub-task Components: API Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Labels: cql3 Fix For: 1.2.0 beta 1 It could be a good idea to assign documented error code for the different exception raised. Currently, one may have to parse the exception string (say if one wants to know if its 'create keyspace' failed because the keyspace already exists versus other kind of exception), but it means we cannot improve the error message at the risk of breaking client code. Adding documented error codes with the message would avoid this. -- 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
[jira] [Updated] (CASSANDRA-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-4542: - Attachment: (was: CASSANDRA-4542-4543-4544.patch) add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- 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
[jira] [Updated] (CASSANDRA-3929) Support row size limits
[ https://issues.apache.org/jira/browse/CASSANDRA-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-3929: Attachment: (was: 3929_c.txt) Support row size limits --- Key: CASSANDRA-3929 URL: https://issues.apache.org/jira/browse/CASSANDRA-3929 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Dave Brosius Priority: Minor Labels: ponies Fix For: 1.2.1 Attachments: 3929_b.txt, 3929_c.txt, 3929.txt We currently support expiring columns by time-to-live; we've also had requests for keeping the most recent N columns in a row. -- 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
[jira] [Updated] (CASSANDRA-3929) Support row size limits
[ https://issues.apache.org/jira/browse/CASSANDRA-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-3929: Attachment: 3929_c.txt Support row size limits --- Key: CASSANDRA-3929 URL: https://issues.apache.org/jira/browse/CASSANDRA-3929 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 1.2.1 Reporter: Jonathan Ellis Assignee: Dave Brosius Priority: Minor Labels: ponies Fix For: 1.2.1 Attachments: 3929_b.txt, 3929_c.txt, 3929.txt We currently support expiring columns by time-to-live; we've also had requests for keeping the most recent N columns in a row. -- 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
[jira] [Updated] (CASSANDRA-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-4542: - Attachment: CASSANDRA-4542-4543-4544-v2.patch add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 Attachments: CASSANDRA-4542-4543-4544-v2.patch atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- 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
[jira] [Commented] (CASSANDRA-4539) potential backwards incompatibility in native protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450286#comment-13450286
]
paul cannon commented on CASSANDRA-4539:
+1.
potential backwards incompatibility in native protocol
--
Key: CASSANDRA-4539
URL: https://issues.apache.org/jira/browse/CASSANDRA-4539
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Assignee: Sylvain Lebresne
Priority: Minor
Labels: cql, native_protocol
Fix For: 1.2.0 beta 1
Attachments: 4539.txt
In the text of the native_protocol.spec document, it explains the format for
a notation called {{[option]}}, which should represent {{a pair of
idvalue}}.
In doing a first-draft implementation of the protocol for the python driver,
though, I found that I had a misunderstanding. I read that section as saying
that {{value}} was a {{[value]}}, and that it could have a length of 0
(i.e., the {{[int]}} on the front of the {{[value]}} could be 0). However, it
turns out that {{value}} might not be there at all, or might be *two*
{{[value]}}'s, depending on the option id and message context.
I'm not a fan of this, since
* A protocol parsing library can't simply implement a single function to
read in {{[option]}}'s, since the length of the value part is dependent on
the message context
* If we add a new native data type (a new option id which could be used
inside a {{col_spec_i}} in a RESULT message), then older clients will not
know how to read past the value part. Of course they won't know how to
interpret the data or deserialize later rows of that unknown type - that's
not the problem - the problem is that the older client should be able just to
mark that column as unparseable and still handle the rest of the columns.
Can we make {{value}} be a {{[value]}}, the contents of which can be
re-interpreted as a {{[string]}}, an {{[option]}}, two {{[option]}}'s, or
whatever?
--
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
[jira] [Resolved] (CASSANDRA-4582) in cqlsh the output of describe columnfamily doesn't convert to hex
[ https://issues.apache.org/jira/browse/CASSANDRA-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon resolved CASSANDRA-4582. Resolution: Won't Fix I'd like to implement this fix, but it's a little less trivial than it sounds to do this in a general way for all comparator classes- cqlsh needs to decode the binary column names according to the comparator class (easy), and then translate the native python values back into a textual format that CQL will parse correctly for a value of the original class (not as easy). The machinery to do that sort of thing is in the trunk (1.2) branch, but it's not in 1.1, and since this only applies to certain cql2 cases, it doesn't seem like it would be as useful to put only in cassandra 1.2. Affecting the usefulness even further is the fact that it seems to be rare to put explicit column names in a cfdef's column_metadata when the column names use a non-textual comparator type (where one usually uses wide rows, not pre-defined columns). I could backport the more powerful translation machinery to 1.1, but it would aggravate the already-somewhat-hairy merging situation for cqlsh. We could also just make this change for comparator=blob and not for the others, but it doesn't seem clear to me that this would be any more useful for blob than, say, timeuuid or float or whatever. Therefore, I'll close this ticket for now; if anyone still feels strongly about the need and has more convincing input on use cases, we can open it back up. in cqlsh the output of describe columnfamily doesn't convert to hex --- Key: CASSANDRA-4582 URL: https://issues.apache.org/jira/browse/CASSANDRA-4582 Project: Cassandra Issue Type: Bug Reporter: Jeremy Hanna Assignee: paul cannon Priority: Minor Labels: cqlsh When the comparator=blob, cqlsh is outputting the metadata for column names in utf8. Instead it should output them in hex because that's what will make it so its output can be used to re-create the column family. Granted it's going to be pretty unreadable for the user, but it will work to re-create the CF. -- 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
[jira] [Updated] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4594:
---
Fix Version/s: (was: 1.2.0)
1.1.6
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
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
[jira] [Commented] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450322#comment-13450322
]
paul cannon commented on CASSANDRA-4594:
Seems worth it to fix this in the 1.1 branch too.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
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
[jira] [Comment Edited] (CASSANDRA-4582) in cqlsh the output of describe columnfamily doesn't convert to hex
[ https://issues.apache.org/jira/browse/CASSANDRA-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450325#comment-13450325 ] Jeremy Hanna edited comment on CASSANDRA-4582 at 9/7/12 3:05 PM: - Yeah. If it's that much work then don't worry about it. Sounds like it's already addressed in a newer version. was (Author: jeromatron): Yeah. If its that much work then don't worry about it. Sounds like it's already addressed in a newer version. in cqlsh the output of describe columnfamily doesn't convert to hex --- Key: CASSANDRA-4582 URL: https://issues.apache.org/jira/browse/CASSANDRA-4582 Project: Cassandra Issue Type: Bug Reporter: Jeremy Hanna Assignee: paul cannon Priority: Minor Labels: cqlsh When the comparator=blob, cqlsh is outputting the metadata for column names in utf8. Instead it should output them in hex because that's what will make it so its output can be used to re-create the column family. Granted it's going to be pretty unreadable for the user, but it will work to re-create the CF. -- 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
[jira] [Commented] (CASSANDRA-4582) in cqlsh the output of describe columnfamily doesn't convert to hex
[ https://issues.apache.org/jira/browse/CASSANDRA-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450325#comment-13450325 ] Jeremy Hanna commented on CASSANDRA-4582: - Yeah. If its that much work then don't worry about it. Sounds like it's already addressed in a newer version. in cqlsh the output of describe columnfamily doesn't convert to hex --- Key: CASSANDRA-4582 URL: https://issues.apache.org/jira/browse/CASSANDRA-4582 Project: Cassandra Issue Type: Bug Reporter: Jeremy Hanna Assignee: paul cannon Priority: Minor Labels: cqlsh When the comparator=blob, cqlsh is outputting the metadata for column names in utf8. Instead it should output them in hex because that's what will make it so its output can be used to re-create the column family. Granted it's going to be pretty unreadable for the user, but it will work to re-create the CF. -- 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
[jira] [Created] (CASSANDRA-4627) support inet data type
paul cannon created CASSANDRA-4627: -- Summary: support inet data type Key: CASSANDRA-4627 URL: https://issues.apache.org/jira/browse/CASSANDRA-4627 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Fix For: 1.2.0 CASSANDRA-4018 introduced a new cassandra data type with a cql name inet, which is not yet supported in cqlsh. Add support for decoding and formatting. -- 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
