[jira] [Commented] (CASSANDRA-4775) Counters 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13701847#comment-13701847 ] Sylvain Lebresne commented on CASSANDRA-4775: - bq. read-before-write is inherent in the 1.0 design That's true, and that's annoying. That being said, I think the fact that today CL.ONE lies about doing a read-before-write is probably a good part of what end up surprising people. Besides, I'll admit that I remain to be convinced about the performance of doing one column per write with on-read merging (as as been suggested for a replacement). It will clearly be faster on writes, but performance on read remains to be seen (I'm particularly afraid of everything run fines in testing, but I go in production, some counters gets more load than expected and now the read performance on those goes through the roof). But yes, read-before-write is a PITA and somewhat anti-Cassandra. bq. but idempotence internally is very handy I couldn't agree more, and that's my biggest problem with the current implementation (and as always be really). But just in case that wasn't clear, the whole goal of the band aid (as you call it) I'm mentioning would to restore internal idempotence. So that problem is *not* inherent to counters 1.0. Counters 2.0 Key: CASSANDRA-4775 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Arya Goudarzi Assignee: Aleksey Yeschenko Labels: counters Fix For: 2.1 The existing partitioned counters remain a source of frustration for most users almost two years after being introduced. The remaining problems are inherent in the design, not something that can be fixed given enough time/eyeballs. Ideally a solution would give us - similar performance - less special cases in the code - potential for a retry mechanism -- 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-5619) CAS UPDATE for a lost race: save round trip by returning column values
[
https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13701868#comment-13701868
]
Sylvain Lebresne commented on CASSANDRA-5619:
-
bq. Could we do timestamp(column) and ttl(column), including literal
parentheses, where column is the name of the column involved?
In the case I'm talking about, there isn't a specific column involved (or
rather there could be more than one). The one I'm talking about is
if you do:
{noformat}
UPDATE foo USING TTL ? SET c1=2, c2=3,
{noformat}
In that case the TTL applies to all the columns. And so in that case we
currently return [ttl] (with the square bracket btw) as name for the first
prepared marked.
bq. These would not be legal column names
Actually, they would. Provided you double quote a column name, we're pretty
permissive about what it can be: it can be anything really, and timestamp()
is as much legal than [timestamp].
This does is a problem somewhat, don't get me wrong. Even ignoring the
timestamp/ttl in prepared statements, if you do:
{noformat}
SELECT writeTime(c), writeTime(c) FROM foo;
{noformat}
we'll return a resultSet where both column with the string writeTime(c) as
identifier, and the only way to distinguish between the arguably weird column
name and the function call is by position in the result set.
But so far we've somewhat dodged that issue saying that you really have to be
looking for trouble to run into this, and that you still can rely on positions
in the result set anyway. We could probably disambiguate this, though so far
I've wondered if it was worth the trouble really.
Anyway, that's somewhat unrelated to this issue but wanted to be complete.
CAS UPDATE for a lost race: save round trip by returning column values
--
Key: CASSANDRA-5619
URL: https://issues.apache.org/jira/browse/CASSANDRA-5619
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 2.0 beta 1
Reporter: Blair Zajac
Assignee: Sylvain Lebresne
Fix For: 2.0 beta 1
Attachments: 0001-Add-back-boolean-result-column.txt,
5619_thrift_fixup.txt, 5619.txt
Looking at the new CAS CQL3 support examples [1], if one lost a race for an
UPDATE, to save a round trip to get the current values to decide if you need
to perform your work, could the columns that were used in the IF clause also
be returned to the caller? Maybe the columns values as part of the SET part
could also be returned.
I don't know if this is generally useful though.
In the case of creating a new user account with a given username which is the
partition key, if one lost the race to another person creating an account
with the same username, it doesn't matter to the loser what the column values
are, just that they lost.
I'm new to Cassandra, so maybe there's other use cases, such as doing
incremental amount of work on a row. In pure Java projects I've done while
loops around AtomicReference.html#compareAndSet() until the work was done on
the referenced object to handle multiple threads each making forward progress
in updating the references object.
[1] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044
--
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-5619) CAS UPDATE for a lost race: save round trip by returning column values
[ https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13701874#comment-13701874 ] Sylvain Lebresne commented on CASSANDRA-5619: - So using exceptions for this actually has some practical backward compatibility problem: we can't really add a new exception to the native protocol v1. And unfortunately there isn't an existing exception that would work very well. It's also a problem for CQL-over-thrift: while we can add a new exception in thrift, having it potentially returned by execute_cql3_query() is a breaking change. It's not necessarily a blocker, we can decide that CAS are only available with the native protocol v2 (and raw thrift), but it's a bit of shame. CAS UPDATE for a lost race: save round trip by returning column values -- Key: CASSANDRA-5619 URL: https://issues.apache.org/jira/browse/CASSANDRA-5619 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 2.0 beta 1 Reporter: Blair Zajac Assignee: Sylvain Lebresne Fix For: 2.0 beta 1 Attachments: 0001-Add-back-boolean-result-column.txt, 5619_thrift_fixup.txt, 5619.txt Looking at the new CAS CQL3 support examples [1], if one lost a race for an UPDATE, to save a round trip to get the current values to decide if you need to perform your work, could the columns that were used in the IF clause also be returned to the caller? Maybe the columns values as part of the SET part could also be returned. I don't know if this is generally useful though. In the case of creating a new user account with a given username which is the partition key, if one lost the race to another person creating an account with the same username, it doesn't matter to the loser what the column values are, just that they lost. I'm new to Cassandra, so maybe there's other use cases, such as doing incremental amount of work on a row. In pure Java projects I've done while loops around AtomicReference.html#compareAndSet() until the work was done on the referenced object to handle multiple threads each making forward progress in updating the references object. [1] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044 -- 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: Don't keep ancestor information in memory since it is only used on startup.
Updated Branches:
refs/heads/cassandra-1.2 cc9ac8277 - 83b75754f
Don't keep ancestor information in memory since it is only used on startup.
patch by marcuse, reviewed by jbellis for CASSANDRA-5342
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/83b75754
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/83b75754
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/83b75754
Branch: refs/heads/cassandra-1.2
Commit: 83b75754ff143d4d77b01ef76a813da47779c6f4
Parents: cc9ac82
Author: Marcus Eriksson marc...@spotify.com
Authored: Mon Jul 8 09:55:34 2013 +0200
Committer: Marcus Eriksson marc...@spotify.com
Committed: Mon Jul 8 09:57:11 2013 +0200
--
CHANGES.txt | 1 +
.../cassandra/io/sstable/SSTableMetadata.java | 39 ++--
.../cassandra/io/sstable/SSTableReader.java | 12 +-
.../cassandra/io/sstable/SSTableWriter.java | 6 +--
.../cassandra/tools/SSTableMetadataViewer.java | 2 +-
.../sstable/SSTableMetadataSerializerTest.java | 13 +--
6 files changed, 52 insertions(+), 21 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83b75754/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fa4df36..b08f967 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -7,6 +7,7 @@
(CASSANDRA-5692)
* Fix skipping range tombstones with reverse queries (CASSANDRA-5712)
* Expire entries out of ThriftSessionManager (CASSANRDA-5719)
+ * Don't keep ancestor information in memory (CASSANDRA-5342)
1.2.6
* Fix tracing when operation completes before all responses arrive
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83b75754/src/java/org/apache/cassandra/io/sstable/SSTableMetadata.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableMetadata.java
b/src/java/org/apache/cassandra/io/sstable/SSTableMetadata.java
index 865c2ea..de51ea9 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableMetadata.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableMetadata.java
@@ -20,6 +20,7 @@ package org.apache.cassandra.io.sstable;
import java.io.*;
import java.util.*;
+import org.apache.cassandra.utils.Pair;
import org.apache.cassandra.utils.StreamingHistogram;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -55,7 +56,6 @@ public class SSTableMetadata
public final long maxTimestamp;
public final double compressionRatio;
public final String partitioner;
-public final SetInteger ancestors;
public final StreamingHistogram estimatedTombstoneDropTime;
private SSTableMetadata()
@@ -67,7 +67,6 @@ public class SSTableMetadata
Long.MAX_VALUE,
NO_COMPRESSION_RATIO,
null,
- Collections.IntegeremptySet(),
defaultTombstoneDropTimeHistogram());
}
@@ -78,7 +77,6 @@ public class SSTableMetadata
long maxTimestamp,
double cr,
String partitioner,
-SetInteger ancestors,
StreamingHistogram estimatedTombstoneDropTime)
{
this.estimatedRowSize = rowSizes;
@@ -88,7 +86,6 @@ public class SSTableMetadata
this.maxTimestamp = maxTimestamp;
this.compressionRatio = cr;
this.partitioner = partitioner;
-this.ancestors = ancestors;
this.estimatedTombstoneDropTime = estimatedTombstoneDropTime;
}
@@ -193,7 +190,6 @@ public class SSTableMetadata
maxTimestamp,
compressionRatio,
partitioner,
- ancestors,
estimatedTombstoneDropTime);
}
@@ -242,7 +238,7 @@ public class SSTableMetadata
{
private static final Logger logger =
LoggerFactory.getLogger(SSTableMetadataSerializer.class);
-public void serialize(SSTableMetadata sstableStats, DataOutput dos)
throws IOException
+public void serialize(SSTableMetadata sstableStats, SetInteger
ancestors, DataOutput dos) throws IOException
{
assert sstableStats.partitioner != null;
@@ -253,20 +249,31 @@ public class SSTableMetadata
dos.writeLong(sstableStats.maxTimestamp);
dos.writeDouble(sstableStats.compressionRatio);
dos.writeUTF(sstableStats.partitioner);
-dos.writeInt(sstableStats.ancestors.size());
-for (Integer g : sstableStats.ancestors)
+
[1/2] git commit: Don't keep ancestor information in memory since it is only used on startup.
Updated Branches:
refs/heads/trunk 1a2f35731 - 07ca445e5
Don't keep ancestor information in memory since it is only used on startup.
patch by marcuse, reviewed by jbellis for CASSANDRA-5342
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/83b75754
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/83b75754
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/83b75754
Branch: refs/heads/trunk
Commit: 83b75754ff143d4d77b01ef76a813da47779c6f4
Parents: cc9ac82
Author: Marcus Eriksson marc...@spotify.com
Authored: Mon Jul 8 09:55:34 2013 +0200
Committer: Marcus Eriksson marc...@spotify.com
Committed: Mon Jul 8 09:57:11 2013 +0200
--
CHANGES.txt | 1 +
.../cassandra/io/sstable/SSTableMetadata.java | 39 ++--
.../cassandra/io/sstable/SSTableReader.java | 12 +-
.../cassandra/io/sstable/SSTableWriter.java | 6 +--
.../cassandra/tools/SSTableMetadataViewer.java | 2 +-
.../sstable/SSTableMetadataSerializerTest.java | 13 +--
6 files changed, 52 insertions(+), 21 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83b75754/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fa4df36..b08f967 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -7,6 +7,7 @@
(CASSANDRA-5692)
* Fix skipping range tombstones with reverse queries (CASSANDRA-5712)
* Expire entries out of ThriftSessionManager (CASSANRDA-5719)
+ * Don't keep ancestor information in memory (CASSANDRA-5342)
1.2.6
* Fix tracing when operation completes before all responses arrive
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83b75754/src/java/org/apache/cassandra/io/sstable/SSTableMetadata.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableMetadata.java
b/src/java/org/apache/cassandra/io/sstable/SSTableMetadata.java
index 865c2ea..de51ea9 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableMetadata.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableMetadata.java
@@ -20,6 +20,7 @@ package org.apache.cassandra.io.sstable;
import java.io.*;
import java.util.*;
+import org.apache.cassandra.utils.Pair;
import org.apache.cassandra.utils.StreamingHistogram;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -55,7 +56,6 @@ public class SSTableMetadata
public final long maxTimestamp;
public final double compressionRatio;
public final String partitioner;
-public final SetInteger ancestors;
public final StreamingHistogram estimatedTombstoneDropTime;
private SSTableMetadata()
@@ -67,7 +67,6 @@ public class SSTableMetadata
Long.MAX_VALUE,
NO_COMPRESSION_RATIO,
null,
- Collections.IntegeremptySet(),
defaultTombstoneDropTimeHistogram());
}
@@ -78,7 +77,6 @@ public class SSTableMetadata
long maxTimestamp,
double cr,
String partitioner,
-SetInteger ancestors,
StreamingHistogram estimatedTombstoneDropTime)
{
this.estimatedRowSize = rowSizes;
@@ -88,7 +86,6 @@ public class SSTableMetadata
this.maxTimestamp = maxTimestamp;
this.compressionRatio = cr;
this.partitioner = partitioner;
-this.ancestors = ancestors;
this.estimatedTombstoneDropTime = estimatedTombstoneDropTime;
}
@@ -193,7 +190,6 @@ public class SSTableMetadata
maxTimestamp,
compressionRatio,
partitioner,
- ancestors,
estimatedTombstoneDropTime);
}
@@ -242,7 +238,7 @@ public class SSTableMetadata
{
private static final Logger logger =
LoggerFactory.getLogger(SSTableMetadataSerializer.class);
-public void serialize(SSTableMetadata sstableStats, DataOutput dos)
throws IOException
+public void serialize(SSTableMetadata sstableStats, SetInteger
ancestors, DataOutput dos) throws IOException
{
assert sstableStats.partitioner != null;
@@ -253,20 +249,31 @@ public class SSTableMetadata
dos.writeLong(sstableStats.maxTimestamp);
dos.writeDouble(sstableStats.compressionRatio);
dos.writeUTF(sstableStats.partitioner);
-dos.writeInt(sstableStats.ancestors.size());
-for (Integer g : sstableStats.ancestors)
+dos.writeInt(ancestors.size());
+
[jira] [Commented] (CASSANDRA-5342) ancestors are not cleared in SSTableMetadata after compactions are done and old SSTables are removed
[ https://issues.apache.org/jira/browse/CASSANDRA-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13701912#comment-13701912 ] Marcus Eriksson commented on CASSANDRA-5342: thanks, committed as 83b75754ff143d4d77b01ef76a813da47779c6f4 opted to leave the Pair in, no strong feelings either ancestors are not cleared in SSTableMetadata after compactions are done and old SSTables are removed Key: CASSANDRA-5342 URL: https://issues.apache.org/jira/browse/CASSANDRA-5342 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.3 Reporter: Wei Zhu Assignee: Marcus Eriksson Fix For: 1.2.7 Attachments: 0001-CASSANDRA-5342-wip.patch, 0001-CASSANDRA-5342-wip-v2.patch, Screen Shot 2013-03-13 at 12.05.08 PM.png We are using LCS and have total of 38000 SSTables for one CF. During LCS, there could be over a thousand SSTable involved. All those SSTable IDs are stored in ancestors field of SSTableMetatdata for the new table. In our case, it consumes more than 1G of heap memory for those field. Put it in perspective, the ancestors consume 2 - 3 times more memory than bloomfilter (fp = 0.1 by default) in LCS. We should remove those ancestors from SSTableMetadata after the compaction is finished and the old SSTable is removed. It might be a big deal for Sized Compaction since there are small number of SSTable involved. But it consumes a lot of memory for LCS. At least, we shouldn't load those ancestors to the memory during startup if the files are removed. I would love to contribute and provide patch. Please let me know how to start. -- 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-5723) DateType (timestamp type in CQL3) does not sort pre-'unix epoch' dates correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5723: Attachment: 5723.txt Attaching a patch with that new TimestampType. The patch is against 1.2 right now, but I'm starting to wonder if 2.0 is not a more reasonable goal. The basics of the patch is that the CQL3 timestamp type now default to that new type. For the native protocol however, we make both DateType and TimestampType be returned as 'timestamp'. Otherwise, if we were returning it as a custom type, this would likely break users since client driver wouldn't recognize it anymore. Besides, the actual sorting of a type in a ResultSet shouldn't matter for a CQL3 driver. On the CQL-over-thrift side however, we return the full thrift comparator name, so in practice we'd have to update cqlsh so it continues to work with dates, but the patch doesn't do it. The patch let user switch between DateType and TimestampType, but log a warning when you do so. DateType (timestamp type in CQL3) does not sort pre-'unix epoch' dates correctly Key: CASSANDRA-5723 URL: https://issues.apache.org/jira/browse/CASSANDRA-5723 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.3 Reporter: zhouhero Fix For: 1.2.3 Attachments: 5723.txt - this bug can be confirmed by fellow: 1.create table like fellow: create table test2 ( id varchar, c varchar, create_date timestamp, primary key(id) ); create index idx_test2_c on test2 (c); create index idx_test2_create_date on test2 (create_date); 2.insert data like fellow; cqlsh:pgl update test2 set create_date='1950-01-01', c='1' where id='111'; cqlsh:pgl update test2 set create_date='1917-01-01', c='1' where id='111'; cqlsh:pgl update test2 set create_date='2013-01-01', c='1' where id='111'; 3.select data : cqlsh:pgl select * from test2 where c='1' and create_date'2011-01-01 12:00:01' ALLOW FILTERING ; id | c | create_date -+---+-- 111 | 1 | 2012-12-31 15:00:00+ 4. add data: update test2 set create_date='1917-05-01', c='1' where id='111'; 5.select data: cqlsh:pgl select * from test2 where c='1' and create_date'2011-01-01 12:00:01' ALLOW FILTERING ; id | c | create_date -+---+-- 111 | 1 | 1917-04-30 15:00:00+ ↑ the search result is not right! it should be fellow: id | c | create_date -+---+-- 111 | 1 | 2012-12-31 15:00:00+ -- 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-5723) DateType (timestamp type in CQL3) does not sort pre-'unix epoch' dates correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5723: Fix Version/s: (was: 1.2.3) DateType (timestamp type in CQL3) does not sort pre-'unix epoch' dates correctly Key: CASSANDRA-5723 URL: https://issues.apache.org/jira/browse/CASSANDRA-5723 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.3 Reporter: zhouhero Attachments: 5723.txt - this bug can be confirmed by fellow: 1.create table like fellow: create table test2 ( id varchar, c varchar, create_date timestamp, primary key(id) ); create index idx_test2_c on test2 (c); create index idx_test2_create_date on test2 (create_date); 2.insert data like fellow; cqlsh:pgl update test2 set create_date='1950-01-01', c='1' where id='111'; cqlsh:pgl update test2 set create_date='1917-01-01', c='1' where id='111'; cqlsh:pgl update test2 set create_date='2013-01-01', c='1' where id='111'; 3.select data : cqlsh:pgl select * from test2 where c='1' and create_date'2011-01-01 12:00:01' ALLOW FILTERING ; id | c | create_date -+---+-- 111 | 1 | 2012-12-31 15:00:00+ 4. add data: update test2 set create_date='1917-05-01', c='1' where id='111'; 5.select data: cqlsh:pgl select * from test2 where c='1' and create_date'2011-01-01 12:00:01' ALLOW FILTERING ; id | c | create_date -+---+-- 111 | 1 | 1917-04-30 15:00:00+ ↑ the search result is not right! it should be fellow: id | c | create_date -+---+-- 111 | 1 | 2012-12-31 15:00:00+ -- 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-4495) Don't tie client side use of AbstractType to JDBC
[ https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702018#comment-13702018 ] Rick Shaw commented on CASSANDRA-4495: -- LGTM. Should be no problem to incorporate into client side work. Thanks for the enhancements! Don't tie client side use of AbstractType to JDBC - Key: CASSANDRA-4495 URL: https://issues.apache.org/jira/browse/CASSANDRA-4495 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Carl Yeksigian Priority: Minor Fix For: 2.0 Attachments: 4495.patch, 4495-v2.patch, 4495-v3.patch We currently expose the AbstractType to java clients that want to reuse them though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL and will never be). Typically, there is a fair amount of the JDBC standard that cannot be implemented with C*, and there is a number of specificity of C* that are not in JDBC (typically the set and maps collections). So I propose to extract simple type classes with just a compose and decompose method (but without ties to jdbc, which would allow all the jdbc specific method those types have) in the purpose of exporting that in a separate jar for clients (we could put that in a org.apache.cassandra.type package for instance). We could then deprecate the jdbc classes with basically the same schedule than CQL2. Let me note that this is *not* saying there shouldn't be a JDBC driver for Cassandra. -- 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-4775) Counters 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702029#comment-13702029 ] Jonathan Ellis commented on CASSANDRA-4775: --- bq. that problem is not inherent to counters 1.0 You'll have to explain that for me in small words, then -- I don't see how moving to explicit read-before-write allows us to safely replay the same commitlog segment twice, for instance. Counters 2.0 Key: CASSANDRA-4775 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Arya Goudarzi Assignee: Aleksey Yeschenko Labels: counters Fix For: 2.1 The existing partitioned counters remain a source of frustration for most users almost two years after being introduced. The remaining problems are inherent in the design, not something that can be fixed given enough time/eyeballs. Ideally a solution would give us - similar performance - less special cases in the code - potential for a retry mechanism -- 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-4775) Counters 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702029#comment-13702029 ] Jonathan Ellis edited comment on CASSANDRA-4775 at 7/8/13 2:34 PM: --- bq. that problem is not inherent to counters 1.0 You'll have to explain that for me in small words, then -- I don't see how moving to lock-and-read-before-write allows us to safely replay the same commitlog segment twice, for instance. was (Author: jbellis): bq. that problem is not inherent to counters 1.0 You'll have to explain that for me in small words, then -- I don't see how moving to explicit read-before-write allows us to safely replay the same commitlog segment twice, for instance. Counters 2.0 Key: CASSANDRA-4775 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Arya Goudarzi Assignee: Aleksey Yeschenko Labels: counters Fix For: 2.1 The existing partitioned counters remain a source of frustration for most users almost two years after being introduced. The remaining problems are inherent in the design, not something that can be fixed given enough time/eyeballs. Ideally a solution would give us - similar performance - less special cases in the code - potential for a retry mechanism -- 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-4775) Counters 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702042#comment-13702042 ] Sylvain Lebresne commented on CASSANDRA-4775: - We currently have 2 types of shards in a couter context: local and remotes. Remote ones are resolved using a the biggest-clock wins rule so they are not problem for internal idempotence. The problem are local shards: when a new increment comes int, the leader of that increment writes a new cell with that increment as local shard, and those local shard get summed during merge. That's the problem, since duplicating said shard imply a duplicate count. But those local shards are an implementation detail. The idea of doing a read-before-write imply not using those anymore. So on a new increment, the leader of the increment would read the current value for his own shard, compute the increment value (and incremented clock) and write that result. But it's now the result of the increment (for his own shard, other node can safely increment their own shard concurrently), not an increment. So duplicating those cells doesn't matter at all. It does mean you synchronize locally the read-before-write of course, hence my mentioning of locking above. Make sense? Counters 2.0 Key: CASSANDRA-4775 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Arya Goudarzi Assignee: Aleksey Yeschenko Labels: counters Fix For: 2.1 The existing partitioned counters remain a source of frustration for most users almost two years after being introduced. The remaining problems are inherent in the design, not something that can be fixed given enough time/eyeballs. Ideally a solution would give us - similar performance - less special cases in the code - potential for a retry mechanism -- 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] [Assigned] (CASSANDRA-5728) Check if native server is running before starting it up
[ https://issues.apache.org/jira/browse/CASSANDRA-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyril Scetbon reassigned CASSANDRA-5728: Assignee: Cyril Scetbon Check if native server is running before starting it up --- Key: CASSANDRA-5728 URL: https://issues.apache.org/jira/browse/CASSANDRA-5728 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2.6 Reporter: Manoj Mainali Assignee: Cyril Scetbon Attachments: trunk-CASSANDRA-5728.patch It is possible to enable/disable thrift and native server via nodetool. However, there is a slight difference in their behaviour. In the case of thrift server, if the server is already running, enable will ignore and will not throw any exceptions. However, in the case of native server if the server is already running an exception is thrown. In the case of thrift, we check if the server is already running but not in the case of binary. The exception is perfectly valid, but, we should have consistent behaviour with thirft and binary server. -- 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-4775) Counters 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702046#comment-13702046 ] Jonathan Ellis commented on CASSANDRA-4775: --- So we'd lock even before the commitlog entry? Counters 2.0 Key: CASSANDRA-4775 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Arya Goudarzi Assignee: Aleksey Yeschenko Labels: counters Fix For: 2.1 The existing partitioned counters remain a source of frustration for most users almost two years after being introduced. The remaining problems are inherent in the design, not something that can be fixed given enough time/eyeballs. Ideally a solution would give us - similar performance - less special cases in the code - potential for a retry mechanism -- 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-4775) Counters 2.0
[
https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702071#comment-13702071
]
Sylvain Lebresne commented on CASSANDRA-4775:
-
bq. So we'd lock even before the commitlog entry?
Yes. The SP.applyCounterMutationOnLeader would become something like (on just
one counter to make it simpler):
{noformat}
public AbstractWriteResponseHandler applyCounterMutationOnLeader(CFStore cfs,
ByteBuffer key, CounterUpdateColumn increment)
{
counterLock.lock();
try
{
CounterColumn current = read(cfs, key, column.name());
CounterColumn newValue = current.add(increment); // This would return a
new value where the current node shard has an incremented value and clock
cfs.apply(newValue);
}
finally
{
counterLock.unlock();
}
}
{noformat}
(of course in practice we would shard that counterLock, and there is probably
some fancier optimization to do).
Counters 2.0
Key: CASSANDRA-4775
URL: https://issues.apache.org/jira/browse/CASSANDRA-4775
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Arya Goudarzi
Assignee: Aleksey Yeschenko
Labels: counters
Fix For: 2.1
The existing partitioned counters remain a source of frustration for most
users almost two years after being introduced. The remaining problems are
inherent in the design, not something that can be fixed given enough
time/eyeballs.
Ideally a solution would give us
- similar performance
- less special cases in the code
- potential for a retry mechanism
--
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-5619) CAS UPDATE for a lost race: save round trip by returning column values
[ https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702084#comment-13702084 ] Jonathan Ellis commented on CASSANDRA-5619: --- Ugh. In that case, I guess the latest patch is probably the lesser evil. Ship it! CAS UPDATE for a lost race: save round trip by returning column values -- Key: CASSANDRA-5619 URL: https://issues.apache.org/jira/browse/CASSANDRA-5619 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 2.0 beta 1 Reporter: Blair Zajac Assignee: Sylvain Lebresne Fix For: 2.0 beta 1 Attachments: 0001-Add-back-boolean-result-column.txt, 5619_thrift_fixup.txt, 5619.txt Looking at the new CAS CQL3 support examples [1], if one lost a race for an UPDATE, to save a round trip to get the current values to decide if you need to perform your work, could the columns that were used in the IF clause also be returned to the caller? Maybe the columns values as part of the SET part could also be returned. I don't know if this is generally useful though. In the case of creating a new user account with a given username which is the partition key, if one lost the race to another person creating an account with the same username, it doesn't matter to the loser what the column values are, just that they lost. I'm new to Cassandra, so maybe there's other use cases, such as doing incremental amount of work on a row. In pure Java projects I've done while loops around AtomicReference.html#compareAndSet() until the work was done on the referenced object to handle multiple threads each making forward progress in updating the references object. [1] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044 -- 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: Commit 3rd (and hopefully last) part of 5619
Updated Branches:
refs/heads/trunk 07ca445e5 - 4cd087f44
Commit 3rd (and hopefully last) part of 5619
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4cd087f4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4cd087f4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4cd087f4
Branch: refs/heads/trunk
Commit: 4cd087f44a0fd49ea82745d4f7aeaeace1fa
Parents: 07ca445
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Mon Jul 8 18:08:33 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Mon Jul 8 18:08:33 2013 +0200
--
.../cql3/statements/ModificationStatement.java | 47 ++--
1 file changed, 43 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4cd087f4/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
index ed30748..63655a8 100644
--- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
@@ -38,13 +38,14 @@ import org.apache.cassandra.service.pager.PagingState;
import org.apache.cassandra.thrift.ThriftValidation;
import org.apache.cassandra.transport.messages.ResultMessage;
import org.apache.cassandra.utils.Pair;
+import org.apache.cassandra.utils.ByteBufferUtil;
/*
* Abstract parent class of individual modifications, i.e. INSERT, UPDATE and
DELETE.
*/
public abstract class ModificationStatement implements CQLStatement
{
-private static final ColumnIdentifier RESULT_COLUMN = new
ColumnIdentifier(result, false);
+private static final ColumnIdentifier CAS_RESULT_COLUMN = new
ColumnIdentifier([applied], false);
private final int boundTerms;
public final CFMetaData cfm;
@@ -374,9 +375,37 @@ public abstract class ModificationStatement implements
CQLStatement
ColumnFamily expected = buildConditions(key, clusteringPrefix, params);
ColumnFamily result = StorageProxy.cas(keyspace(), columnFamily(),
key, clusteringPrefix, expected, updates, cl);
-return result == null
- ? new ResultMessage.Void()
- : new ResultMessage.Rows(buildCasFailureResultSet(key, result));
+return new ResultMessage.Rows(buildCasResultSet(key, result));
+}
+
+private ResultSet buildCasResultSet(ByteBuffer key, ColumnFamily cf)
throws InvalidRequestException
+{
+boolean success = cf == null;
+
+ColumnSpecification spec = new ColumnSpecification(keyspace(),
columnFamily(), CAS_RESULT_COLUMN, BooleanType.instance);
+ResultSet.Metadata metadata = new
ResultSet.Metadata(Collections.singletonList(spec));
+ListListByteBuffer rows =
Collections.singletonList(Collections.singletonList(BooleanType.instance.decompose(success)));
+
+ResultSet rs = new ResultSet(metadata, rows);
+return success ? rs : merge(rs, buildCasFailureResultSet(key, cf));
+}
+
+private static ResultSet merge(ResultSet left, ResultSet right)
+{
+if (left.size() == 0)
+return right;
+else if (right.size() == 0)
+return left;
+
+assert left.size() == 1 right.size() == 1;
+int size = left.metadata.names.size() + right.metadata.names.size();
+ListColumnSpecification specs = new
ArrayListColumnSpecification(size);
+specs.addAll(left.metadata.names);
+specs.addAll(right.metadata.names);
+ListByteBuffer row = new ArrayListByteBuffer(size);
+row.addAll(left.rows.get(0));
+row.addAll(right.rows.get(0));
+return new ResultSet(new ResultSet.Metadata(specs),
Collections.singletonList(row));
}
private ResultSet buildCasFailureResultSet(ByteBuffer key, ColumnFamily
cf) throws InvalidRequestException
@@ -467,6 +496,16 @@ public abstract class ModificationStatement implements
CQLStatement
return null;
ColumnFamily cf = TreeMapBackedSortedColumns.factory.create(cfm);
+
+// CQL row marker
+CFDefinition cfDef = cfm.getCfDef();
+if (cfDef.isComposite !cfDef.isCompact !cfm.isSuper())
+{
+ByteBuffer name =
clusteringPrefix.copy().add(ByteBufferUtil.EMPTY_BYTE_BUFFER).build();
+cf.addColumn(params.makeColumn(name,
ByteBufferUtil.EMPTY_BYTE_BUFFER));
+}
+
+// Conditions
for (Operation condition : columnConditions)
condition.execute(key, cf, clusteringPrefix.copy(), params);
[jira] [Resolved] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values
[ https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-5619. - Resolution: Fixed Alright, committed, thanks. CAS UPDATE for a lost race: save round trip by returning column values -- Key: CASSANDRA-5619 URL: https://issues.apache.org/jira/browse/CASSANDRA-5619 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 2.0 beta 1 Reporter: Blair Zajac Assignee: Sylvain Lebresne Fix For: 2.0 beta 1 Attachments: 0001-Add-back-boolean-result-column.txt, 5619_thrift_fixup.txt, 5619.txt Looking at the new CAS CQL3 support examples [1], if one lost a race for an UPDATE, to save a round trip to get the current values to decide if you need to perform your work, could the columns that were used in the IF clause also be returned to the caller? Maybe the columns values as part of the SET part could also be returned. I don't know if this is generally useful though. In the case of creating a new user account with a given username which is the partition key, if one lost the race to another person creating an account with the same username, it doesn't matter to the loser what the column values are, just that they lost. I'm new to Cassandra, so maybe there's other use cases, such as doing incremental amount of work on a row. In pure Java projects I've done while loops around AtomicReference.html#compareAndSet() until the work was done on the referenced object to handle multiple threads each making forward progress in updating the references object. [1] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044 -- 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-5723) DateType (timestamp type in CQL3) does not sort pre-'unix epoch' dates correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702091#comment-13702091 ] Jonathan Ellis commented on CASSANDRA-5723: --- +1, but I agree that this should be for 2.0. DateType (timestamp type in CQL3) does not sort pre-'unix epoch' dates correctly Key: CASSANDRA-5723 URL: https://issues.apache.org/jira/browse/CASSANDRA-5723 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.3 Reporter: zhouhero Assignee: Sylvain Lebresne Attachments: 5723.txt - this bug can be confirmed by fellow: 1.create table like fellow: create table test2 ( id varchar, c varchar, create_date timestamp, primary key(id) ); create index idx_test2_c on test2 (c); create index idx_test2_create_date on test2 (create_date); 2.insert data like fellow; cqlsh:pgl update test2 set create_date='1950-01-01', c='1' where id='111'; cqlsh:pgl update test2 set create_date='1917-01-01', c='1' where id='111'; cqlsh:pgl update test2 set create_date='2013-01-01', c='1' where id='111'; 3.select data : cqlsh:pgl select * from test2 where c='1' and create_date'2011-01-01 12:00:01' ALLOW FILTERING ; id | c | create_date -+---+-- 111 | 1 | 2012-12-31 15:00:00+ 4. add data: update test2 set create_date='1917-05-01', c='1' where id='111'; 5.select data: cqlsh:pgl select * from test2 where c='1' and create_date'2011-01-01 12:00:01' ALLOW FILTERING ; id | c | create_date -+---+-- 111 | 1 | 1917-04-30 15:00:00+ ↑ the search result is not right! it should be fellow: id | c | create_date -+---+-- 111 | 1 | 2012-12-31 15:00:00+ -- 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
[3/3] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a90e8b77 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a90e8b77 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a90e8b77 Branch: refs/heads/trunk Commit: a90e8b77c5b0f4d231bd7b61abc0bd16450beeaa Parents: 4cd087f f8c072e Author: Jonathan Ellis jbel...@apache.org Authored: Mon Jul 8 11:30:39 2013 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Mon Jul 8 11:30:39 2013 -0500 -- CHANGES.txt | 2 ++ src/java/org/apache/cassandra/transport/Server.java | 7 +-- 2 files changed, 7 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a90e8b77/CHANGES.txt -- diff --cc CHANGES.txt index 40c076c,7c16cd0..5d597bd --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,81 -1,8 +1,82 @@@ +2.0 + * Removed on-heap row cache (CASSANDRA-5348) + * use nanotime consistently for node-local timeouts (CASSANDRA-5581) + * Avoid unnecessary second pass on name-based queries (CASSANDRA-5577) + * Experimental triggers (CASSANDRA-1311) + * JEMalloc support for off-heap allocation (CASSANDRA-3997) + * Single-pass compaction (CASSANDRA-4180) + * Removed token range bisection (CASSANDRA-5518) + * Removed compatibility with pre-1.2.5 sstables and network messages + (CASSANDRA-5511) + * removed PBSPredictor (CASSANDRA-5455) + * CAS support (CASSANDRA-5062, 5441, 5442, 5443, 5619, 5667) + * Leveled compaction performs size-tiered compactions in L0 + (CASSANDRA-5371, 5439) + * Add yaml network topology snitch for mixed ec2/other envs (CASSANDRA-5339) + * Log when a node is down longer than the hint window (CASSANDRA-4554) + * Optimize tombstone creation for ExpiringColumns (CASSANDRA-4917) + * Improve LeveledScanner work estimation (CASSANDRA-5250, 5407) + * Replace compaction lock with runWithCompactionsDisabled (CASSANDRA-3430) + * Change Message IDs to ints (CASSANDRA-5307) + * Move sstable level information into the Stats component, removing the + need for a separate Manifest file (CASSANDRA-4872) + * avoid serializing to byte[] on commitlog append (CASSANDRA-5199) + * make index_interval configurable per columnfamily (CASSANDRA-3961, CASSANDRA-5650) + * add default_time_to_live (CASSANDRA-3974) + * add memtable_flush_period_in_ms (CASSANDRA-4237) + * replace supercolumns internally by composites (CASSANDRA-3237, 5123) + * upgrade thrift to 0.9.0 (CASSANDRA-3719) + * drop unnecessary keyspace parameter from user-defined compaction API + (CASSANDRA-5139) + * more robust solution to incomplete compactions + counters (CASSANDRA-5151) + * Change order of directory searching for c*.in.sh (CASSANDRA-3983) + * Add tool to reset SSTable compaction level for LCS (CASSANDRA-5271) + * Allow custom configuration loader (CASSANDRA-5045) + * Remove memory emergency pressure valve logic (CASSANDRA-3534) + * Reduce request latency with eager retry (CASSANDRA-4705) + * cqlsh: Remove ASSUME command (CASSANDRA-5331) + * Rebuild BF when loading sstables if bloom_filter_fp_chance + has changed since compaction (CASSANDRA-5015) + * remove row-level bloom filters (CASSANDRA-4885) + * Change Kernel Page Cache skipping into row preheating (disabled by default) + (CASSANDRA-4937) + * Improve repair by deciding on a gcBefore before sending + out TreeRequests (CASSANDRA-4932) + * Add an official way to disable compactions (CASSANDRA-5074) + * Reenable ALTER TABLE DROP with new semantics (CASSANDRA-3919) + * Add binary protocol versioning (CASSANDRA-5436) + * Swap THshaServer for TThreadedSelectorServer (CASSANDRA-5530) + * Add alias support to SELECT statement (CASSANDRA-5075) + * Don't create empty RowMutations in CommitLogReplayer (CASSANDRA-5541) + * Use range tombstones when dropping cfs/columns from schema (CASSANDRA-5579) + * cqlsh: drop CQL2/CQL3-beta support (CASSANDRA-5585) + * Track max/min column names in sstables to be able to optimize slice + queries (CASSANDRA-5514, CASSANDRA-5595, CASSANDRA-5600) + * Binary protocol: allow batching already prepared statements (CASSANDRA-4693) + * Allow preparing timestamp, ttl and limit in CQL3 queries (CASSANDRA-4450) + * Support native link w/o JNA in Java7 (CASSANDRA-3734) + * Use SASL authentication in binary protocol v2 (CASSANDRA-5545) + * Replace Thrift HsHa with LMAX Disruptor based implementation (CASSANDRA-5582) + * cqlsh: Add row count to SELECT output (CASSANDRA-5636) + * Include a timestamp with all read commands to determine column expiration + (CASSANDRA-5149) + * Streaming 2.0 (CASSANDRA-5286, 5699) + * Conditional create/drop ks/table/index
[2/3] git commit: make starting native protocol server idempotent patch by Manoj Mainali; reviewed by jbellis for CASSANDRA-5728
make starting native protocol server idempotent
patch by Manoj Mainali; reviewed by jbellis for CASSANDRA-5728
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f8c072e9
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f8c072e9
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f8c072e9
Branch: refs/heads/trunk
Commit: f8c072e974eef21ca7287e21db33f09788cb56c0
Parents: 83b7575
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jul 8 11:30:31 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jul 8 11:30:31 2013 -0500
--
CHANGES.txt | 2 ++
src/java/org/apache/cassandra/transport/Server.java | 7 +--
2 files changed, 7 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f8c072e9/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b08f967..7c16cd0 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.2.7
+ * make starting native protocol server idempotent (CASSANDRA-5728)
* Fix loading key cache when a saved entry is no longer valid (CASSANDRA-5706)
* Fix serialization of the LEFT gossip value (CASSANDRA-5696)
* Pig: support for cql3 tables (CASSANDRA-5234)
@@ -9,6 +10,7 @@
* Expire entries out of ThriftSessionManager (CASSANRDA-5719)
* Don't keep ancestor information in memory (CASSANDRA-5342)
+
1.2.6
* Fix tracing when operation completes before all responses arrive
(CASSANDRA-5668)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f8c072e9/src/java/org/apache/cassandra/transport/Server.java
--
diff --git a/src/java/org/apache/cassandra/transport/Server.java
b/src/java/org/apache/cassandra/transport/Server.java
index 51a90e8..7400a8b 100644
--- a/src/java/org/apache/cassandra/transport/Server.java
+++ b/src/java/org/apache/cassandra/transport/Server.java
@@ -95,8 +95,11 @@ public class Server implements CassandraDaemon.Server
public void start()
{
-run();
-isRunning.set(true);
+ if(!isRunning())
+ {
+run();
+isRunning.set(true);
+ }
}
public void stop()
[1/3] git commit: make starting native protocol server idempotent patch by Manoj Mainali; reviewed by jbellis for CASSANDRA-5728
Updated Branches:
refs/heads/cassandra-1.2 83b75754f - f8c072e97
refs/heads/trunk 4cd087f44 - a90e8b77c
make starting native protocol server idempotent
patch by Manoj Mainali; reviewed by jbellis for CASSANDRA-5728
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f8c072e9
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f8c072e9
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f8c072e9
Branch: refs/heads/cassandra-1.2
Commit: f8c072e974eef21ca7287e21db33f09788cb56c0
Parents: 83b7575
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jul 8 11:30:31 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jul 8 11:30:31 2013 -0500
--
CHANGES.txt | 2 ++
src/java/org/apache/cassandra/transport/Server.java | 7 +--
2 files changed, 7 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f8c072e9/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b08f967..7c16cd0 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.2.7
+ * make starting native protocol server idempotent (CASSANDRA-5728)
* Fix loading key cache when a saved entry is no longer valid (CASSANDRA-5706)
* Fix serialization of the LEFT gossip value (CASSANDRA-5696)
* Pig: support for cql3 tables (CASSANDRA-5234)
@@ -9,6 +10,7 @@
* Expire entries out of ThriftSessionManager (CASSANRDA-5719)
* Don't keep ancestor information in memory (CASSANDRA-5342)
+
1.2.6
* Fix tracing when operation completes before all responses arrive
(CASSANDRA-5668)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f8c072e9/src/java/org/apache/cassandra/transport/Server.java
--
diff --git a/src/java/org/apache/cassandra/transport/Server.java
b/src/java/org/apache/cassandra/transport/Server.java
index 51a90e8..7400a8b 100644
--- a/src/java/org/apache/cassandra/transport/Server.java
+++ b/src/java/org/apache/cassandra/transport/Server.java
@@ -95,8 +95,11 @@ public class Server implements CassandraDaemon.Server
public void start()
{
-run();
-isRunning.set(true);
+ if(!isRunning())
+ {
+run();
+isRunning.set(true);
+ }
}
public void stop()
[4/4] git commit: Add TimestampType to replace DateType
Add TimestampType to replace DateType
patch by slebresne; reviewed by jbellis for CASSANDRA-5723
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9ec7b808
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9ec7b808
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9ec7b808
Branch: refs/heads/trunk
Commit: 9ec7b808ac6786db74b5cbad0a63f6a9cdfdc5bd
Parents: e9c6742
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Mon Jul 8 15:49:21 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Mon Jul 8 18:55:32 2013 +0200
--
CHANGES.txt | 1 +
NEWS.txt| 1 +
.../org/apache/cassandra/cql3/CQL3Type.java | 2 +-
.../apache/cassandra/cql3/UntypedResultSet.java | 2 +-
.../cassandra/cql3/functions/TimeuuidFcts.java | 14 +-
.../cassandra/db/marshal/AbstractType.java | 1 -
.../apache/cassandra/db/marshal/DateType.java | 42 --
.../apache/cassandra/db/marshal/LongType.java | 8 +-
.../cassandra/db/marshal/TimestampType.java | 145 +++
.../apache/cassandra/db/marshal/UUIDType.java | 2 +-
.../hadoop/pig/AbstractCassandraStorage.java| 4 +-
.../org/apache/cassandra/tools/Shuffle.java | 4 +-
.../apache/cassandra/transport/DataType.java| 5 +-
.../apache/cassandra/type/DateSerializer.java | 104 -
.../cassandra/type/TimestampSerializer.java | 104 +
15 files changed, 304 insertions(+), 135 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9ec7b808/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index eaa5eea..4b7dcc5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -72,6 +72,7 @@
* Move resultset type information into prepare, not execute (CASSANDRA-5649)
* Auto paging in binary protocol (CASSANDRA-4415, 5714)
* Don't tie client side use of AbstractType to JDBC (CASSANDRA-4495)
+ * Adds new TimestampType to replace DateType (CASSANDRA-5723)
1.2.7
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9ec7b808/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 7e12e2c..652f8c2 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -73,6 +73,7 @@ Features
1.2.7
=
+
Upgrading
-
- If you have decommissioned a node in the past 72 hours, it is imperative
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9ec7b808/src/java/org/apache/cassandra/cql3/CQL3Type.java
--
diff --git a/src/java/org/apache/cassandra/cql3/CQL3Type.java
b/src/java/org/apache/cassandra/cql3/CQL3Type.java
index d7a4e8e..aed3165 100644
--- a/src/java/org/apache/cassandra/cql3/CQL3Type.java
+++ b/src/java/org/apache/cassandra/cql3/CQL3Type.java
@@ -41,7 +41,7 @@ public interface CQL3Type
INET (InetAddressType.instance),
INT (Int32Type.instance),
TEXT (UTF8Type.instance),
-TIMESTAMP(DateType.instance),
+TIMESTAMP(TimestampType.instance),
UUID (UUIDType.instance),
VARCHAR (UTF8Type.instance),
VARINT (IntegerType.instance),
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9ec7b808/src/java/org/apache/cassandra/cql3/UntypedResultSet.java
--
diff --git a/src/java/org/apache/cassandra/cql3/UntypedResultSet.java
b/src/java/org/apache/cassandra/cql3/UntypedResultSet.java
index 9bee563..25294d6 100644
--- a/src/java/org/apache/cassandra/cql3/UntypedResultSet.java
+++ b/src/java/org/apache/cassandra/cql3/UntypedResultSet.java
@@ -128,7 +128,7 @@ public class UntypedResultSet implements
IterableUntypedResultSet.Row
public Date getTimestamp(String column)
{
-return DateType.instance.compose(data.get(column));
+return TimestampType.instance.compose(data.get(column));
}
public long getLong(String column)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9ec7b808/src/java/org/apache/cassandra/cql3/functions/TimeuuidFcts.java
--
diff --git a/src/java/org/apache/cassandra/cql3/functions/TimeuuidFcts.java
b/src/java/org/apache/cassandra/cql3/functions/TimeuuidFcts.java
index e325e8f..18ccd56 100644
--- a/src/java/org/apache/cassandra/cql3/functions/TimeuuidFcts.java
+++ b/src/java/org/apache/cassandra/cql3/functions/TimeuuidFcts.java
@@ -21,7 +21,7 @@ import java.nio.ByteBuffer;
import java.util.Date;
import java.util.List;
-import org.apache.cassandra.db.marshal.DateType;
+import
[jira] [Created] (CASSANDRA-5729) Add new TimestampType to cqlsh
Sylvain Lebresne created CASSANDRA-5729: --- Summary: Add new TimestampType to cqlsh Key: CASSANDRA-5729 URL: https://issues.apache.org/jira/browse/CASSANDRA-5729 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Priority: Minor Fix For: 2.0 Since cqlsh used CQL-over-thrift currently, we'd need to add support for the new TimestampType introduced in CASSANDRA-5723. -- 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-5723) DateType (timestamp type in CQL3) does not sort pre-'unix epoch' dates correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5723: Reviewer: jbellis DateType (timestamp type in CQL3) does not sort pre-'unix epoch' dates correctly Key: CASSANDRA-5723 URL: https://issues.apache.org/jira/browse/CASSANDRA-5723 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.3 Reporter: zhouhero Assignee: Sylvain Lebresne Fix For: 2.0 beta 1 Attachments: 5723.txt - this bug can be confirmed by fellow: 1.create table like fellow: create table test2 ( id varchar, c varchar, create_date timestamp, primary key(id) ); create index idx_test2_c on test2 (c); create index idx_test2_create_date on test2 (create_date); 2.insert data like fellow; cqlsh:pgl update test2 set create_date='1950-01-01', c='1' where id='111'; cqlsh:pgl update test2 set create_date='1917-01-01', c='1' where id='111'; cqlsh:pgl update test2 set create_date='2013-01-01', c='1' where id='111'; 3.select data : cqlsh:pgl select * from test2 where c='1' and create_date'2011-01-01 12:00:01' ALLOW FILTERING ; id | c | create_date -+---+-- 111 | 1 | 2012-12-31 15:00:00+ 4. add data: update test2 set create_date='1917-05-01', c='1' where id='111'; 5.select data: cqlsh:pgl select * from test2 where c='1' and create_date'2011-01-01 12:00:01' ALLOW FILTERING ; id | c | create_date -+---+-- 111 | 1 | 1917-04-30 15:00:00+ ↑ the search result is not right! it should be fellow: id | c | create_date -+---+-- 111 | 1 | 2012-12-31 15:00:00+ -- 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-5723) DateType (timestamp type in CQL3) does not sort pre-'unix epoch' dates correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5723: Fix Version/s: 2.0 beta 1 DateType (timestamp type in CQL3) does not sort pre-'unix epoch' dates correctly Key: CASSANDRA-5723 URL: https://issues.apache.org/jira/browse/CASSANDRA-5723 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.3 Reporter: zhouhero Assignee: Sylvain Lebresne Fix For: 2.0 beta 1 Attachments: 5723.txt - this bug can be confirmed by fellow: 1.create table like fellow: create table test2 ( id varchar, c varchar, create_date timestamp, primary key(id) ); create index idx_test2_c on test2 (c); create index idx_test2_create_date on test2 (create_date); 2.insert data like fellow; cqlsh:pgl update test2 set create_date='1950-01-01', c='1' where id='111'; cqlsh:pgl update test2 set create_date='1917-01-01', c='1' where id='111'; cqlsh:pgl update test2 set create_date='2013-01-01', c='1' where id='111'; 3.select data : cqlsh:pgl select * from test2 where c='1' and create_date'2011-01-01 12:00:01' ALLOW FILTERING ; id | c | create_date -+---+-- 111 | 1 | 2012-12-31 15:00:00+ 4. add data: update test2 set create_date='1917-05-01', c='1' where id='111'; 5.select data: cqlsh:pgl select * from test2 where c='1' and create_date'2011-01-01 12:00:01' ALLOW FILTERING ; id | c | create_date -+---+-- 111 | 1 | 1917-04-30 15:00:00+ ↑ the search result is not right! it should be fellow: id | c | create_date -+---+-- 111 | 1 | 2012-12-31 15:00:00+ -- 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-5730) Re-add ScrubTest post single-pass compaction
Sylvain Lebresne created CASSANDRA-5730: --- Summary: Re-add ScrubTest post single-pass compaction Key: CASSANDRA-5730 URL: https://issues.apache.org/jira/browse/CASSANDRA-5730 Project: Cassandra Issue Type: Test Reporter: Sylvain Lebresne Assignee: Jason Brown Priority: Minor Fix For: 2.0 Follow up of CASSANDRA-5429 for adding back a ScrubTest. -- 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-5429) Update scrub and scrubtest for single-pass compaction format
[ https://issues.apache.org/jira/browse/CASSANDRA-5429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-5429. - Resolution: Fixed Don't want to hold back beta1, so created CASSANDRA-5730 as a follow up to add back scrubTest. Update scrub and scrubtest for single-pass compaction format Key: CASSANDRA-5429 URL: https://issues.apache.org/jira/browse/CASSANDRA-5429 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 2.0 beta 1 Reporter: Jonathan Ellis Assignee: Jason Brown Fix For: 2.0 beta 1 Attachments: 5429-v1.diff -- 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-5731) Should use index_interval from already loaded index summary
Yuki Morishita created CASSANDRA-5731: - Summary: Should use index_interval from already loaded index summary Key: CASSANDRA-5731 URL: https://issues.apache.org/jira/browse/CASSANDRA-5731 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Trivial Fix For: 2.0 Since index_interval can be changed anytime in 2.0, SSTableReader should use index interval from loaded summary. -- 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-5731) Should use index_interval from already loaded index summary
[ https://issues.apache.org/jira/browse/CASSANDRA-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-5731: -- Attachment: 5731.txt Fix attached. Should use index_interval from already loaded index summary --- Key: CASSANDRA-5731 URL: https://issues.apache.org/jira/browse/CASSANDRA-5731 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Trivial Fix For: 2.0 Attachments: 5731.txt Since index_interval can be changed anytime in 2.0, SSTableReader should use index interval from loaded summary. -- 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
[1/3] Renames post 4495
Updated Branches:
refs/heads/trunk 9ec7b808a - fc8b76f79
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fc8b76f7/src/java/org/apache/cassandra/type/SetSerializer.java
--
diff --git a/src/java/org/apache/cassandra/type/SetSerializer.java
b/src/java/org/apache/cassandra/type/SetSerializer.java
deleted file mode 100644
index f60acb4..000
--- a/src/java/org/apache/cassandra/type/SetSerializer.java
+++ /dev/null
@@ -1,115 +0,0 @@
-/*
- * 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
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an AS IS BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-package org.apache.cassandra.type;
-
-import java.nio.BufferUnderflowException;
-import java.nio.ByteBuffer;
-import java.util.*;
-
-public class SetSerializerT extends CollectionSerializerSetT
-{
-// interning instances
-private static final MapAbstractSerializer?, SetSerializer instances =
new HashMapAbstractSerializer?, SetSerializer();
-
-public final AbstractSerializerT elements;
-
-public static synchronized T SetSerializerT
getInstance(AbstractSerializerT elements)
-{
-SetSerializerT t = instances.get(elements);
-if (t == null)
-{
-t = new SetSerializerT(elements);
-instances.put(elements, t);
-}
-return t;
-}
-
-private SetSerializer(AbstractSerializerT elements)
-{
-this.elements = elements;
-}
-
-public SetT serialize(ByteBuffer bytes)
-{
-try
-{
-ByteBuffer input = bytes.duplicate();
-int n = getUnsignedShort(input);
-SetT l = new LinkedHashSetT(n);
-for (int i = 0; i n; i++)
-{
-int s = getUnsignedShort(input);
-byte[] data = new byte[s];
-input.get(data);
-ByteBuffer databb = ByteBuffer.wrap(data);
-elements.validate(databb);
-l.add(elements.serialize(databb));
-}
-return l;
-}
-catch (BufferUnderflowException e)
-{
-throw new MarshalException(Not enough bytes to read a list);
-}
-}
-
-/**
- * Layout is: {@code ns_1b_1...s_nb_n }
- * where:
- * n is the number of elements
- * s_i is the number of bytes composing the ith element
- * b_i is the s_i bytes composing the ith element
- */
-public ByteBuffer deserialize(SetT value)
-{
-ListByteBuffer bbs = new ArrayListByteBuffer(value.size());
-int size = 0;
-for (T elt : value)
-{
-ByteBuffer bb = elements.deserialize(elt);
-bbs.add(bb);
-size += 2 + bb.remaining();
-}
-return pack(bbs, value.size(), size);
-}
-
-public String toString(SetT value)
-{
-StringBuffer sb = new StringBuffer();
-boolean isFirst = true;
-for (T element : value)
-{
-if (isFirst)
-{
-isFirst = false;
-}
-else
-{
-sb.append(; );
-}
-sb.append(elements.toString(element));
-}
-return sb.toString();
-}
-
-public ClassSetT getType()
-{
-return (Class) Set.class;
-}
-}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fc8b76f7/src/java/org/apache/cassandra/type/TimeUUIDSerializer.java
--
diff --git a/src/java/org/apache/cassandra/type/TimeUUIDSerializer.java
b/src/java/org/apache/cassandra/type/TimeUUIDSerializer.java
deleted file mode 100644
index b767012..000
--- a/src/java/org/apache/cassandra/type/TimeUUIDSerializer.java
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * 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
- * with the License. You may obtain a copy of the License at
- *
- *
[jira] [Commented] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
[ https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702166#comment-13702166 ] Sylvain Lebresne commented on CASSANDRA-4495: - For info, took the liberty to do the following renames: * renamed the package from type to serializers, since that's what the classes are called. * made AbstractSerializer an interface since I didn't see a good reason to have it an abstract class. Renamed into TypeSerializer too. * renamed the asComposer() method in AbstractType to getSerializer() (I suspect that was a left-over of the initial patch) Don't tie client side use of AbstractType to JDBC - Key: CASSANDRA-4495 URL: https://issues.apache.org/jira/browse/CASSANDRA-4495 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Carl Yeksigian Priority: Minor Fix For: 2.0 beta 1 Attachments: 4495.patch, 4495-v2.patch, 4495-v3.patch We currently expose the AbstractType to java clients that want to reuse them though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL and will never be). Typically, there is a fair amount of the JDBC standard that cannot be implemented with C*, and there is a number of specificity of C* that are not in JDBC (typically the set and maps collections). So I propose to extract simple type classes with just a compose and decompose method (but without ties to jdbc, which would allow all the jdbc specific method those types have) in the purpose of exporting that in a separate jar for clients (we could put that in a org.apache.cassandra.type package for instance). We could then deprecate the jdbc classes with basically the same schedule than CQL2. Let me note that this is *not* saying there shouldn't be a JDBC driver for Cassandra. -- 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-5731) Should use index_interval from already loaded index summary
[ https://issues.apache.org/jira/browse/CASSANDRA-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702170#comment-13702170 ] Jonathan Ellis commented on CASSANDRA-5731: --- +1 Should use index_interval from already loaded index summary --- Key: CASSANDRA-5731 URL: https://issues.apache.org/jira/browse/CASSANDRA-5731 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Trivial Fix For: 2.0 Attachments: 5731.txt Since index_interval can be changed anytime in 2.0, SSTableReader should use index interval from loaded summary. -- 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-5517) Cassandra crashes at start with segmentation fault
[ https://issues.apache.org/jira/browse/CASSANDRA-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-5517: -- Assignee: Eric Evans Cassandra crashes at start with segmentation fault -- Key: CASSANDRA-5517 URL: https://issues.apache.org/jira/browse/CASSANDRA-5517 Project: Cassandra Issue Type: Bug Components: Core Environment: VirtualBox 4.2.6 VM with 4GB RAM, Xubuntu 12.10 as host and guest OS. Cassandra 1.2.4 installed on guest as Debian package. Reporter: Sergey Naumov Assignee: Eric Evans Attachments: 0001-CASSANDRA-5517-up-xss-to-256k-for-openjdk-1.6.patch, 0002-optional-upgrade-dependency-to-OpenJDK-7.patch Sometimes Cassandra fails at start with segmentation fault: # /usr/sbin/cassandra -f xss = -ea -javaajent:/usr/share/cassandra/lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms1024M -Xmx1024M -Xmn100M -XX:+HeapDumpOnOutOfMemoryError -Xss180k Segmentation fault It seems that not only me encountered this bug: http://snapwebsites.org/known-issues/cassandra-crashes-java-segmentation-fault Solution proposed on this link works. -- 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-5517) Cassandra crashes at start with segmentation fault
[ https://issues.apache.org/jira/browse/CASSANDRA-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-5517: -- Attachment: 0002-optional-upgrade-dependency-to-OpenJDK-7.patch 0001-CASSANDRA-5517-up-xss-to-256k-for-openjdk-1.6.patch Cassandra crashes at start with segmentation fault -- Key: CASSANDRA-5517 URL: https://issues.apache.org/jira/browse/CASSANDRA-5517 Project: Cassandra Issue Type: Bug Components: Core Environment: VirtualBox 4.2.6 VM with 4GB RAM, Xubuntu 12.10 as host and guest OS. Cassandra 1.2.4 installed on guest as Debian package. Reporter: Sergey Naumov Assignee: Eric Evans Attachments: 0001-CASSANDRA-5517-up-xss-to-256k-for-openjdk-1.6.patch, 0002-optional-upgrade-dependency-to-OpenJDK-7.patch Sometimes Cassandra fails at start with segmentation fault: # /usr/sbin/cassandra -f xss = -ea -javaajent:/usr/share/cassandra/lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms1024M -Xmx1024M -Xmn100M -XX:+HeapDumpOnOutOfMemoryError -Xss180k Segmentation fault It seems that not only me encountered this bug: http://snapwebsites.org/known-issues/cassandra-crashes-java-segmentation-fault Solution proposed on this link works. -- 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-5517) Cassandra crashes at start with segmentation fault
[ https://issues.apache.org/jira/browse/CASSANDRA-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702254#comment-13702254 ] Eric Evans commented on CASSANDRA-5517: --- The attached patch, 0001-CASSANDRA-5517-up-xss-to-256k-for-openjdk-1.6, raises -Xss to 256k for OpenJDK 1.6 only. Optionally, 0002-optional-upgrade-dependency-to-OpenJDK-7 raises the Debian package dependency to OpenJDK 1.7. You could argue it unwise to change this in a point release, but OpenJDK 1.7 seems to be a _much_ better default at this point. Cassandra crashes at start with segmentation fault -- Key: CASSANDRA-5517 URL: https://issues.apache.org/jira/browse/CASSANDRA-5517 Project: Cassandra Issue Type: Bug Components: Core Environment: VirtualBox 4.2.6 VM with 4GB RAM, Xubuntu 12.10 as host and guest OS. Cassandra 1.2.4 installed on guest as Debian package. Reporter: Sergey Naumov Assignee: Eric Evans Attachments: 0001-CASSANDRA-5517-up-xss-to-256k-for-openjdk-1.6.patch, 0002-optional-upgrade-dependency-to-OpenJDK-7.patch Sometimes Cassandra fails at start with segmentation fault: # /usr/sbin/cassandra -f xss = -ea -javaajent:/usr/share/cassandra/lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms1024M -Xmx1024M -Xmn100M -XX:+HeapDumpOnOutOfMemoryError -Xss180k Segmentation fault It seems that not only me encountered this bug: http://snapwebsites.org/known-issues/cassandra-crashes-java-segmentation-fault Solution proposed on this link works. -- 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: use index interval from index summary patch by yukim; reviewed by jbellis for CASSANDRA-5731
Updated Branches:
refs/heads/trunk fc8b76f79 - 2de07250d
use index interval from index summary
patch by yukim; reviewed by jbellis for CASSANDRA-5731
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2de07250
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2de07250
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2de07250
Branch: refs/heads/trunk
Commit: 2de07250d1235a4e9e7fac0ac1a2a45784d2a3ab
Parents: fc8b76f
Author: Yuki Morishita yu...@apache.org
Authored: Mon Jul 8 13:50:21 2013 -0500
Committer: Yuki Morishita yu...@apache.org
Committed: Mon Jul 8 13:50:32 2013 -0500
--
.../org/apache/cassandra/io/sstable/SSTableReader.java| 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/2de07250/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
b/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
index 81f83d1..c4f32cb 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
@@ -112,7 +112,7 @@ public class SSTableReader extends SSTable
for (SSTableReader sstable : sstables)
{
int indexKeyCount = sstable.getKeySampleSize();
-count = count + (indexKeyCount + 1) * metadata.getIndexInterval();
+count = count + (indexKeyCount + 1) *
sstable.indexSummary.getIndexInterval();
if (logger.isDebugEnabled())
logger.debug(index size for bloom filter calc for file : +
sstable.getFilename() +: + count);
}
@@ -556,7 +556,7 @@ public class SSTableReader extends SSTable
*/
public long estimatedKeys()
{
-return indexSummary.size() * metadata.getIndexInterval();
+return indexSummary.size() * indexSummary.getIndexInterval();
}
/**
@@ -569,7 +569,7 @@ public class SSTableReader extends SSTable
ListPairInteger, Integer sampleIndexes =
getSampleIndexesForRanges(indexSummary, ranges);
for (PairInteger, Integer sampleIndexRange : sampleIndexes)
sampleKeyCount += (sampleIndexRange.right - sampleIndexRange.left
+ 1);
-return Math.max(1, sampleKeyCount * metadata.getIndexInterval());
+return Math.max(1, sampleKeyCount * indexSummary.getIndexInterval());
}
/**
@@ -825,12 +825,12 @@ public class SSTableReader extends SSTable
// of the next interval).
int i = 0;
IteratorFileDataInput segments = ifile.iterator(sampledPosition,
INDEX_FILE_BUFFER_BYTES);
-while (segments.hasNext() i = metadata.getIndexInterval())
+while (segments.hasNext() i = indexSummary.getIndexInterval())
{
FileDataInput in = segments.next();
try
{
-while (!in.isEOF() i = metadata.getIndexInterval())
+while (!in.isEOF() i = indexSummary.getIndexInterval())
{
i++;
[jira] [Resolved] (CASSANDRA-5731) Should use index_interval from already loaded index summary
[ https://issues.apache.org/jira/browse/CASSANDRA-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita resolved CASSANDRA-5731. --- Resolution: Fixed Fix Version/s: (was: 2.0) 2.0 beta 1 Reviewer: jbellis Committed. Should use index_interval from already loaded index summary --- Key: CASSANDRA-5731 URL: https://issues.apache.org/jira/browse/CASSANDRA-5731 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Yuki Morishita Assignee: Yuki Morishita Priority: Trivial Fix For: 2.0 beta 1 Attachments: 5731.txt Since index_interval can be changed anytime in 2.0, SSTableReader should use index interval from loaded summary. -- 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: scripts fail when paths contain whitespace
Updated Branches:
refs/heads/cassandra-1.2 f8c072e97 - 909b2ed1a
scripts fail when paths contain whitespace
Patch by Amichai Rothman; Reviewed by eevans for CASSANDRA-5338
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/909b2ed1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/909b2ed1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/909b2ed1
Branch: refs/heads/cassandra-1.2
Commit: 909b2ed1a939048cd372bbf97918f0a69f80af92
Parents: f8c072e
Author: Eric Evans eev...@apache.org
Authored: Mon Jul 8 14:20:40 2013 -0500
Committer: Eric Evans eev...@apache.org
Committed: Mon Jul 8 14:20:40 2013 -0500
--
bin/cassandra | 10 +-
bin/cassandra-cli | 20 ++--
bin/cassandra-shuffle | 24
bin/cassandra.in.sh | 16
bin/debug-cql | 4 ++--
bin/json2sstable | 20 ++--
bin/nodetool | 30 +++---
bin/sstable2json | 20 ++--
bin/sstablekeys | 22 +++---
bin/sstableloader | 20 ++--
bin/sstablescrub | 20 ++--
11 files changed, 103 insertions(+), 103 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/909b2ed1/bin/cassandra
--
diff --git a/bin/cassandra b/bin/cassandra
index 25498aa..1fbf047 100755
--- a/bin/cassandra
+++ b/bin/cassandra
@@ -71,7 +71,7 @@ if [ x$CASSANDRA_INCLUDE = x ]; then
/usr/local/share/cassandra/cassandra.in.sh \
/opt/cassandra/cassandra.in.sh \
$HOME/.cassandra.in.sh \
- `dirname $0`/cassandra.in.sh; do
+ `dirname $0`/cassandra.in.sh; do
if [ -r $include ]; then
. $include
break
@@ -120,10 +120,10 @@ esac
launch_service()
{
-pidpath=$1
-foreground=$2
-props=$3
-class=$4
+pidpath=$1
+foreground=$2
+props=$3
+class=$4
cassandra_parms=-Dlog4j.configuration=log4j-server.properties
-Dlog4j.defaultInitOverride=true
if [ x$pidpath != x ]; then
http://git-wip-us.apache.org/repos/asf/cassandra/blob/909b2ed1/bin/cassandra-cli
--
diff --git a/bin/cassandra-cli b/bin/cassandra-cli
index c5fe27b..56c3095 100755
--- a/bin/cassandra-cli
+++ b/bin/cassandra-cli
@@ -21,29 +21,29 @@ if [ x$CASSANDRA_INCLUDE = x ]; then
/usr/local/share/cassandra/cassandra.in.sh \
/opt/cassandra/cassandra.in.sh \
~/.cassandra.in.sh \
- `dirname $0`/cassandra.in.sh; do
-if [ -r $include ]; then
-. $include
+ `dirname $0`/cassandra.in.sh; do
+if [ -r $include ]; then
+. $include
break
fi
done
-elif [ -r $CASSANDRA_INCLUDE ]; then
-. $CASSANDRA_INCLUDE
+elif [ -r $CASSANDRA_INCLUDE ]; then
+. $CASSANDRA_INCLUDE
fi
# Use JAVA_HOME if set, otherwise look for java in PATH
-if [ -x $JAVA_HOME/bin/java ]; then
-JAVA=$JAVA_HOME/bin/java
+if [ -x $JAVA_HOME/bin/java ]; then
+JAVA=$JAVA_HOME/bin/java
else
-JAVA=`which java`
+JAVA=`which java`
fi
-if [ -z $CLASSPATH ]; then
+if [ -z $CLASSPATH ]; then
echo You must set the CLASSPATH var 2
exit 1
fi
-$JAVA -ea -cp $CLASSPATH -Xmx256M \
+$JAVA -ea -cp $CLASSPATH -Xmx256M \
-Dlog4j.configuration=log4j-tools.properties \
org.apache.cassandra.cli.CliMain $@
http://git-wip-us.apache.org/repos/asf/cassandra/blob/909b2ed1/bin/cassandra-shuffle
--
diff --git a/bin/cassandra-shuffle b/bin/cassandra-shuffle
index d6dabfe..53636f7 100755
--- a/bin/cassandra-shuffle
+++ b/bin/cassandra-shuffle
@@ -19,24 +19,24 @@ if [ x$CASSANDRA_INCLUDE = x ]; then
for include in /usr/share/cassandra/cassandra.in.sh \
/usr/local/share/cassandra/cassandra.in.sh \
/opt/cassandra/cassandra.in.sh \
- `dirname $0`/cassandra.in.sh; do
-if [ -r $include ]; then
-. $include
+ `dirname $0`/cassandra.in.sh; do
+if [ -r $include ]; then
+. $include
break
fi
done
-elif [ -r $CASSANDRA_INCLUDE ]; then
-. $CASSANDRA_INCLUDE
+elif [ -r $CASSANDRA_INCLUDE ]; then
+. $CASSANDRA_INCLUDE
fi
# Use JAVA_HOME if set, otherwise look for java in PATH
-if [ -x $JAVA_HOME/bin/java ]; then
-JAVA=$JAVA_HOME/bin/java
+if [ -x $JAVA_HOME/bin/java ]; then
+JAVA=$JAVA_HOME/bin/java
else
-JAVA=`which
[jira] [Updated] (CASSANDRA-5729) Add new TimestampType to cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-5729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-5729: - Attachment: 5729.txt Add new TimestampType to cqlsh -- Key: CASSANDRA-5729 URL: https://issues.apache.org/jira/browse/CASSANDRA-5729 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Priority: Minor Fix For: 2.0 Attachments: 5729.txt Since cqlsh used CQL-over-thrift currently, we'd need to add support for the new TimestampType introduced in CASSANDRA-5723. -- 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-5729) Add new TimestampType to cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-5729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702341#comment-13702341 ] Brandon Williams commented on CASSANDRA-5729: - +1 Add new TimestampType to cqlsh -- Key: CASSANDRA-5729 URL: https://issues.apache.org/jira/browse/CASSANDRA-5729 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Aleksey Yeschenko Priority: Minor Fix For: 2.0 Attachments: 5729.txt Since cqlsh used CQL-over-thrift currently, we'd need to add support for the new TimestampType introduced in CASSANDRA-5723. -- 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-5697) cqlsh doesn't allow semicolons in BATCH statements
[ https://issues.apache.org/jira/browse/CASSANDRA-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702340#comment-13702340 ] Brandon Williams commented on CASSANDRA-5697: - +1 cqlsh doesn't allow semicolons in BATCH statements -- Key: CASSANDRA-5697 URL: https://issues.apache.org/jira/browse/CASSANDRA-5697 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.0 Environment: Mac OSX, cqlsh 3.0.2 Reporter: Russell Alexander Spitzer Assignee: Aleksey Yeschenko Priority: Minor Labels: cqlsh Fix For: 1.2.7 Attachments: 5697.txt The documentation for BATCH statements declares that semicolons are required between update operations. Currently including them results in an error 'expecting K_APPLY'. To match the design specifications, semi-colons should be allowed or optional. -- 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: cqlsh: support the new TimestampType
Updated Branches: refs/heads/trunk 2de07250d - 61772d3d7 cqlsh: support the new TimestampType patch by Aleksey Yeschenko; reviewed by Brandon Williams for CASSANDRA-5729 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/61772d3d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/61772d3d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/61772d3d Branch: refs/heads/trunk Commit: 61772d3d7b333071268675653ded650b59c36496 Parents: 2de0725 Author: Aleksey Yeschenko alek...@apache.org Authored: Mon Jul 8 23:08:19 2013 +0300 Committer: Aleksey Yeschenko alek...@apache.org Committed: Mon Jul 8 23:08:19 2013 +0300 -- CHANGES.txt| 2 +- pylib/cqlshlib/cql3handling.py | 6 +- 2 files changed, 6 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/61772d3d/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 4b7dcc5..88683c2 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -72,7 +72,7 @@ * Move resultset type information into prepare, not execute (CASSANDRA-5649) * Auto paging in binary protocol (CASSANDRA-4415, 5714) * Don't tie client side use of AbstractType to JDBC (CASSANDRA-4495) - * Adds new TimestampType to replace DateType (CASSANDRA-5723) + * Adds new TimestampType to replace DateType (CASSANDRA-5723, CASSANDRA-5729) 1.2.7 http://git-wip-us.apache.org/repos/asf/cassandra/blob/61772d3d/pylib/cqlshlib/cql3handling.py -- diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py index 110fd6a..40d22c6 100644 --- a/pylib/cqlshlib/cql3handling.py +++ b/pylib/cqlshlib/cql3handling.py @@ -18,7 +18,7 @@ import re from warnings import warn from .cqlhandling import CqlParsingRuleSet, Hint from cql.cqltypes import (cql_types, lookup_casstype, CompositeType, UTF8Type, - ColumnToCollectionType, CounterColumnType) + ColumnToCollectionType, CounterColumnType, DateType) from . import helptopics simple_cql_types = set(cql_types) @@ -31,6 +31,10 @@ try: except ImportError: import simplejson as json +# temporarily have this here until a newer cassandra-dbapi2 is bundled with C* +class TimestampType(DateType): +pass + class UnexpectedTableStructure(UserWarning): def __init__(self, msg): self.msg = msg
[jira] [Updated] (CASSANDRA-5520) Query tracing session info inconsistent with events info
[
https://issues.apache.org/jira/browse/CASSANDRA-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-5520:
---
Description:
Session info for a trace is showing that a query took 10 seconds (it timed
out).
{noformat}
cqlsh:system_traces select session_id, duration, request from sessions where
session_id = c7e36a30-af3a-11e2-9ec9-772ec39805fe;
session_id | duration | request
c7e36a30-af3a-11e2-9ec9-772ec39805fe | 1230 | multiget_slice
However, the event-level breakdown shows no such large duration:
cqlsh:system_traces select * from events where session_id =
c7e36a30-af3a-11e2-9ec9-772ec39805fe;
session_id | event_id | activity | source | source_elapsed | thread
-+---
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e36a30-af3a-11e2-9480-e9d811e0fc18 |
Message received from /xxx.xxx.90.147 | xxx.xxx.4.16 | 19 | Thread-57
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e36a31-af3a-11e2-9ec9-772ec39805fe |
Sending message to /xxx.xxx.153.16 | xxx.xxx.90.147 | 246 | WRITE-/xxx.xxx.4.16
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39140-af3a-11e2-9480-e9d811e0fc18 |
Message received from /xxx.xxx.90.147 | xxx.xxx.4.16 | 259 | Thread-57
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39140-af3a-11e2-9ec9-772ec39805fe |
Sending message to /10.248.106.37 | xxx.xxx.90.147 | 253 | WRITE-/xxx.xxx.79.52
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39140-af3a-11e2-b8dc-a7032a583115 |
Message received from /xxx.xxx.90.147 | xxx.xxx.213.136 | 25 | Thread-94
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39141-af3a-11e2-9480-e9d811e0fc18 |
Executing single-partition query on CardHash | xxx.xxx.4.16 | 421 |
ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39141-af3a-11e2-9ec9-772ec39805fe |
Sending message to /xxx.xxx.151.214 | xxx.xxx.90.147 | 310 |
WRITE-/xxx.xxx.213.136
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39141-af3a-11e2-b8dc-a7032a583115 |
Message received from /xxx.xxx.90.147 | xxx.xxx.213.136 | 106 | Thread-94
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39142-af3a-11e2-9480-e9d811e0fc18 |
Acquiring sstable references | xxx.xxx.4.16 | 444 | ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39142-af3a-11e2-9ec9-772ec39805fe |
Sending message to /10.248.106.37 | xxx.xxx.90.147 | 352 | WRITE-/xxx.xxx.79.52
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39142-af3a-11e2-b8dc-a7032a583115 |
Executing single-partition query on CardHash | xxx.xxx.213.136 | 144 |
ReadStage:11
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39143-af3a-11e2-9480-e9d811e0fc18 |
Merging memtable contents | xxx.xxx.4.16 | 472 | ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39143-af3a-11e2-9ec9-772ec39805fe |
Sending message to /10.248.95.237 | xxx.xxx.90.147 | 362 |
WRITE-/xxx.xxx.201.218
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39143-af3a-11e2-b8dc-a7032a583115 |
Acquiring sstable references | xxx.xxx.213.136 | 164 | ReadStage:11
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39144-af3a-11e2-9480-e9d811e0fc18 |
Merging data from memtables and 0 sstables | xxx.xxx.4.16 | 510 | ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39144-af3a-11e2-9ec9-772ec39805fe |
Sending message to /xxx.xxx.151.214 | xxx.xxx.90.147 | 376 |
WRITE-/xxx.xxx.213.136
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39144-af3a-11e2-b8dc-a7032a583115 |
Merging memtable contents | xxx.xxx.213.136 | 195 | ReadStage:11
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39145-af3a-11e2-9480-e9d811e0fc18 |
Read 0 live cells and 0 tombstoned | xxx.xxx.4.16 | 530 | ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39145-af3a-11e2-9ec9-772ec39805fe |
Sending message to /10.248.95.237 | xxx.xxx.90.147 | 401 |
WRITE-/xxx.xxx.201.218
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39145-af3a-11e2-b8dc-a7032a583115 |
Executing single-partition query on CardHash | xxx.xxx.213.136 | 202 |
ReadStage:41
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39146-af3a-11e2-9480-e9d811e0fc18 |
Enqueuing response to /xxx.xxx.90.147 | xxx.xxx.4.16 | 572 | ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39146-af3a-11e2-9ec9-772ec39805fe |
Sending message to /xxx.xxx.153.16 | xxx.xxx.90.147 | 489 | WRITE-/xxx.xxx.4.16
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39146-af3a-11e2-b8dc-a7032a583115 |
Acquiring sstable references | xxx.xxx.213.136 | 215 | ReadStage:41
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39147-af3a-11e2-9480-e9d811e0fc18 |
Executing single-partition query on CardHash | xxx.xxx.4.16 | 610 |
ReadStage:5330
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39147-af3a-11e2-b8dc-a7032a583115 |
Merging data from memtables and 0 sstables | xxx.xxx.213.136 | 239 |
ReadStage:11
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39148-af3a-11e2-9480-e9d811e0fc18 |
Acquiring
git commit: cqlsh: fix handling of semicolons inside BATCH queries
Updated Branches:
refs/heads/cassandra-1.2 909b2ed1a - c1d71213b
cqlsh: fix handling of semicolons inside BATCH queries
patch by Aleksey Yeschenko; reviewed by Brandon Williams for
CASSANDRA-5697
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c1d71213
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c1d71213
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c1d71213
Branch: refs/heads/cassandra-1.2
Commit: c1d71213bdb6f5d326f5cc5a55e645a8edf2e589
Parents: 909b2ed
Author: Aleksey Yeschenko alek...@apache.org
Authored: Mon Jul 8 22:57:35 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Mon Jul 8 22:57:35 2013 +0300
--
CHANGES.txt| 1 +
pylib/cqlshlib/cql3handling.py | 4 ++--
pylib/cqlshlib/cqlhandling.py | 10 --
3 files changed, 7 insertions(+), 8 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1d71213/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7c16cd0..65dd404 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -9,6 +9,7 @@
* Fix skipping range tombstones with reverse queries (CASSANDRA-5712)
* Expire entries out of ThriftSessionManager (CASSANRDA-5719)
* Don't keep ancestor information in memory (CASSANDRA-5342)
+ * cqlsh: fix handling of semicolons inside BATCH queries (CASSANDRA-5697)
1.2.6
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1d71213/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 0e631ea..92701d6 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -986,8 +986,8 @@ syntax_rules += r'''
batchStatement ::= BEGIN ( UNLOGGED | COUNTER )? BATCH
( USING [batchopt]=usingOption
( AND [batchopt]=usingOption )* )?
-[batchstmt]=batchStatementMember ;
-( [batchstmt]=batchStatementMember ; )*
+[batchstmt]=batchStatementMember ;?
+( [batchstmt]=batchStatementMember ;? )*
APPLY BATCH
;
batchStatementMember ::= insertStatement
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1d71213/pylib/cqlshlib/cqlhandling.py
--
diff --git a/pylib/cqlshlib/cqlhandling.py b/pylib/cqlshlib/cqlhandling.py
index 83e1dc2..7d36301 100644
--- a/pylib/cqlshlib/cqlhandling.py
+++ b/pylib/cqlshlib/cqlhandling.py
@@ -189,13 +189,11 @@ class CqlParsingRuleSet(pylexotron.ParsingRuleSet):
output[-1].extend(stmt)
else:
output.append(stmt)
-if len(stmt) 1 \
-and stmt[0][0] == 'identifier' and stmt[1][0] == 'identifier' \
-and stmt[1][1].lower() == 'batch':
-if stmt[0][1].lower() == 'begin':
-in_batch = True
-elif stmt[0][1].lower() == 'apply':
+if len(stmt) 2:
+if stmt[-3][0] == 'K_APPLY':
in_batch = False
+elif stmt[0][0] == 'K_BEGIN':
+in_batch = True
return output, in_batch
def cql_complete_single(self, text, partial, init_bindings={},
ignore_case=True,
[2/2] git commit: Merge branch '1.2' into trunk
Merge branch '1.2' into trunk Conflicts: bin/cassandra bin/cassandra-cli bin/json2sstable bin/nodetool bin/sstable2json bin/sstablekeys bin/sstableloader Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a307c174 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a307c174 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a307c174 Branch: refs/heads/trunk Commit: a307c174997fabed46269375bab503c93a5e986a Parents: 61772d3 909b2ed Author: Eric Evans eev...@apache.org Authored: Mon Jul 8 15:25:00 2013 -0500 Committer: Eric Evans eev...@apache.org Committed: Mon Jul 8 15:25:00 2013 -0500 -- bin/cassandra | 10 +- bin/cassandra-cli | 20 ++-- bin/cassandra-shuffle | 24 bin/cassandra.in.sh | 16 bin/debug-cql | 4 ++-- bin/json2sstable | 20 ++-- bin/nodetool | 30 +++--- bin/sstable2json | 20 ++-- bin/sstablekeys | 22 +++--- bin/sstableloader | 20 ++-- bin/sstablescrub | 20 ++-- 11 files changed, 103 insertions(+), 103 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a307c174/bin/cassandra -- diff --cc bin/cassandra index e6b1220,1fbf047..78d0660 --- a/bin/cassandra +++ b/bin/cassandra @@@ -67,11 -67,11 +67,11 @@@ # If an include wasn't specified in the environment, then search for one... if [ x$CASSANDRA_INCLUDE = x ]; then # Locations (in order) to use when searching for an include file. - for include in `dirname $0`/cassandra.in.sh \ -for include in /usr/share/cassandra/cassandra.in.sh \ - /usr/local/share/cassandra/cassandra.in.sh \ - /opt/cassandra/cassandra.in.sh \ ++for include in `dirname $0`/cassandra.in.sh \ $HOME/.cassandra.in.sh \ - `dirname $0`/cassandra.in.sh; do + /usr/share/cassandra/cassandra.in.sh \ + /usr/local/share/cassandra/cassandra.in.sh \ + /opt/cassandra/cassandra.in.sh; do if [ -r $include ]; then . $include break http://git-wip-us.apache.org/repos/asf/cassandra/blob/a307c174/bin/cassandra-cli -- diff --cc bin/cassandra-cli index 23d7dbb,56c3095..ea52b8e --- a/bin/cassandra-cli +++ b/bin/cassandra-cli @@@ -17,13 -17,13 +17,13 @@@ # limitations under the License. if [ x$CASSANDRA_INCLUDE = x ]; then - for include in `dirname $0`/cassandra.in.sh \ -for include in /usr/share/cassandra/cassandra.in.sh \ ++for include in `dirname $0`/cassandra.in.sh \ + $HOME/.cassandra.in.sh \ + /usr/share/cassandra/cassandra.in.sh \ /usr/local/share/cassandra/cassandra.in.sh \ - /opt/cassandra/cassandra.in.sh \ - ~/.cassandra.in.sh \ - `dirname $0`/cassandra.in.sh; do + /opt/cassandra/cassandra.in.sh; do - if [ -r $include ]; then - . $include + if [ -r $include ]; then + . $include break fi done http://git-wip-us.apache.org/repos/asf/cassandra/blob/a307c174/bin/json2sstable -- diff --cc bin/json2sstable index 29d2e46,f41afd3..8da7634 --- a/bin/json2sstable +++ b/bin/json2sstable @@@ -17,13 -17,13 +17,13 @@@ # limitations under the License. if [ x$CASSANDRA_INCLUDE = x ]; then - for include in `dirname $0`/cassandra.in.sh \ -for include in /usr/share/cassandra/cassandra.in.sh \ ++for include in `dirname $0`/cassandra.in.sh \ + $HOME/.cassandra.in.sh \ + /usr/share/cassandra/cassandra.in.sh \ /usr/local/share/cassandra/cassandra.in.sh \ - /opt/cassandra/cassandra.in.sh \ - ~/.cassandra.in.sh \ - `dirname $0`/cassandra.in.sh; do + /opt/cassandra/cassandra.in.sh; do - if [ -r $include ]; then - . $include + if [ -r $include ]; then + . $include break fi done http://git-wip-us.apache.org/repos/asf/cassandra/blob/a307c174/bin/nodetool -- diff --cc bin/nodetool index 54201f4,c602530..13f9178 --- a/bin/nodetool +++ b/bin/nodetool @@@ -22,13 -22,12 +22,13 @@@ if [
[1/2] git commit: scripts fail when paths contain whitespace
Updated Branches:
refs/heads/trunk 61772d3d7 - a307c1749
scripts fail when paths contain whitespace
Patch by Amichai Rothman; Reviewed by eevans for CASSANDRA-5338
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/909b2ed1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/909b2ed1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/909b2ed1
Branch: refs/heads/trunk
Commit: 909b2ed1a939048cd372bbf97918f0a69f80af92
Parents: f8c072e
Author: Eric Evans eev...@apache.org
Authored: Mon Jul 8 14:20:40 2013 -0500
Committer: Eric Evans eev...@apache.org
Committed: Mon Jul 8 14:20:40 2013 -0500
--
bin/cassandra | 10 +-
bin/cassandra-cli | 20 ++--
bin/cassandra-shuffle | 24
bin/cassandra.in.sh | 16
bin/debug-cql | 4 ++--
bin/json2sstable | 20 ++--
bin/nodetool | 30 +++---
bin/sstable2json | 20 ++--
bin/sstablekeys | 22 +++---
bin/sstableloader | 20 ++--
bin/sstablescrub | 20 ++--
11 files changed, 103 insertions(+), 103 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/909b2ed1/bin/cassandra
--
diff --git a/bin/cassandra b/bin/cassandra
index 25498aa..1fbf047 100755
--- a/bin/cassandra
+++ b/bin/cassandra
@@ -71,7 +71,7 @@ if [ x$CASSANDRA_INCLUDE = x ]; then
/usr/local/share/cassandra/cassandra.in.sh \
/opt/cassandra/cassandra.in.sh \
$HOME/.cassandra.in.sh \
- `dirname $0`/cassandra.in.sh; do
+ `dirname $0`/cassandra.in.sh; do
if [ -r $include ]; then
. $include
break
@@ -120,10 +120,10 @@ esac
launch_service()
{
-pidpath=$1
-foreground=$2
-props=$3
-class=$4
+pidpath=$1
+foreground=$2
+props=$3
+class=$4
cassandra_parms=-Dlog4j.configuration=log4j-server.properties
-Dlog4j.defaultInitOverride=true
if [ x$pidpath != x ]; then
http://git-wip-us.apache.org/repos/asf/cassandra/blob/909b2ed1/bin/cassandra-cli
--
diff --git a/bin/cassandra-cli b/bin/cassandra-cli
index c5fe27b..56c3095 100755
--- a/bin/cassandra-cli
+++ b/bin/cassandra-cli
@@ -21,29 +21,29 @@ if [ x$CASSANDRA_INCLUDE = x ]; then
/usr/local/share/cassandra/cassandra.in.sh \
/opt/cassandra/cassandra.in.sh \
~/.cassandra.in.sh \
- `dirname $0`/cassandra.in.sh; do
-if [ -r $include ]; then
-. $include
+ `dirname $0`/cassandra.in.sh; do
+if [ -r $include ]; then
+. $include
break
fi
done
-elif [ -r $CASSANDRA_INCLUDE ]; then
-. $CASSANDRA_INCLUDE
+elif [ -r $CASSANDRA_INCLUDE ]; then
+. $CASSANDRA_INCLUDE
fi
# Use JAVA_HOME if set, otherwise look for java in PATH
-if [ -x $JAVA_HOME/bin/java ]; then
-JAVA=$JAVA_HOME/bin/java
+if [ -x $JAVA_HOME/bin/java ]; then
+JAVA=$JAVA_HOME/bin/java
else
-JAVA=`which java`
+JAVA=`which java`
fi
-if [ -z $CLASSPATH ]; then
+if [ -z $CLASSPATH ]; then
echo You must set the CLASSPATH var 2
exit 1
fi
-$JAVA -ea -cp $CLASSPATH -Xmx256M \
+$JAVA -ea -cp $CLASSPATH -Xmx256M \
-Dlog4j.configuration=log4j-tools.properties \
org.apache.cassandra.cli.CliMain $@
http://git-wip-us.apache.org/repos/asf/cassandra/blob/909b2ed1/bin/cassandra-shuffle
--
diff --git a/bin/cassandra-shuffle b/bin/cassandra-shuffle
index d6dabfe..53636f7 100755
--- a/bin/cassandra-shuffle
+++ b/bin/cassandra-shuffle
@@ -19,24 +19,24 @@ if [ x$CASSANDRA_INCLUDE = x ]; then
for include in /usr/share/cassandra/cassandra.in.sh \
/usr/local/share/cassandra/cassandra.in.sh \
/opt/cassandra/cassandra.in.sh \
- `dirname $0`/cassandra.in.sh; do
-if [ -r $include ]; then
-. $include
+ `dirname $0`/cassandra.in.sh; do
+if [ -r $include ]; then
+. $include
break
fi
done
-elif [ -r $CASSANDRA_INCLUDE ]; then
-. $CASSANDRA_INCLUDE
+elif [ -r $CASSANDRA_INCLUDE ]; then
+. $CASSANDRA_INCLUDE
fi
# Use JAVA_HOME if set, otherwise look for java in PATH
-if [ -x $JAVA_HOME/bin/java ]; then
-JAVA=$JAVA_HOME/bin/java
+if [ -x $JAVA_HOME/bin/java ]; then
+JAVA=$JAVA_HOME/bin/java
else
-JAVA=`which java`
+
[1/2] git commit: cqlsh: fix handling of semicolons inside BATCH queries
Updated Branches:
refs/heads/trunk a307c1749 - 36a661394
cqlsh: fix handling of semicolons inside BATCH queries
patch by Aleksey Yeschenko; reviewed by Brandon Williams for
CASSANDRA-5697
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c1d71213
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c1d71213
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c1d71213
Branch: refs/heads/trunk
Commit: c1d71213bdb6f5d326f5cc5a55e645a8edf2e589
Parents: 909b2ed
Author: Aleksey Yeschenko alek...@apache.org
Authored: Mon Jul 8 22:57:35 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Mon Jul 8 22:57:35 2013 +0300
--
CHANGES.txt| 1 +
pylib/cqlshlib/cql3handling.py | 4 ++--
pylib/cqlshlib/cqlhandling.py | 10 --
3 files changed, 7 insertions(+), 8 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1d71213/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7c16cd0..65dd404 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -9,6 +9,7 @@
* Fix skipping range tombstones with reverse queries (CASSANDRA-5712)
* Expire entries out of ThriftSessionManager (CASSANRDA-5719)
* Don't keep ancestor information in memory (CASSANDRA-5342)
+ * cqlsh: fix handling of semicolons inside BATCH queries (CASSANDRA-5697)
1.2.6
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1d71213/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 0e631ea..92701d6 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -986,8 +986,8 @@ syntax_rules += r'''
batchStatement ::= BEGIN ( UNLOGGED | COUNTER )? BATCH
( USING [batchopt]=usingOption
( AND [batchopt]=usingOption )* )?
-[batchstmt]=batchStatementMember ;
-( [batchstmt]=batchStatementMember ; )*
+[batchstmt]=batchStatementMember ;?
+( [batchstmt]=batchStatementMember ;? )*
APPLY BATCH
;
batchStatementMember ::= insertStatement
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c1d71213/pylib/cqlshlib/cqlhandling.py
--
diff --git a/pylib/cqlshlib/cqlhandling.py b/pylib/cqlshlib/cqlhandling.py
index 83e1dc2..7d36301 100644
--- a/pylib/cqlshlib/cqlhandling.py
+++ b/pylib/cqlshlib/cqlhandling.py
@@ -189,13 +189,11 @@ class CqlParsingRuleSet(pylexotron.ParsingRuleSet):
output[-1].extend(stmt)
else:
output.append(stmt)
-if len(stmt) 1 \
-and stmt[0][0] == 'identifier' and stmt[1][0] == 'identifier' \
-and stmt[1][1].lower() == 'batch':
-if stmt[0][1].lower() == 'begin':
-in_batch = True
-elif stmt[0][1].lower() == 'apply':
+if len(stmt) 2:
+if stmt[-3][0] == 'K_APPLY':
in_batch = False
+elif stmt[0][0] == 'K_BEGIN':
+in_batch = True
return output, in_batch
def cql_complete_single(self, text, partial, init_bindings={},
ignore_case=True,
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/36a66139 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/36a66139 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/36a66139 Branch: refs/heads/trunk Commit: 36a661394e738d7dbc459ffa56e188286f7d2c7e Parents: a307c17 c1d7121 Author: Aleksey Yeschenko alek...@apache.org Authored: Mon Jul 8 23:34:44 2013 +0300 Committer: Aleksey Yeschenko alek...@apache.org Committed: Mon Jul 8 23:34:44 2013 +0300 -- CHANGES.txt| 1 + pylib/cqlshlib/cql3handling.py | 4 ++-- pylib/cqlshlib/cqlhandling.py | 10 -- 3 files changed, 7 insertions(+), 8 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a66139/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a66139/pylib/cqlshlib/cql3handling.py -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/36a66139/pylib/cqlshlib/cqlhandling.py --
[jira] [Created] (CASSANDRA-5732) Can not query secondary index
Tony Anecito created CASSANDRA-5732: --- Summary: Can not query secondary index Key: CASSANDRA-5732 URL: https://issues.apache.org/jira/browse/CASSANDRA-5732 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Environment: Windows 8, Jre 1.6.0_45 16-bit Reporter: Tony Anecito Noticed after taking a column family that already existed and assigning to an IntegerType index_type:KEYS and the caching was already set to 'ALL' that the prepared statement do not return rows neither did it throw an exception. Here is the sequence. 1. Starting state query running with caching off for a Column Family with the query using the secondary index for te WHERE clause. 2, Set Column Family caching to ALL using Cassandra-CLI and update CQL. Cassandra-cli Describe shows column family caching set to ALL 3. Rerun query and it works. 4. Restart Cassandra and run query and no rows returned. Cassandra-cli Describe shows column family caching set to ALL 5. Set Column Family caching to NONE using Cassandra-cli and update CQL. Rerun query and no rows returned. Cassandra-cli Describe for column family shows caching set to NONE. 6. Restart Cassandra. Rerun query and it is working again. We are now back to the starting state. Best Regards, -Tony -- 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-5520) Query tracing session info inconsistent with events info
[
https://issues.apache.org/jira/browse/CASSANDRA-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702467#comment-13702467
]
Tyler Hobbs commented on CASSANDRA-5520:
bq. If we're going to gold-plate it, including the result in the trace (but not
the debug call, we only want to construct it if requested, because creating
Strings is expensive) is a good idea too.
Can you elaborate on what you mean by including the result in the trace? Are
you just referring to the exception details that Sylvain mentioned?
Query tracing session info inconsistent with events info
Key: CASSANDRA-5520
URL: https://issues.apache.org/jira/browse/CASSANDRA-5520
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.2.4
Environment: Linux
Reporter: Ilya Kirnos
Assignee: Tyler Hobbs
Priority: Minor
Session info for a trace is showing that a query took 10 seconds (it timed
out).
{noformat}
cqlsh:system_traces select session_id, duration, request from sessions where
session_id = c7e36a30-af3a-11e2-9ec9-772ec39805fe;
session_id | duration | request
c7e36a30-af3a-11e2-9ec9-772ec39805fe | 1230 | multiget_slice
However, the event-level breakdown shows no such large duration:
cqlsh:system_traces select * from events where session_id =
c7e36a30-af3a-11e2-9ec9-772ec39805fe;
session_id | event_id | activity | source | source_elapsed | thread
-+---
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e36a30-af3a-11e2-9480-e9d811e0fc18 |
Message received from /xxx.xxx.90.147 | xxx.xxx.4.16 | 19 | Thread-57
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e36a31-af3a-11e2-9ec9-772ec39805fe |
Sending message to /xxx.xxx.153.16 | xxx.xxx.90.147 | 246 |
WRITE-/xxx.xxx.4.16
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39140-af3a-11e2-9480-e9d811e0fc18 |
Message received from /xxx.xxx.90.147 | xxx.xxx.4.16 | 259 | Thread-57
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39140-af3a-11e2-9ec9-772ec39805fe |
Sending message to /10.248.106.37 | xxx.xxx.90.147 | 253 |
WRITE-/xxx.xxx.79.52
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39140-af3a-11e2-b8dc-a7032a583115 |
Message received from /xxx.xxx.90.147 | xxx.xxx.213.136 | 25 | Thread-94
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39141-af3a-11e2-9480-e9d811e0fc18 |
Executing single-partition query on CardHash | xxx.xxx.4.16 | 421 |
ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39141-af3a-11e2-9ec9-772ec39805fe |
Sending message to /xxx.xxx.151.214 | xxx.xxx.90.147 | 310 |
WRITE-/xxx.xxx.213.136
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39141-af3a-11e2-b8dc-a7032a583115 |
Message received from /xxx.xxx.90.147 | xxx.xxx.213.136 | 106 | Thread-94
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39142-af3a-11e2-9480-e9d811e0fc18 |
Acquiring sstable references | xxx.xxx.4.16 | 444 | ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39142-af3a-11e2-9ec9-772ec39805fe |
Sending message to /10.248.106.37 | xxx.xxx.90.147 | 352 |
WRITE-/xxx.xxx.79.52
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39142-af3a-11e2-b8dc-a7032a583115 |
Executing single-partition query on CardHash | xxx.xxx.213.136 | 144 |
ReadStage:11
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39143-af3a-11e2-9480-e9d811e0fc18 |
Merging memtable contents | xxx.xxx.4.16 | 472 | ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39143-af3a-11e2-9ec9-772ec39805fe |
Sending message to /10.248.95.237 | xxx.xxx.90.147 | 362 |
WRITE-/xxx.xxx.201.218
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39143-af3a-11e2-b8dc-a7032a583115 |
Acquiring sstable references | xxx.xxx.213.136 | 164 | ReadStage:11
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39144-af3a-11e2-9480-e9d811e0fc18 |
Merging data from memtables and 0 sstables | xxx.xxx.4.16 | 510 |
ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39144-af3a-11e2-9ec9-772ec39805fe |
Sending message to /xxx.xxx.151.214 | xxx.xxx.90.147 | 376 |
WRITE-/xxx.xxx.213.136
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39144-af3a-11e2-b8dc-a7032a583115 |
Merging memtable contents | xxx.xxx.213.136 | 195 | ReadStage:11
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39145-af3a-11e2-9480-e9d811e0fc18 |
Read 0 live cells and 0 tombstoned | xxx.xxx.4.16 | 530 | ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39145-af3a-11e2-9ec9-772ec39805fe |
Sending message to /10.248.95.237 | xxx.xxx.90.147 | 401 |
WRITE-/xxx.xxx.201.218
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39145-af3a-11e2-b8dc-a7032a583115 |
Executing single-partition query on
[jira] [Updated] (CASSANDRA-5732) Can not query secondary index
[ https://issues.apache.org/jira/browse/CASSANDRA-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Anecito updated CASSANDRA-5732: Environment: Windows 8, Jre 1.6.0_45 32-bit (was: Windows 8, Jre 1.6.0_45 16-bit) Can not query secondary index - Key: CASSANDRA-5732 URL: https://issues.apache.org/jira/browse/CASSANDRA-5732 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Environment: Windows 8, Jre 1.6.0_45 32-bit Reporter: Tony Anecito Noticed after taking a column family that already existed and assigning to an IntegerType index_type:KEYS and the caching was already set to 'ALL' that the prepared statement do not return rows neither did it throw an exception. Here is the sequence. 1. Starting state query running with caching off for a Column Family with the query using the secondary index for te WHERE clause. 2, Set Column Family caching to ALL using Cassandra-CLI and update CQL. Cassandra-cli Describe shows column family caching set to ALL 3. Rerun query and it works. 4. Restart Cassandra and run query and no rows returned. Cassandra-cli Describe shows column family caching set to ALL 5. Set Column Family caching to NONE using Cassandra-cli and update CQL. Rerun query and no rows returned. Cassandra-cli Describe for column family shows caching set to NONE. 6. Restart Cassandra. Rerun query and it is working again. We are now back to the starting state. Best Regards, -Tony -- 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-5520) Query tracing session info inconsistent with events info
[
https://issues.apache.org/jira/browse/CASSANDRA-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702499#comment-13702499
]
Jonathan Ellis commented on CASSANDRA-5520:
---
I think I meant the timeout details, because logging the request result in the
timeout block doesn't make sense.
Query tracing session info inconsistent with events info
Key: CASSANDRA-5520
URL: https://issues.apache.org/jira/browse/CASSANDRA-5520
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.2.4
Environment: Linux
Reporter: Ilya Kirnos
Assignee: Tyler Hobbs
Priority: Minor
Session info for a trace is showing that a query took 10 seconds (it timed
out).
{noformat}
cqlsh:system_traces select session_id, duration, request from sessions where
session_id = c7e36a30-af3a-11e2-9ec9-772ec39805fe;
session_id | duration | request
c7e36a30-af3a-11e2-9ec9-772ec39805fe | 1230 | multiget_slice
However, the event-level breakdown shows no such large duration:
cqlsh:system_traces select * from events where session_id =
c7e36a30-af3a-11e2-9ec9-772ec39805fe;
session_id | event_id | activity | source | source_elapsed | thread
-+---
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e36a30-af3a-11e2-9480-e9d811e0fc18 |
Message received from /xxx.xxx.90.147 | xxx.xxx.4.16 | 19 | Thread-57
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e36a31-af3a-11e2-9ec9-772ec39805fe |
Sending message to /xxx.xxx.153.16 | xxx.xxx.90.147 | 246 |
WRITE-/xxx.xxx.4.16
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39140-af3a-11e2-9480-e9d811e0fc18 |
Message received from /xxx.xxx.90.147 | xxx.xxx.4.16 | 259 | Thread-57
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39140-af3a-11e2-9ec9-772ec39805fe |
Sending message to /10.248.106.37 | xxx.xxx.90.147 | 253 |
WRITE-/xxx.xxx.79.52
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39140-af3a-11e2-b8dc-a7032a583115 |
Message received from /xxx.xxx.90.147 | xxx.xxx.213.136 | 25 | Thread-94
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39141-af3a-11e2-9480-e9d811e0fc18 |
Executing single-partition query on CardHash | xxx.xxx.4.16 | 421 |
ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39141-af3a-11e2-9ec9-772ec39805fe |
Sending message to /xxx.xxx.151.214 | xxx.xxx.90.147 | 310 |
WRITE-/xxx.xxx.213.136
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39141-af3a-11e2-b8dc-a7032a583115 |
Message received from /xxx.xxx.90.147 | xxx.xxx.213.136 | 106 | Thread-94
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39142-af3a-11e2-9480-e9d811e0fc18 |
Acquiring sstable references | xxx.xxx.4.16 | 444 | ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39142-af3a-11e2-9ec9-772ec39805fe |
Sending message to /10.248.106.37 | xxx.xxx.90.147 | 352 |
WRITE-/xxx.xxx.79.52
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39142-af3a-11e2-b8dc-a7032a583115 |
Executing single-partition query on CardHash | xxx.xxx.213.136 | 144 |
ReadStage:11
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39143-af3a-11e2-9480-e9d811e0fc18 |
Merging memtable contents | xxx.xxx.4.16 | 472 | ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39143-af3a-11e2-9ec9-772ec39805fe |
Sending message to /10.248.95.237 | xxx.xxx.90.147 | 362 |
WRITE-/xxx.xxx.201.218
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39143-af3a-11e2-b8dc-a7032a583115 |
Acquiring sstable references | xxx.xxx.213.136 | 164 | ReadStage:11
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39144-af3a-11e2-9480-e9d811e0fc18 |
Merging data from memtables and 0 sstables | xxx.xxx.4.16 | 510 |
ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39144-af3a-11e2-9ec9-772ec39805fe |
Sending message to /xxx.xxx.151.214 | xxx.xxx.90.147 | 376 |
WRITE-/xxx.xxx.213.136
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39144-af3a-11e2-b8dc-a7032a583115 |
Merging memtable contents | xxx.xxx.213.136 | 195 | ReadStage:11
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39145-af3a-11e2-9480-e9d811e0fc18 |
Read 0 live cells and 0 tombstoned | xxx.xxx.4.16 | 530 | ReadStage:5329
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39145-af3a-11e2-9ec9-772ec39805fe |
Sending message to /10.248.95.237 | xxx.xxx.90.147 | 401 |
WRITE-/xxx.xxx.201.218
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39145-af3a-11e2-b8dc-a7032a583115 |
Executing single-partition query on CardHash | xxx.xxx.213.136 | 202 |
ReadStage:41
c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39146-af3a-11e2-9480-e9d811e0fc18 |
Enqueuing response to /xxx.xxx.90.147 | xxx.xxx.4.16 | 572 | ReadStage:5329
[jira] [Created] (CASSANDRA-5733) json2sstable can not read from a pipe even if -n and -s are specified.
Steven Lowenthal created CASSANDRA-5733:
---
Summary: json2sstable can not read from a pipe even if -n and -s
are specified.
Key: CASSANDRA-5733
URL: https://issues.apache.org/jira/browse/CASSANDRA-5733
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.2.6
Reporter: Steven Lowenthal
Priority: Minor
SSTableImport.importSorted always opens the file twice even if the number of
keys are specifed. I changed this to only open the file a second time when -n
is not specified.
I moved the second parser = getparser ... call inside the if (keyCountToImport
== null) block.
if (keyCountToImport == null)
{
keyCountToImport = 0;
System.out.println(Counting keys to import, please wait... (NOTE:
to skip this use -n num_keys));
parser.nextToken(); // START_ARRAY
while (parser.nextToken() != null)
{
parser.skipChildren();
if (parser.getCurrentToken() == JsonToken.END_ARRAY)
break;
keyCountToImport++;
}
parser = getParser(jsonFile); // renewing parser only if we read the
file already - to support streaming.
}
--
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-5733) json2sstable can not read from a pipe even if -n and -s are specified.
[
https://issues.apache.org/jira/browse/CASSANDRA-5733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702509#comment-13702509
]
Jonathan Ellis commented on CASSANDRA-5733:
---
Can you attach a patch? {{git diff 5733.txt}}
json2sstable can not read from a pipe even if -n and -s are specified.
--
Key: CASSANDRA-5733
URL: https://issues.apache.org/jira/browse/CASSANDRA-5733
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.2.6
Reporter: Steven Lowenthal
Priority: Minor
SSTableImport.importSorted always opens the file twice even if the number of
keys are specifed. I changed this to only open the file a second time when
-n is not specified.
I moved the second parser = getparser ... call inside the if
(keyCountToImport == null) block.
if (keyCountToImport == null)
{
keyCountToImport = 0;
System.out.println(Counting keys to import, please wait...
(NOTE: to skip this use -n num_keys));
parser.nextToken(); // START_ARRAY
while (parser.nextToken() != null)
{
parser.skipChildren();
if (parser.getCurrentToken() == JsonToken.END_ARRAY)
break;
keyCountToImport++;
}
parser = getParser(jsonFile); // renewing parser only if we read
the file already - to support streaming.
}
--
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-5669) Connection thrashing in multi-region ec2 during upgrade, due to messaging version
[ https://issues.apache.org/jira/browse/CASSANDRA-5669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702549#comment-13702549 ] Jason Brown commented on CASSANDRA-5669: How does this patch break the 'use localIP addr when in the same DC (ec2 region)'? Yes, it temporarily bypasses it during upgrades (due to insanity described in CASSANDRA-5660), but otherwise I believe it behaves as before. Is there a bug or subtlety that I'm not seeing? Connection thrashing in multi-region ec2 during upgrade, due to messaging version - Key: CASSANDRA-5669 URL: https://issues.apache.org/jira/browse/CASSANDRA-5669 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Jason Brown Assignee: Jason Brown Priority: Minor Labels: ec2, ec2multiregionsnitch, gossip Fix For: 1.2.6, 2.0 beta 1 Attachments: 5669-v1.diff, 5669-v2.diff While debugging the upgrading scenario described in CASSANDRA-5660, I discovered the ITC.close() will reset the message protocol version of a peer node that disconnects. CASSANDRA-5660 has a full description of the upgrade path, but basically the Ec2MultiRegionSnitch will close connections on the publicIP addr to reconnect on the privateIp, and this causes ITC to drop the message protocol version of previously known nodes. I think we want to hang onto that version so that when the newer node (re-)connects to the lower node version, it passes the correct protocol version rather than the current version (too high for the older node),the connection attempt getting dropped, and going through the dance again. To clarify, the 'thrashing' is at a rather low volume, from what I observed. Anecdotaly, perhaps one connection per second gets turned over. -- 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-5669) Connection thrashing in multi-region ec2 during upgrade, due to messaging version
[ https://issues.apache.org/jira/browse/CASSANDRA-5669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702557#comment-13702557 ] Vijay commented on CASSANDRA-5669: -- Yes because now reconnect to local ip is not happening during upgrades (you will try to connect in a Non SSL port within a DC) Lets say Public IP address is not open between node A and B (which are in the local DC and they are not seeds) then node A cannot talk to B if you dont reconnect using private IP... which is the case in https://issues.apache.org/jira/browse/CASSANDRA-5432?focusedCommentId=13637454page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13637454 Connection thrashing in multi-region ec2 during upgrade, due to messaging version - Key: CASSANDRA-5669 URL: https://issues.apache.org/jira/browse/CASSANDRA-5669 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Reporter: Jason Brown Assignee: Jason Brown Priority: Minor Labels: ec2, ec2multiregionsnitch, gossip Fix For: 1.2.6, 2.0 beta 1 Attachments: 5669-v1.diff, 5669-v2.diff While debugging the upgrading scenario described in CASSANDRA-5660, I discovered the ITC.close() will reset the message protocol version of a peer node that disconnects. CASSANDRA-5660 has a full description of the upgrade path, but basically the Ec2MultiRegionSnitch will close connections on the publicIP addr to reconnect on the privateIp, and this causes ITC to drop the message protocol version of previously known nodes. I think we want to hang onto that version so that when the newer node (re-)connects to the lower node version, it passes the correct protocol version rather than the current version (too high for the older node),the connection attempt getting dropped, and going through the dance again. To clarify, the 'thrashing' is at a rather low volume, from what I observed. Anecdotaly, perhaps one connection per second gets turned over. -- 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-5542) BulkLoader is broken in trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702583#comment-13702583 ] Yuki Morishita commented on CASSANDRA-5542: --- I added querying schema part to bulk loader and successfully opened SSTables, but now I'm stuck on the change in streaming. New streaming now connects from both endpoints, so bulk loader also needs to listen on storage port to receive message from the loading nodes. I think we don't want to make bulk loader a fat client again... [~slebresne] Any suggestion for fixing this issue? BulkLoader is broken in trunk - Key: CASSANDRA-5542 URL: https://issues.apache.org/jira/browse/CASSANDRA-5542 Project: Cassandra Issue Type: Bug Affects Versions: 2.0 beta 1 Reporter: Yuki Morishita Assignee: Yuki Morishita Fix For: 2.0 Attachments: 5542-fix-NPE.txt, 5542.txt After CASSANDRA-5015 and CASSANDRA-5521, we need CFMetaData to open SSTable(Reader), especially to get bloom_filter_fp_chance and index_interval. When using bulkloader, CFMetaData is not available, so we cannot open SSTable to be streamed. -- 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-5734) Print usage when command is not specified in nodetool instead of connection failure
Manoj Mainali created CASSANDRA-5734:
Summary: Print usage when command is not specified in nodetool
instead of connection failure
Key: CASSANDRA-5734
URL: https://issues.apache.org/jira/browse/CASSANDRA-5734
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.2.6
Reporter: Manoj Mainali
Priority: Minor
nodetool command tries to establish connection to the cassandra node before
ensuring that the command is valid. Therefore, when no command is specified it
will print
{noformat}
$ bin/nodetool
Failed to connect to '127.0.0.1:7199': Connection refused
{noformat}
That means we need to have a running instance of C* to check the available
commands. But this is a syntax error and usage can be displayed (which is the
result even if a C* is running) even without a C* instance. Probably, it would
be better to make sure that the command sytnax is valid and print usage if not.
By doing this, we can easily check the available commands.
Additionally, same should apply for the help command. Since, help will not be
connecting to the C* instance, we should not have a dependency on a running C*.
--
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-5734) Print usage when command is not specified in nodetool instead of connection failure
[
https://issues.apache.org/jira/browse/CASSANDRA-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manoj Mainali updated CASSANDRA-5734:
-
Attachment: trunk-CASSANDRA-5734.patch
Print usage when command is not specified in nodetool instead of connection
failure
---
Key: CASSANDRA-5734
URL: https://issues.apache.org/jira/browse/CASSANDRA-5734
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.2.6
Reporter: Manoj Mainali
Priority: Minor
Attachments: trunk-CASSANDRA-5734.patch
nodetool command tries to establish connection to the cassandra node before
ensuring that the command is valid. Therefore, when no command is specified
it will print
{noformat}
$ bin/nodetool
Failed to connect to '127.0.0.1:7199': Connection refused
{noformat}
That means we need to have a running instance of C* to check the available
commands. But this is a syntax error and usage can be displayed (which is the
result even if a C* is running) even without a C* instance. Probably, it
would be better to make sure that the command sytnax is valid and print usage
if not. By doing this, we can easily check the available commands.
Additionally, same should apply for the help command. Since, help will not be
connecting to the C* instance, we should not have a dependency on a running
C*.
--
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-5735) Add binary server status to the node information
Manoj Mainali created CASSANDRA-5735: Summary: Add binary server status to the node information Key: CASSANDRA-5735 URL: https://issues.apache.org/jira/browse/CASSANDRA-5735 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2.6 Reporter: Manoj Mainali Priority: Minor nodetool info gives the gossip and thrift active status. Now, since there is a binary server it is nice to have the binary status too. -- 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-5735) Add binary server status to the node information
[ https://issues.apache.org/jira/browse/CASSANDRA-5735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Mainali updated CASSANDRA-5735: - Attachment: trunk-CASSANDRA-5735.patch Add binary server status to the node information Key: CASSANDRA-5735 URL: https://issues.apache.org/jira/browse/CASSANDRA-5735 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2.6 Reporter: Manoj Mainali Priority: Minor Attachments: trunk-CASSANDRA-5735.patch nodetool info gives the gossip and thrift active status. Now, since there is a binary server it is nice to have the binary status too. -- 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-5734) Print usage when command is not specified in nodetool instead of connection failure
[
https://issues.apache.org/jira/browse/CASSANDRA-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manoj Mainali updated CASSANDRA-5734:
-
Description:
nodetool command tries to establish connection to the cassandra node before
ensuring that the command is valid. Therefore, when no command is specified it
will print (in the case when C* is not running)
{noformat}
$ bin/nodetool
Failed to connect to '127.0.0.1:7199': Connection refused
{noformat}
That means we need to have a running instance of C* to check the available
commands. But this is a syntax error and usage can be displayed (which is the
result even if a C* is running) even without a C* instance. Probably, it would
be better to make sure that the command sytnax is valid and print usage if not.
By doing this, we can easily check the available commands.
Additionally, same should apply for the help command. Since, help will not be
connecting to the C* instance, we should not have a dependency on a running C*.
was:
nodetool command tries to establish connection to the cassandra node before
ensuring that the command is valid. Therefore, when no command is specified it
will print
{noformat}
$ bin/nodetool
Failed to connect to '127.0.0.1:7199': Connection refused
{noformat}
That means we need to have a running instance of C* to check the available
commands. But this is a syntax error and usage can be displayed (which is the
result even if a C* is running) even without a C* instance. Probably, it would
be better to make sure that the command sytnax is valid and print usage if not.
By doing this, we can easily check the available commands.
Additionally, same should apply for the help command. Since, help will not be
connecting to the C* instance, we should not have a dependency on a running C*.
Print usage when command is not specified in nodetool instead of connection
failure
---
Key: CASSANDRA-5734
URL: https://issues.apache.org/jira/browse/CASSANDRA-5734
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.2.6
Reporter: Manoj Mainali
Priority: Minor
Attachments: trunk-CASSANDRA-5734.patch
nodetool command tries to establish connection to the cassandra node before
ensuring that the command is valid. Therefore, when no command is specified
it will print (in the case when C* is not running)
{noformat}
$ bin/nodetool
Failed to connect to '127.0.0.1:7199': Connection refused
{noformat}
That means we need to have a running instance of C* to check the available
commands. But this is a syntax error and usage can be displayed (which is the
result even if a C* is running) even without a C* instance. Probably, it
would be better to make sure that the command sytnax is valid and print usage
if not. By doing this, we can easily check the available commands.
Additionally, same should apply for the help command. Since, help will not be
connecting to the C* instance, we should not have a dependency on a running
C*.
--
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-5732) Can not query secondary index
[ https://issues.apache.org/jira/browse/CASSANDRA-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702913#comment-13702913 ] Tony Anecito commented on CASSANDRA-5732: - Hi, I tried the same set of tables, data, java code in Windows 7 jre 1.7.0_05 64-bit and it seems to not have the issue so far. Will try other environment using 1.7.0_x 32 then 64-bit to see if that solves the issue. Regards, -Tony Can not query secondary index - Key: CASSANDRA-5732 URL: https://issues.apache.org/jira/browse/CASSANDRA-5732 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Environment: Windows 8, Jre 1.6.0_45 32-bit Reporter: Tony Anecito Noticed after taking a column family that already existed and assigning to an IntegerType index_type:KEYS and the caching was already set to 'ALL' that the prepared statement do not return rows neither did it throw an exception. Here is the sequence. 1. Starting state query running with caching off for a Column Family with the query using the secondary index for te WHERE clause. 2, Set Column Family caching to ALL using Cassandra-CLI and update CQL. Cassandra-cli Describe shows column family caching set to ALL 3. Rerun query and it works. 4. Restart Cassandra and run query and no rows returned. Cassandra-cli Describe shows column family caching set to ALL 5. Set Column Family caching to NONE using Cassandra-cli and update CQL. Rerun query and no rows returned. Cassandra-cli Describe for column family shows caching set to NONE. 6. Restart Cassandra. Rerun query and it is working again. We are now back to the starting state. Best Regards, -Tony -- 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
