git commit: (cql3) Fix queries using LIMIT missing results
Updated Branches:
refs/heads/trunk 12691ae3a - 6fc30803e
(cql3) Fix queries using LIMIT missing results
patch by slebresne; reviewed by xedin for CASSANDRA-4579
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6fc30803
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6fc30803
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6fc30803
Branch: refs/heads/trunk
Commit: 6fc30803e13e9d73f3d1a8141bc306f251e734d4
Parents: 12691ae
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Sep 18 08:34:23 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Sep 18 08:34:23 2012 +0200
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/SelectStatement.java |7 ++-
.../cassandra/db/filter/SliceQueryFilter.java | 13 ++---
3 files changed, 13 insertions(+), 8 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fc30803/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 3235855..1dd875e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -63,6 +63,7 @@
* Add sstable count per level to cfstats (CASSANDRA-4537)
* (cql3) Add ALTER KEYSPACE statement (CASSANDRA-4611)
* (cql3) Allow defining default consistency levels (CASSANDRA-4448)
+ * (cql3) Fix queries using LIMIT missing results (CASSANDRA-4579)
1.1.6
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fc30803/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index 1c2b631..26086ad 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -196,6 +196,11 @@ public class SelectStatement implements CQLStatement
try
{
+// The LIMIT provided by the user is the number of CQL row he
wants returned.
+// For NamesQueryFilter, this is the number of internal rows
returned, since a NamesQueryFilter can only select one CQL row in a given
internal row.
+// For SliceQueryFilter however, we want to have getRangeSlice to
count the number of columns, not the number of keys. Then
+// SliceQueryFilter.collectReducedColumns will correctly columns
having the same composite prefix using ColumnCounter.
+boolean maxIsColumns = filter instanceof SliceQueryFilter;
rows = StorageProxy.getRangeSlice(new RangeSliceCommand(keyspace(),
columnFamily(),
null,
@@ -203,7 +208,7 @@ public class SelectStatement implements CQLStatement
getKeyBounds(variables),
expressions,
getLimit(),
-true, //
limit by columns, not keys
+
maxIsColumns,
false),
getConsistencyLevel());
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6fc30803/src/java/org/apache/cassandra/db/filter/SliceQueryFilter.java
--
diff --git a/src/java/org/apache/cassandra/db/filter/SliceQueryFilter.java
b/src/java/org/apache/cassandra/db/filter/SliceQueryFilter.java
index 6b36f4e..2de284a 100644
--- a/src/java/org/apache/cassandra/db/filter/SliceQueryFilter.java
+++ b/src/java/org/apache/cassandra/db/filter/SliceQueryFilter.java
@@ -149,13 +149,6 @@ public class SliceQueryFilter implements IFilter
while (reducedColumns.hasNext())
{
-if (columnCounter.live() = count)
-{
-logger.debug(Read %s live columns and %s tombstoned,
- columnCounter.live(), columnCounter.ignored());
-break;
-}
-
IColumn column = reducedColumns.next();
if (logger.isTraceEnabled())
logger.trace(String.format(collecting %s of %s: %s,
@@ -163,6 +156,12 @@ public class SliceQueryFilter implements IFilter
columnCounter.count(column, container);
+if
[2/2] git commit: cqlsh: adapt to CASSANDRA-4018 system cf changes
cqlsh: adapt to CASSANDRA-4018 system cf changes
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9ec77eb6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9ec77eb6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9ec77eb6
Branch: refs/heads/trunk
Commit: 9ec77eb66ec4106fde1b8ecaf17c2aca521fe9f0
Parents: 6fc3080
Author: paul cannon p...@datastax.com
Authored: Sat Aug 4 23:10:00 2012 -0600
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Sep 18 09:09:39 2012 +0200
--
bin/cqlsh | 42 --
pylib/cqlshlib/cql3handling.py | 12 -
2 files changed, 44 insertions(+), 10 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9ec77eb6/bin/cqlsh
--
diff --git a/bin/cqlsh b/bin/cqlsh
index 42a77cc..43b1e53 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -434,6 +434,7 @@ class Shell(cmd.Cmd):
tempcurs.execute('USE %s;' % self.cql_protect_name(keyspace))
tempcurs.close()
self.cursor = self.conn.cursor()
+self.get_connection_versions()
self.current_keyspace = keyspace
@@ -470,6 +471,9 @@ class Shell(cmd.Cmd):
def cqlver_atleast(self, major, minor=0, patch=0):
return self.cql_ver_tuple[:3] = (major, minor, patch)
+def cassandraver_atleast(self, major, minor=0, patch=0):
+return self.cass_ver_tuple[:3] = (major, minor, patch)
+
def myformat_value(self, val, casstype, **kwargs):
if isinstance(val, DecodeError):
self.decoding_errors.append(val)
@@ -491,7 +495,7 @@ class Shell(cmd.Cmd):
self.port)
def show_version(self):
-vers = self.get_cluster_versions()
+vers = self.connection_versions.copy()
vers['shver'] = version
# system.Versions['cql'] apparently does not reflect changes with
# set_cql_version.
@@ -524,7 +528,22 @@ class Shell(cmd.Cmd):
% (cf, colname, cql_typename(vtype))
print
-def get_cluster_versions(self):
+def get_connection_versions(self):
+try:
+self.cursor.execute(select * from system.local where key =
'local')
+except cql.ProgrammingError:
+vers = self.get_connection_versions_fallback()
+else:
+result = self.fetchdict()
+vers = {
+'build': result['release_version'],
+'thrift': result['thrift_version'],
+'cql': result['cql_version'],
+}
+self.connection_versions = vers
+self.cass_ver_tuple = tuple(map(int, vers['build'].split('-',
1)[0].split('.', 2)))
+
+def get_connection_versions_fallback(self):
if self.cqlver_atleast(3):
query = 'select component, version from system.Versions'
else:
@@ -660,15 +679,21 @@ class Shell(cmd.Cmd):
def get_columnfamily_layout(self, ksname, cfname):
if ksname is None:
ksname = self.current_keyspace
-self.cursor.execute(select * from system.schema_columnfamilies
-where keyspace=:ks and columnfamily=:cf,
-{'ks': ksname, 'cf': cfname})
+if self.cassandraver_atleast(1, 2):
+cf_q = select * from system.schema_columnfamilies
+ where keyspace_name=:ks and columnfamily_name=:cf
+col_q = select * from system.schema_columns
+where keyspace_name=:ks and columnfamily_name=:cf
+else:
+cf_q = select * from system.schema_columnfamilies
+ where keyspace=:ks and columnfamily=:cf
+col_q = select * from system.schema_columns
+where keyspace=:ks and columnfamily=:cf
+self.cursor.execute(cf_q, {'ks': ksname, 'cf': cfname})
layout = self.fetchdict()
if layout is None:
raise ColumnFamilyNotFound(Column family %r not found % cfname)
-self.cursor.execute(select * from system.schema_columns
-where keyspace=:ks and columnfamily=:cf,
-{'ks': ksname, 'cf': cfname})
+self.cursor.execute(col_q, {'ks': ksname, 'cf': cfname})
cols = self.fetchdict_all()
return cql3handling.CqlTableDef.from_layout(layout, cols)
@@ -1544,6 +1569,7 @@ class Shell(cmd.Cmd):
showwhat = parsed.get_binding('what').lower()
if showwhat == 'version':
+self.get_connection_versions()
self.show_version()
elif showwhat == 'host':
self.show_host()
[1/2] git commit: cqlsh: update DESCRIBE support for collections
Updated Branches:
refs/heads/trunk 6fc30803e - ebd60fb74
cqlsh: update DESCRIBE support for collections
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ebd60fb7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ebd60fb7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ebd60fb7
Branch: refs/heads/trunk
Commit: ebd60fb74d2a3e5fdf7ab6fda63ed59dafa0aa27
Parents: 9ec77eb
Author: paul cannon p...@datastax.com
Authored: Sun Aug 19 18:00:46 2012 -0600
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Sep 18 09:30:25 2012 +0200
--
bin/cqlsh | 21 ++-
pylib/cqlshlib/cql3handling.py | 295 ---
2 files changed, 215 insertions(+), 101 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ebd60fb7/bin/cqlsh
--
diff --git a/bin/cqlsh b/bin/cqlsh
index 43b1e53..21cce89 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -554,7 +554,7 @@ class Shell(cmd.Cmd):
except cql.ProgrammingError:
# older Cassandra; doesn't have system.Versions
thrift_ver = self.get_thrift_version()
-return {'build': 'unknown', 'cql': 'unknown', 'thrift': thrift_ver}
+return {'build': '0.0.0', 'cql': 'unknown', 'thrift': thrift_ver}
return vers
def fetchdict(self):
@@ -1188,19 +1188,28 @@ class Shell(cmd.Cmd):
cfname = self.cql_protect_name(layout.name)
out.write(CREATE TABLE %s (\n % cfname)
keycol = layout.columns[0]
-out.write( %s %s % (self.cql_protect_name(keycol.name),
keycol.cqltype))
-if len(layout.key_components) == 1:
+out.write( %s %s % (self.cql_protect_name(keycol.name),
+ keycol.cqltype.cql_parameterized_type()))
+if len(layout.primary_key_components) == 1:
out.write( PRIMARY KEY)
indexed_columns = []
for col in layout.columns[1:]:
colname = self.cql_protect_name(col.name)
-out.write(,\n %s %s % (colname, col.cqltype))
+out.write(,\n %s %s % (colname,
col.cqltype.cql_parameterized_type()))
if col.index_name is not None:
indexed_columns.append(col)
-if len(layout.key_components) 1:
-out.write(,\n PRIMARY KEY (%s) % ',
'.join(map(self.cql_protect_name, layout.key_components)))
+if len(layout.primary_key_components) 1:
+out.write(,\n PRIMARY KEY ()
+partkeynames = map(self.cql_protect_name,
layout.partition_key_components)
+if len(partkeynames) 1:
+partkey = (%s) % ', '.join(partkeynames)
+else:
+partkey = partkeynames[0]
+pk_parts = [partkey] + map(self.cql_protect_name,
layout.column_aliases)
+out.write(', '.join(pk_parts) + ')')
+
out.write(\n))
joiner = 'WITH'
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ebd60fb7/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index f1d7f81..9c5f337 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -17,7 +17,8 @@
import re
from warnings import warn
from .cqlhandling import CqlParsingRuleSet, Hint
-from cql.cqltypes import cql_types, cql_typename
+from cql.cqltypes import (cql_types, lookup_casstype, CompositeType, UTF8Type,
+ ColumnToCollectionType)
try:
import json
@@ -323,7 +324,7 @@ def select_order_column_completer(ctxt, cass):
if not keyname:
return [Hint(Can't ORDER BY here: need to specify partition key
in WHERE clause)]
layout = get_cf_layout(ctxt, cass)
-order_by_candidates = layout.key_components[1:] # can't order by first
part of key
+order_by_candidates = layout.column_aliases[:]
if len(order_by_candidates) len(prev_order_cols):
return [maybe_escape_name(order_by_candidates[len(prev_order_cols)])]
return [Hint('No more orderable columns here.')]
@@ -335,16 +336,21 @@ def relation_token_word_completer(ctxt, cass):
@completer_for('relation', 'rel_tokname')
def relation_token_subject_completer(ctxt, cass):
layout = get_cf_layout(ctxt, cass)
-return [layout.key_components[0]]
+return [layout.partition_key_components[0]]
@completer_for('relation', 'rel_lhs')
def select_relation_lhs_completer(ctxt, cass):
layout = get_cf_layout(ctxt, cass)
-filterable = set(layout.key_components[:2])
-already_filtered_on = ctxt.get_binding('rel_lhs')
-for num in range(1, len(layout.key_components)):
-
[jira] [Resolved] (CASSANDRA-4491) cqlsh needs to use system.local instead of system.Versions
[ https://issues.apache.org/jira/browse/CASSANDRA-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-4491. - Resolution: Fixed I've committed the first 2 patches then. cqlsh needs to use system.local instead of system.Versions -- Key: CASSANDRA-4491 URL: https://issues.apache.org/jira/browse/CASSANDRA-4491 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Priority: Minor Labels: cqlsh Fix For: 1.2.0 beta 1 Apparently the system.Versions table was removed as part of CASSANDRA-4018. cqlsh in 1.2 should use system.local preferentially, and fall back on system.Versions to keep backwards compatibility with older c*. Also changed in 4018: all the system.schema_* CFs now use columns named keyspace_name, columnfamily_name, and column_name instead of keyspace, columnfamily, and column. While we're at it, let's update the cql3 table structure parsing and the DESCRIBE command for the recent Cassandra changes 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] [Commented] (CASSANDRA-4018) Add column metadata to system columnfamilies
[ https://issues.apache.org/jira/browse/CASSANDRA-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457681#comment-13457681 ] Hudson commented on CASSANDRA-4018: --- Integrated in Cassandra #2117 (See [https://builds.apache.org/job/Cassandra/2117/]) cqlsh: adapt to CASSANDRA-4018 system cf changes (Revision 9ec77eb66ec4106fde1b8ecaf17c2aca521fe9f0) Result = ABORTED sylvain : Files : * bin/cqlsh * pylib/cqlshlib/cql3handling.py Add column metadata to system columnfamilies Key: CASSANDRA-4018 URL: https://issues.apache.org/jira/browse/CASSANDRA-4018 Project: Cassandra Issue Type: Improvement Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.2.0 beta 1 CASSANDRA-3792 adds this to the schema CFs; we should modernize the other system CFs as well -- 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-4621) AssertionError in StorageProxy.getRestrictedRange
[ https://issues.apache.org/jira/browse/CASSANDRA-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4621: Attachment: 4621-followup.txt AssertionError in StorageProxy.getRestrictedRange - Key: CASSANDRA-4621 URL: https://issues.apache.org/jira/browse/CASSANDRA-4621 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Environment: archlinux, openjdk7 Reporter: Pierre-Yves Ritschard Assignee: Sylvain Lebresne Fix For: 1.2.0 beta 1 Attachments: 4621-followup.txt, 4621.txt, 4621.txt On a freshly built cassandra from trunk, I can create a column family with a composite row key using the syntax: for instance a standard eventlog CF: CREATE TABLE events ( facility text, prio int, message text, PRIMARY KEY ( (facility, prio) ) ); A simple query will then generate exceptions: SELECT * FROM events; will yield: ERROR 15:33:40,383 Exception in thread Thread[Thrift:1,5,main] java.lang.AssertionError: [min(0),max(-8021625467324731134)] at org.apache.cassandra.dht.Bounds.init(Bounds.java:41) at org.apache.cassandra.dht.Bounds.split(Bounds.java:59) at org.apache.cassandra.service.StorageProxy.getRestrictedRanges(StorageProxy.java:1073) at org.apache.cassandra.service.StorageProxy.getRangeSlice(StorageProxy.java:879) at org.apache.cassandra.cql3.statements.SelectStatement.multiRangeSlice(SelectStatement.java:209) at org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:128) at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118) at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62) at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107) at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115) at org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521) at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618) at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606) at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32) at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- 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] [Reopened] (CASSANDRA-4621) AssertionError in StorageProxy.getRestrictedRange
[ https://issues.apache.org/jira/browse/CASSANDRA-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne reopened CASSANDRA-4621: - Reopening this since the midpoint calculation for murmur3Partitioner is actually broken by having negative tokens (concretely, Murmur3PartitionerTest is failing). Attaching patch to fix it. AssertionError in StorageProxy.getRestrictedRange - Key: CASSANDRA-4621 URL: https://issues.apache.org/jira/browse/CASSANDRA-4621 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Environment: archlinux, openjdk7 Reporter: Pierre-Yves Ritschard Assignee: Sylvain Lebresne Fix For: 1.2.0 beta 1 Attachments: 4621-followup.txt, 4621.txt, 4621.txt On a freshly built cassandra from trunk, I can create a column family with a composite row key using the syntax: for instance a standard eventlog CF: CREATE TABLE events ( facility text, prio int, message text, PRIMARY KEY ( (facility, prio) ) ); A simple query will then generate exceptions: SELECT * FROM events; will yield: ERROR 15:33:40,383 Exception in thread Thread[Thrift:1,5,main] java.lang.AssertionError: [min(0),max(-8021625467324731134)] at org.apache.cassandra.dht.Bounds.init(Bounds.java:41) at org.apache.cassandra.dht.Bounds.split(Bounds.java:59) at org.apache.cassandra.service.StorageProxy.getRestrictedRanges(StorageProxy.java:1073) at org.apache.cassandra.service.StorageProxy.getRangeSlice(StorageProxy.java:879) at org.apache.cassandra.cql3.statements.SelectStatement.multiRangeSlice(SelectStatement.java:209) at org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:128) at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118) at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62) at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107) at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115) at org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521) at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618) at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606) at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32) at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- 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-4676) Can't delete/create a keyspace
Ivan Sobolev created CASSANDRA-4676: --- Summary: Can't delete/create a keyspace Key: CASSANDRA-4676 URL: https://issues.apache.org/jira/browse/CASSANDRA-4676 Project: Cassandra Issue Type: Bug Environment: CentOs 5.5. Cassandra 1.0.6--1.1.5 Reporter: Ivan Sobolev The main question for me is what to try. Deletion/recreation of the keyspace is not possible for some reason and this prevents me from reinstalling OpsCenter(which I'd like to have). -- 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-4676) Can't delete/create a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Sobolev updated CASSANDRA-4676: Attachment: cassandra-ex.txt cassandra-cli.txt Can't delete/create a keyspace -- Key: CASSANDRA-4676 URL: https://issues.apache.org/jira/browse/CASSANDRA-4676 Project: Cassandra Issue Type: Bug Environment: CentOs 5.5. Cassandra 1.0.6--1.1.5 Reporter: Ivan Sobolev Attachments: cassandra-cli.txt, cassandra-ex.txt The main question for me is what to try. Deletion/recreation of the keyspace is not possible for some reason and this prevents me from reinstalling OpsCenter(which I'd like to have). -- 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-4676) Can't delete/create a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457727#comment-13457727 ] Ivan Sobolev commented on CASSANDRA-4676: - Cassandra-ex is what I can find on Cassandra logs when try to create a keyspace. Deletion is silent. Can't delete/create a keyspace -- Key: CASSANDRA-4676 URL: https://issues.apache.org/jira/browse/CASSANDRA-4676 Project: Cassandra Issue Type: Bug Environment: CentOs 5.5. Cassandra 1.0.6--1.1.5 Reporter: Ivan Sobolev Attachments: cassandra-cli.txt, cassandra-ex.txt The main question for me is what to try. Deletion/recreation of the keyspace is not possible for some reason and this prevents me from reinstalling OpsCenter(which I'd like to have). -- 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-4677) Change description of nodetool ring command
Alexey Zotov created CASSANDRA-4677:
---
Summary: Change description of nodetool ring command
Key: CASSANDRA-4677
URL: https://issues.apache.org/jira/browse/CASSANDRA-4677
Project: Cassandra
Issue Type: Task
Components: Tools
Affects Versions: 1.1.5
Reporter: Alexey Zotov
Priority: Trivial
Attachments: nodetool_ring_description.patch
Additional option of 'nodetool ring' command is not documented.
Old variant:
{code}
ring - Print information about the token ring
{code}
New variant
{code}
ring [keyspace]- Print information about the token ring for a given
keyspace (for all keyspaces if it is not specified)
{code}
Patch has been attached.
Some history (I think it will be useful for someone who will have the same
problem):
I have 4-nodes cluster. One of nodes is located in other DC (DC2). I've met the
problem that 'nodetool ring' shows that node in DC2 'Owns 0.00%'. I've found
following questions:
http://www.datastax.com/support-forums/topic/owns-in-nodetool
http://mail-archives.apache.org/mod_mbox/cassandra-user/201202.mbox/%3c323dbc99-8519-4e86-b69b-6520d53fa...@humbaba.net%3E
and task with fix:
https://issues.apache.org/jira/browse/CASSANDRA-3412
So you should use 'nodetool ring keyspace' for getting right information.
--
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-4677) Change description of nodetool ring command
[
https://issues.apache.org/jira/browse/CASSANDRA-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4677:
Attachment: nodetool_ring_description.patch
Change description of nodetool ring command
---
Key: CASSANDRA-4677
URL: https://issues.apache.org/jira/browse/CASSANDRA-4677
Project: Cassandra
Issue Type: Task
Components: Tools
Affects Versions: 1.1.5
Reporter: Alexey Zotov
Priority: Trivial
Labels: ring
Attachments: nodetool_ring_description.patch
Additional option of 'nodetool ring' command is not documented.
Old variant:
{code}
ring - Print information about the token ring
{code}
New variant
{code}
ring [keyspace]- Print information about the token ring for a given
keyspace (for all keyspaces if it is not specified)
{code}
Patch has been attached.
Some history (I think it will be useful for someone who will have the same
problem):
I have 4-nodes cluster. One of nodes is located in other DC (DC2). I've met
the problem that 'nodetool ring' shows that node in DC2 'Owns 0.00%'. I've
found following questions:
http://www.datastax.com/support-forums/topic/owns-in-nodetool
http://mail-archives.apache.org/mod_mbox/cassandra-user/201202.mbox/%3c323dbc99-8519-4e86-b69b-6520d53fa...@humbaba.net%3E
and task with fix:
https://issues.apache.org/jira/browse/CASSANDRA-3412
So you should use 'nodetool ring keyspace' for getting right information.
--
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-4676) Can't delete/create a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Sobolev updated CASSANDRA-4676:
Description:
Deletion/recreation of the keyspace was not possible.
*Workaround:*
use system;
set schema_keyspaces['OpsCenter']['durable_writes']=true;
set schema_keyspaces['OpsCenter']['strategy_options']='{datacenter1:1}';
set schema_keyspaces['OpsCenter']['name']='OpsCenter';
set
schema_keyspaces['OpsCenter']['strategy_class']='org.apache.cassandra.locator.NetworkTopologyStrategy';
drop keyspace OpsCenter;
was:
The main question for me is what to try. Deletion/recreation of the keyspace
was not possible.
*Workaround:*
use system;
set schema_keyspaces['OpsCenter']['durable_writes']=true;
set schema_keyspaces['OpsCenter']['strategy_options']='{datacenter1:1}';
set schema_keyspaces['OpsCenter']['name']='OpsCenter';
set
schema_keyspaces['OpsCenter']['strategy_class']='org.apache.cassandra.locator.NetworkTopologyStrategy';
drop keyspace OpsCenter;
Can't delete/create a keyspace
--
Key: CASSANDRA-4676
URL: https://issues.apache.org/jira/browse/CASSANDRA-4676
Project: Cassandra
Issue Type: Bug
Environment: CentOs 5.5.
Cassandra 1.0.6--1.1.5
Reporter: Ivan Sobolev
Attachments: cassandra-cli.txt, cassandra-ex.txt
Deletion/recreation of the keyspace was not possible.
*Workaround:*
use system;
set schema_keyspaces['OpsCenter']['durable_writes']=true;
set schema_keyspaces['OpsCenter']['strategy_options']='{datacenter1:1}';
set schema_keyspaces['OpsCenter']['name']='OpsCenter';
set
schema_keyspaces['OpsCenter']['strategy_class']='org.apache.cassandra.locator.NetworkTopologyStrategy';
drop keyspace OpsCenter;
--
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-4676) Can't delete/create a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Sobolev updated CASSANDRA-4676:
Description:
The main question for me is what to try. Deletion/recreation of the keyspace
was not possible.
*Workaround:*
use system;
set schema_keyspaces['OpsCenter']['durable_writes']=true;
set schema_keyspaces['OpsCenter']['strategy_options']='{datacenter1:1}';
set schema_keyspaces['OpsCenter']['name']='OpsCenter';
set
schema_keyspaces['OpsCenter']['strategy_class']='org.apache.cassandra.locator.NetworkTopologyStrategy';
drop keyspace OpsCenter;
was:The main question for me is what to try. Deletion/recreation of the
keyspace is not possible for some reason and this prevents me from reinstalling
OpsCenter(which I'd like to have).
Can't delete/create a keyspace
--
Key: CASSANDRA-4676
URL: https://issues.apache.org/jira/browse/CASSANDRA-4676
Project: Cassandra
Issue Type: Bug
Environment: CentOs 5.5.
Cassandra 1.0.6--1.1.5
Reporter: Ivan Sobolev
Attachments: cassandra-cli.txt, cassandra-ex.txt
The main question for me is what to try. Deletion/recreation of the keyspace
was not possible.
*Workaround:*
use system;
set schema_keyspaces['OpsCenter']['durable_writes']=true;
set schema_keyspaces['OpsCenter']['strategy_options']='{datacenter1:1}';
set schema_keyspaces['OpsCenter']['name']='OpsCenter';
set
schema_keyspaces['OpsCenter']['strategy_class']='org.apache.cassandra.locator.NetworkTopologyStrategy';
drop keyspace OpsCenter;
--
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-4676) Can't delete/create a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Sobolev updated CASSANDRA-4676:
Priority: Trivial (was: Major)
Can't delete/create a keyspace
--
Key: CASSANDRA-4676
URL: https://issues.apache.org/jira/browse/CASSANDRA-4676
Project: Cassandra
Issue Type: Bug
Environment: CentOs 5.5.
Cassandra 1.0.6--1.1.5
Reporter: Ivan Sobolev
Priority: Trivial
Attachments: cassandra-cli.txt, cassandra-ex.txt
Deletion/recreation of the keyspace was not possible.
*Workaround:*
use system;
set schema_keyspaces['OpsCenter']['durable_writes']=true;
set schema_keyspaces['OpsCenter']['strategy_options']='{datacenter1:1}';
set schema_keyspaces['OpsCenter']['name']='OpsCenter';
set
schema_keyspaces['OpsCenter']['strategy_class']='org.apache.cassandra.locator.NetworkTopologyStrategy';
drop keyspace OpsCenter;
--
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-4674) cqlsh COPY TO and COPY FROM don't work with cql3
[ https://issues.apache.org/jira/browse/CASSANDRA-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko resolved CASSANDRA-4674. -- Resolution: Not A Problem cqlsh COPY TO and COPY FROM don't work with cql3 Key: CASSANDRA-4674 URL: https://issues.apache.org/jira/browse/CASSANDRA-4674 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko Labels: cqlsh Attachments: FIX-CQLSH-COPY.patch cqlsh COPY TO and COPY FROM don't work with cql3 due to previous cql3 changes. -- 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-4674) cqlsh COPY TO and COPY FROM don't work with cql3
[ https://issues.apache.org/jira/browse/CASSANDRA-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-4674: - Attachment: (was: FIX-CQLSH-COPY.patch) cqlsh COPY TO and COPY FROM don't work with cql3 Key: CASSANDRA-4674 URL: https://issues.apache.org/jira/browse/CASSANDRA-4674 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko Labels: cqlsh cqlsh COPY TO and COPY FROM don't work with cql3 due to previous cql3 changes. -- 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-4678) Add possibility to stop repair session from nodetool
Alexey Zotov created CASSANDRA-4678: --- Summary: Add possibility to stop repair session from nodetool Key: CASSANDRA-4678 URL: https://issues.apache.org/jira/browse/CASSANDRA-4678 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.1.5 Reporter: Alexey Zotov Priority: Minor I've added possibility to stop repair session from nodetool. 'stoprepair' command has been introduced. -- 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-4678) Add possibility to stop repair session from nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zotov updated CASSANDRA-4678: Attachment: nodetool_stoprepair_command_v1.patch Add possibility to stop repair session from nodetool Key: CASSANDRA-4678 URL: https://issues.apache.org/jira/browse/CASSANDRA-4678 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.1.5 Reporter: Alexey Zotov Priority: Minor Labels: nodetool, repair Attachments: nodetool_stoprepair_command_v1.patch I've added possibility to stop repair session from nodetool. 'stoprepair' command has been introduced. -- 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-4679) Fix binary protocol NEW_NODE event
Sylvain Lebresne created CASSANDRA-4679: --- Summary: Fix binary protocol NEW_NODE event Key: CASSANDRA-4679 URL: https://issues.apache.org/jira/browse/CASSANDRA-4679 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 As discussed on CASSANDRA-4480, the NEW_NODE/REMOVED_NODE of the binary protocol are not correctly fired (NEW_NODE is fired on node UP basically). This ticket is to fix that. -- 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-4679) Fix binary protocol NEW_NODE event
[ https://issues.apache.org/jira/browse/CASSANDRA-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4679: Attachment: 4679.txt Attaching patch that adds a new listener interface for higher level events than the gossip ones. Fix binary protocol NEW_NODE event -- Key: CASSANDRA-4679 URL: https://issues.apache.org/jira/browse/CASSANDRA-4679 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 Attachments: 4679.txt As discussed on CASSANDRA-4480, the NEW_NODE/REMOVED_NODE of the binary protocol are not correctly fired (NEW_NODE is fired on node UP basically). This ticket is to fix that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: fix for M3P.midPoint patch by slebresne; reviewed by jbellis for CASSANDRA-4621
Updated Branches:
refs/heads/trunk ebd60fb74 - 0ea28c858
fix for M3P.midPoint
patch by slebresne; reviewed by jbellis for CASSANDRA-4621
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0ea28c85
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0ea28c85
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0ea28c85
Branch: refs/heads/trunk
Commit: 0ea28c858e3f693dc44d38cd4306e02049d01ce8
Parents: ebd60fb
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue Sep 18 09:42:00 2012 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue Sep 18 09:42:00 2012 -0500
--
.../apache/cassandra/dht/Murmur3Partitioner.java |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0ea28c85/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java
--
diff --git a/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java
b/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java
index 440b159..3e98e32 100644
--- a/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java
+++ b/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java
@@ -63,7 +63,13 @@ public class Murmur3Partitioner extends
AbstractPartitionerLongToken
else // wrapping case
{
BigInteger max = BigInteger.valueOf(MAXIMUM);
-midpoint = max.add(r).subtract(l).shiftRight(1).add(l).mod(max);
+BigInteger min = BigInteger.valueOf(MINIMUM.token);
+// length of range we're bisecting is (R - min) + (max - L)
+// so we add that to L giving
+// L + ((R - min) + (max - L) / 2) = (L + R + max - min) / 2
+midpoint = (max.subtract(min).add(l).add(r)).shiftRight(1);
+if (midpoint.compareTo(max) 0)
+midpoint = min.add(midpoint.subtract(max));
}
return new LongToken(midpoint.longValue());
[jira] [Resolved] (CASSANDRA-4621) AssertionError in StorageProxy.getRestrictedRange
[ https://issues.apache.org/jira/browse/CASSANDRA-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4621. --- Resolution: Fixed committed w/ additional comments AssertionError in StorageProxy.getRestrictedRange - Key: CASSANDRA-4621 URL: https://issues.apache.org/jira/browse/CASSANDRA-4621 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Environment: archlinux, openjdk7 Reporter: Pierre-Yves Ritschard Assignee: Sylvain Lebresne Fix For: 1.2.0 beta 1 Attachments: 4621-followup.txt, 4621.txt, 4621.txt On a freshly built cassandra from trunk, I can create a column family with a composite row key using the syntax: for instance a standard eventlog CF: CREATE TABLE events ( facility text, prio int, message text, PRIMARY KEY ( (facility, prio) ) ); A simple query will then generate exceptions: SELECT * FROM events; will yield: ERROR 15:33:40,383 Exception in thread Thread[Thrift:1,5,main] java.lang.AssertionError: [min(0),max(-8021625467324731134)] at org.apache.cassandra.dht.Bounds.init(Bounds.java:41) at org.apache.cassandra.dht.Bounds.split(Bounds.java:59) at org.apache.cassandra.service.StorageProxy.getRestrictedRanges(StorageProxy.java:1073) at org.apache.cassandra.service.StorageProxy.getRangeSlice(StorageProxy.java:879) at org.apache.cassandra.cql3.statements.SelectStatement.multiRangeSlice(SelectStatement.java:209) at org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:128) at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118) at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62) at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107) at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115) at org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521) at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618) at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606) at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32) at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- 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-4673) Compaction of HintsColumnFamily stucks
[ https://issues.apache.org/jira/browse/CASSANDRA-4673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457861#comment-13457861 ] Jonathan Ellis commented on CASSANDRA-4673: --- Let us know if you can reproduce on 1.1.5. Compaction of HintsColumnFamily stucks -- Key: CASSANDRA-4673 URL: https://issues.apache.org/jira/browse/CASSANDRA-4673 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.1 Environment: We've got a 24 nodes cluster with 3 virtual data centers. We've got 7 nodes with SSD drives. We are operating under very heavy read/write load. We typically seeing CPU usage 90% on our machines. We are using 1.1.2 - why this version is not listed in the 'Affected Version' drop down? Reporter: Bartłomiej Romański On some nodes the compaction of HintsColumnFamily stucked. Here is a typical output of 'nodetool compactionstats': pending tasks: 1 compaction typekeyspace column family bytes compacted bytes total progress Compaction systemHintsColumnFamily 346205828 34690966299.80% Active compaction remaining time : 0h00m00s Rebooting a node does not help. The compaction starts immediately after booting and stucks and the same point. If this can be related we are also expiring a problem described in CASSANDRA-4639. -- 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-4676) Can't delete/create a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-4676:
-
Assignee: Pavel Yaskevich
Can't delete/create a keyspace
--
Key: CASSANDRA-4676
URL: https://issues.apache.org/jira/browse/CASSANDRA-4676
Project: Cassandra
Issue Type: Bug
Environment: CentOs 5.5.
Cassandra 1.0.6--1.1.5
Reporter: Ivan Sobolev
Assignee: Pavel Yaskevich
Priority: Trivial
Attachments: cassandra-cli.txt, cassandra-ex.txt
Deletion/recreation of the keyspace was not possible.
*Workaround:*
use system;
set schema_keyspaces['OpsCenter']['durable_writes']=true;
set schema_keyspaces['OpsCenter']['strategy_options']='{datacenter1:1}';
set schema_keyspaces['OpsCenter']['name']='OpsCenter';
set
schema_keyspaces['OpsCenter']['strategy_class']='org.apache.cassandra.locator.NetworkTopologyStrategy';
drop keyspace OpsCenter;
--
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-4679) Fix binary protocol NEW_NODE event
[ https://issues.apache.org/jira/browse/CASSANDRA-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4679: -- Reviewer: yukim Fix binary protocol NEW_NODE event -- Key: CASSANDRA-4679 URL: https://issues.apache.org/jira/browse/CASSANDRA-4679 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 Attachments: 4679.txt As discussed on CASSANDRA-4480, the NEW_NODE/REMOVED_NODE of the binary protocol are not correctly fired (NEW_NODE is fired on node UP basically). This ticket is to fix that. -- 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-4678) Add possibility to stop repair session from nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457865#comment-13457865 ] Jonathan Ellis commented on CASSANDRA-4678: --- Something is wrong with your diff tool. I see literal backslash-enn sequences here instead of newlines. Add possibility to stop repair session from nodetool Key: CASSANDRA-4678 URL: https://issues.apache.org/jira/browse/CASSANDRA-4678 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.1.5 Reporter: Alexey Zotov Priority: Minor Labels: nodetool, repair Attachments: nodetool_stoprepair_command_v1.patch I've added possibility to stop repair session from nodetool. 'stoprepair' command has been introduced. -- 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-4677) Change description of nodetool ring command
[
https://issues.apache.org/jira/browse/CASSANDRA-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457866#comment-13457866
]
Jonathan Ellis commented on CASSANDRA-4677:
---
Please attach fixed diff. Suggest using commandline git instead of intellij.
Change description of nodetool ring command
---
Key: CASSANDRA-4677
URL: https://issues.apache.org/jira/browse/CASSANDRA-4677
Project: Cassandra
Issue Type: Task
Components: Tools
Affects Versions: 1.1.5
Reporter: Alexey Zotov
Priority: Trivial
Labels: ring
Attachments: nodetool_ring_description.patch
Additional option of 'nodetool ring' command is not documented.
Old variant:
{code}
ring - Print information about the token ring
{code}
New variant
{code}
ring [keyspace]- Print information about the token ring for a given
keyspace (for all keyspaces if it is not specified)
{code}
Patch has been attached.
Some history (I think it will be useful for someone who will have the same
problem):
I have 4-nodes cluster. One of nodes is located in other DC (DC2). I've met
the problem that 'nodetool ring' shows that node in DC2 'Owns 0.00%'. I've
found following questions:
http://www.datastax.com/support-forums/topic/owns-in-nodetool
http://mail-archives.apache.org/mod_mbox/cassandra-user/201202.mbox/%3c323dbc99-8519-4e86-b69b-6520d53fa...@humbaba.net%3E
and task with fix:
https://issues.apache.org/jira/browse/CASSANDRA-3412
So you should use 'nodetool ring keyspace' for getting right information.
--
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] git commit: Merge branch 'cassandra-1.1' into trunk
Updated Branches: refs/heads/cassandra-1.1 e7f28f303 - e6326e9fd refs/heads/trunk 0ea28c858 - dd79571f5 Merge branch 'cassandra-1.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/dd79571f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/dd79571f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/dd79571f Branch: refs/heads/trunk Commit: dd79571f5130c2623c1c7b8eea4b6a0cf9497661 Parents: 0ea28c8 e6326e9 Author: Jonathan Ellis jbel...@apache.org Authored: Tue Sep 18 09:57:25 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Tue Sep 18 09:57:25 2012 -0500 -- build.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/dd79571f/build.xml --
[3/3] git commit: increase long-test timeout
increase long-test timeout Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e6326e9f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e6326e9f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e6326e9f Branch: refs/heads/cassandra-1.1 Commit: e6326e9fd85fca0e81adb04b0405cb7db1b51ac6 Parents: e7f28f3 Author: Jonathan Ellis jbel...@apache.org Authored: Tue Sep 18 09:57:20 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Tue Sep 18 09:57:20 2012 -0500 -- build.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e6326e9f/build.xml -- diff --git a/build.xml b/build.xml index 6a97687..08b597b 100644 --- a/build.xml +++ b/build.xml @@ -84,7 +84,7 @@ property name=maven-repository-id value=apache.snapshots.https/ property name=test.timeout value=6 / -property name=test.long.timeout value=30 / +property name=test.long.timeout value=60 / !-- http://cobertura.sourceforge.net/ -- property name=cobertura.version value=1.9.4.1/
[2/3] git commit: increase long-test timeout
increase long-test timeout Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e6326e9f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e6326e9f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e6326e9f Branch: refs/heads/trunk Commit: e6326e9fd85fca0e81adb04b0405cb7db1b51ac6 Parents: e7f28f3 Author: Jonathan Ellis jbel...@apache.org Authored: Tue Sep 18 09:57:20 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Tue Sep 18 09:57:20 2012 -0500 -- build.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e6326e9f/build.xml -- diff --git a/build.xml b/build.xml index 6a97687..08b597b 100644 --- a/build.xml +++ b/build.xml @@ -84,7 +84,7 @@ property name=maven-repository-id value=apache.snapshots.https/ property name=test.timeout value=6 / -property name=test.long.timeout value=30 / +property name=test.long.timeout value=60 / !-- http://cobertura.sourceforge.net/ -- property name=cobertura.version value=1.9.4.1/
[jira] [Commented] (CASSANDRA-4675) NPE in NTS when using LQ against a node (DC) that doesn't have replica
[
https://issues.apache.org/jira/browse/CASSANDRA-4675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457883#comment-13457883
]
Jonathan Ellis commented on CASSANDRA-4675:
---
Not sure what version this stacktrace is supposed to be against. Doesn't
appear to be against a recent 1.0 or 1.1.
NPE in NTS when using LQ against a node (DC) that doesn't have replica
--
Key: CASSANDRA-4675
URL: https://issues.apache.org/jira/browse/CASSANDRA-4675
Project: Cassandra
Issue Type: Bug
Reporter: Jackson Chung
Priority: Minor
in a NetworkTopologyStrategy where there are 2 DC:
{panel}
Address DC RackStatus State LoadOwns
Token
85070591730234615865843651857942052864
127.0.0.1 dc1 r1 Up Normal 115.78 KB 50.00%
0
127.0.0.2 dc2 r1 Up Normal 129.3 KB50.00%
85070591730234615865843651857942052864
{panel}
I have a KS that has replica is 1 of the dc (dc1):
{panel}
[default@unknown] describe Keyspace3;
Keyspace: Keyspace3:
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
Durable Writes: true
Options: [dc1:1]
Column Families:
ColumnFamily: testcf
{panel}
But if I connect to a node in dc2, using LOCAL_QUORUM, I get NPE in the
Cassandra node's log:
{panel}
[default@unknown] consistencylevel as LOCAL_QUORUM;
Consistency level is set to 'LOCAL_QUORUM'.
[default@unknown] use Keyspace3;
Authenticated to keyspace: Keyspace3
[default@Keyspace3] get testcf[utf8('k1')][utf8('c1')];
Internal error processing get
org.apache.thrift.TApplicationException: Internal error processing get
at
org.apache.thrift.TApplicationException.read(TApplicationException.java:108)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_get(Cassandra.java:511)
at
org.apache.cassandra.thrift.Cassandra$Client.get(Cassandra.java:492)
at org.apache.cassandra.cli.CliClient.executeGet(CliClient.java:648)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:209)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:348)
{panel}
node2's log:
{panel}
ERROR [Thrift:3] 2012-09-17 18:15:16,868 Cassandra.java (line 2999) Internal
error processing get
java.lang.NullPointerException
at
org.apache.cassandra.locator.NetworkTopologyStrategy.getReplicationFactor(NetworkTopologyStrategy.java:142)
at
org.apache.cassandra.service.DatacenterReadCallback.determineBlockFor(DatacenterReadCallback.java:90)
at
org.apache.cassandra.service.ReadCallback.init(ReadCallback.java:67)
at
org.apache.cassandra.service.DatacenterReadCallback.init(DatacenterReadCallback.java:63)
at
org.apache.cassandra.service.StorageProxy.getReadCallback(StorageProxy.java:775)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:609)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:564)
at
org.apache.cassandra.thrift.CassandraServer.readColumnFamily(CassandraServer.java:128)
at
org.apache.cassandra.thrift.CassandraServer.internal_get(CassandraServer.java:383)
at
org.apache.cassandra.thrift.CassandraServer.get(CassandraServer.java:401)
at
org.apache.cassandra.thrift.Cassandra$Processor$get.process(Cassandra.java:2989)
at
org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
{panel}
I could workaround it by adding dc2:0 to the option:
{panel}
[default@Keyspace3] describe Keyspace3;
Keyspace: Keyspace3:
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
Durable Writes: true
Options: [dc2:0, dc1:1]
Column Families:
ColumnFamily: testcf
{panel}
Now you get UA:
{panel}
[default@Keyspace3] get testcf[utf8('k1')][utf8('c1')];
[jira] [Updated] (CASSANDRA-4576) Error in non-upgraded node's log when upgrading another node to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4576:
---
Attachment: CASSANDRA-4576.patch
Actually it's a problem with Gossiper :)
Error in non-upgraded node's log when upgrading another node to trunk
-
Key: CASSANDRA-4576
URL: https://issues.apache.org/jira/browse/CASSANDRA-4576
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Environment: ubuntu, ccm cluster with dtests
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.2.0
Attachments: CASSANDRA-4576.patch
I'm upgrading a 2-node cluster from cassandra-1.1 to trunk. On node1 I flush,
stop the node, upgrade it to trunk, and start it. The following error gets
written once a second in the log for node2:
{code}
ERROR [GossipStage:10] 2012-08-24 11:03:36,293 AbstractCassandraDaemon.java
(line 134) Exception in thread Thread[GossipStage:10,5,main]
java.lang.RuntimeException: java.net.UnknownHostException: addr is of illegal
length
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:89)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.UnknownHostException: addr is of illegal length
at java.net.InetAddress.getByAddress(InetAddress.java:935)
at java.net.InetAddress.getByAddress(InetAddress.java:1318)
at
org.apache.cassandra.net.CompactEndpointSerializationHelper.deserialize(CompactEndpointSerializationHelper.java:39)
at
org.apache.cassandra.gms.EndpointStatesSerializationHelper.deserialize(GossipDigestSynMessage.java:117)
at
org.apache.cassandra.gms.GossipDigestAckMessageSerializer.deserialize(GossipDigestAckMessage.java:83)
at
org.apache.cassandra.gms.GossipDigestAckMessageSerializer.deserialize(GossipDigestAckMessage.java:70)
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:60)
... 4 more
{code}
Here is the exact code I ran to produce the error:
{code}
from dtest import Tester, debug
FROM_VERSION = 'git:cassandra-1.1'
TO_VERSION = 'git:trunk'
class TestUpgradeOneNode(Tester):
def upgrade_test(self):
# Start a cluster
cluster = self.cluster
cluster.partitioner = 'org.apache.cassandra.dht.RandomPartitioner'
cluster.set_cassandra_dir(cassandra_version=FROM_VERSION)
cluster.populate(2).start()
(node1, node2) = cluster.nodelist()
node1.watch_log_for('Listening for thrift clients...')
node2.watch_log_for('Listening for thrift clients...')
# Bring one node down and upgrade it.
node1.flush()
node1.stop(wait_other_notice=True)
node1.set_cassandra_dir(cassandra_version=TO_VERSION)
node1.start(wait_other_notice=True)
import pdb; pdb.set_trace() # -- pause here and tail -f the
node2.logfilename()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Git Push Summary
Updated Tags: refs/tags/1.2.0-beta1-tentative [created] 60bf68caa refs/tags/done/3933-1.0 [created] 12bcc5642 refs/tags/done/3933-1.1 [created] a401034f5 refs/tags/pending/3636 [created] 511993912 refs/tags/pending/3709-2 [created] e343633cb refs/tags/pending/4012 [created] a820ef150 refs/tags/pending/4012-2 [created] dec05280f refs/tags/pending/4036 [created] 0c330c686 refs/tags/pending/4073 [created] c0153d81c refs/tags/pending/4074 [created] d9a2cfd47 refs/tags/pending/4108 [created] 042612e7b refs/tags/pending/4113-2 [created] 54d1be337 refs/tags/pending/4198 [created] 59d803e4c refs/tags/pending/4271 [created] 38da438af refs/tags/pending/4385 [created] 89dabb5dd refs/tags/pending/4385-2 [created] b065c2733 refs/tags/pending/4434 [created] 26aeddf81 refs/tags/pending/4434-2 [created] d49002b26 refs/tags/pending/4454 [created] f00896eb0 refs/tags/pending/4470 [created] 72889a9f3 refs/tags/pending/4491 [created] 9eba7ab3b refs/tags/pending/4500-2 [created] f4495d875 refs/tags/pending/4500-3 [created] 71edbceae refs/tags/pending/4546 [created] 8b1336f00 refs/tags/pending/4594-1.1 [created] 01a9de392 refs/tags/pending/4594-1.2-rebase [created] 0b8d9d395 refs/tags/pending/4627 [created] 9349b42c6
Git Push Summary
Updated Tags: refs/tags/done/3933-1.0 [deleted] 12bcc5642
Git Push Summary
Updated Tags: refs/tags/done/3933-1.1 [deleted] a401034f5
Git Push Summary
Updated Tags: refs/tags/pending/3636 [deleted] 511993912
Git Push Summary
Updated Tags: refs/tags/pending/3709-2 [deleted] e343633cb refs/tags/pending/4012 [deleted] a820ef150
Git Push Summary
Updated Tags: refs/tags/pending/4012-2 [deleted] dec05280f refs/tags/pending/4036 [deleted] 0c330c686 refs/tags/pending/4073 [deleted] c0153d81c refs/tags/pending/4074 [deleted] d9a2cfd47 refs/tags/pending/4108 [deleted] 042612e7b
Git Push Summary
Updated Tags: refs/tags/pending/4113-2 [deleted] 54d1be337 refs/tags/pending/4198 [deleted] 59d803e4c refs/tags/pending/4271 [deleted] 38da438af refs/tags/pending/4385 [deleted] 89dabb5dd refs/tags/pending/4385-2 [deleted] b065c2733
Git Push Summary
Updated Tags: refs/tags/pending/4434 [deleted] 26aeddf81 refs/tags/pending/4434-2 [deleted] d49002b26 refs/tags/pending/4454 [deleted] f00896eb0 refs/tags/pending/4470 [deleted] 72889a9f3 refs/tags/pending/4491 [deleted] 9eba7ab3b refs/tags/pending/4500-2 [deleted] f4495d875 refs/tags/pending/4500-3 [deleted] 71edbceae refs/tags/pending/4546 [deleted] 8b1336f00 refs/tags/pending/4594-1.1 [deleted] 01a9de392 refs/tags/pending/4594-1.2-rebase [deleted] 0b8d9d395 refs/tags/pending/4627 [deleted] 9349b42c6
[jira] [Commented] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457917#comment-13457917
]
Aleksey Yeschenko commented on CASSANDRA-4594:
--
trunk, cql3, python 2.7:
{quote}
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
CQL query must be bytes, not unicode
{quote}
and
{quote}
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Traceback (most recent call last):
File bin/cqlsh, line 914, in perform_statement
self.cursor.execute(statement, decoder=decoder)
File bin/../lib/cql-internal-only-1.2.0.zip/cql-1.2.0/cql/cursor.py, line
75, in execute
raise ValueError(CQL query must be bytes, not unicode)
ValueError: CQL query must be bytes, not unicode
{quote}
I've attached a patch that fixes the issue but probably isn't the best possible
solution.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
[jira] [Updated] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-4594:
-
Attachment: lazy-fix.txt
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Attachments: lazy-fix.txt
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4576) Error in non-upgraded node's log when upgrading another node to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457943#comment-13457943
]
Brandon Williams commented on CASSANDRA-4576:
-
Can you explain what happened here? I'm confused by the version 11 change,
given that trunk is version 12.
Error in non-upgraded node's log when upgrading another node to trunk
-
Key: CASSANDRA-4576
URL: https://issues.apache.org/jira/browse/CASSANDRA-4576
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Environment: ubuntu, ccm cluster with dtests
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.2.0
Attachments: CASSANDRA-4576.patch
I'm upgrading a 2-node cluster from cassandra-1.1 to trunk. On node1 I flush,
stop the node, upgrade it to trunk, and start it. The following error gets
written once a second in the log for node2:
{code}
ERROR [GossipStage:10] 2012-08-24 11:03:36,293 AbstractCassandraDaemon.java
(line 134) Exception in thread Thread[GossipStage:10,5,main]
java.lang.RuntimeException: java.net.UnknownHostException: addr is of illegal
length
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:89)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.UnknownHostException: addr is of illegal length
at java.net.InetAddress.getByAddress(InetAddress.java:935)
at java.net.InetAddress.getByAddress(InetAddress.java:1318)
at
org.apache.cassandra.net.CompactEndpointSerializationHelper.deserialize(CompactEndpointSerializationHelper.java:39)
at
org.apache.cassandra.gms.EndpointStatesSerializationHelper.deserialize(GossipDigestSynMessage.java:117)
at
org.apache.cassandra.gms.GossipDigestAckMessageSerializer.deserialize(GossipDigestAckMessage.java:83)
at
org.apache.cassandra.gms.GossipDigestAckMessageSerializer.deserialize(GossipDigestAckMessage.java:70)
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:60)
... 4 more
{code}
Here is the exact code I ran to produce the error:
{code}
from dtest import Tester, debug
FROM_VERSION = 'git:cassandra-1.1'
TO_VERSION = 'git:trunk'
class TestUpgradeOneNode(Tester):
def upgrade_test(self):
# Start a cluster
cluster = self.cluster
cluster.partitioner = 'org.apache.cassandra.dht.RandomPartitioner'
cluster.set_cassandra_dir(cassandra_version=FROM_VERSION)
cluster.populate(2).start()
(node1, node2) = cluster.nodelist()
node1.watch_log_for('Listening for thrift clients...')
node2.watch_log_for('Listening for thrift clients...')
# Bring one node down and upgrade it.
node1.flush()
node1.stop(wait_other_notice=True)
node1.set_cassandra_dir(cassandra_version=TO_VERSION)
node1.start(wait_other_notice=True)
import pdb; pdb.set_trace() # -- pause here and tail -f the
node2.logfilename()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457999#comment-13457999
]
paul cannon commented on CASSANDRA-4594:
Aleksey: you must be missing the patch for this ticket. It includes a change to
the cql_protect_name function to encode unicode names in utf8 when necessary.
Using {{str}} won't work when there are non-ascii characters and the default
encoding is not utf8.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Attachments: lazy-fix.txt
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458019#comment-13458019
]
Aleksey Yeschenko commented on CASSANDRA-4594:
--
Paul: if it's in the trunk then I'm not missing it. Just double-checked it,
still got exact same exceptions.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Attachments: lazy-fix.txt
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458022#comment-13458022
]
paul cannon commented on CASSANDRA-4594:
It's not yet in trunk. See above; Brandon couldn't get the commit to apply,
because it was missing two of the commits from 4491.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Attachments: lazy-fix.txt
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458023#comment-13458023
]
Aleksey Yeschenko commented on CASSANDRA-4594:
--
Ah. Then I misunderstood you. Sorry.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Attachments: lazy-fix.txt
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-4594:
-
Attachment: (was: lazy-fix.txt)
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458026#comment-13458026
]
Brandon Williams commented on CASSANDRA-4594:
-
Sylvain said he committed those and I think I see them there, maybe you just
need to pull.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458028#comment-13458028
]
Aleksey Yeschenko commented on CASSANDRA-4594:
--
I pulled, of course. So unless git is lying to me, I should have the latest
trunk.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458039#comment-13458039
]
paul cannon commented on CASSANDRA-4594:
Yes, the commits from 4491 are there. The patch for _this commit_ is not.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Missing commit from 4594 merge.
Updated Branches:
refs/heads/trunk 60bf68caa - 09d3e7f7f
Missing commit from 4594 merge.
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/09d3e7f7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/09d3e7f7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/09d3e7f7
Branch: refs/heads/trunk
Commit: 09d3e7f7f7f795fb14b4193b89db399f79c82990
Parents: 60bf68c
Author: Brandon Williams brandonwilli...@apache.org
Authored: Tue Sep 18 13:47:56 2012 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Tue Sep 18 13:47:56 2012 -0500
--
bin/cqlsh |2 ++
pylib/cqlshlib/cql3handling.py |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/09d3e7f7/bin/cqlsh
--
diff --git a/bin/cqlsh b/bin/cqlsh
index 21cce89..f15b02c 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -1081,6 +1081,8 @@ class Shell(cmd.Cmd):
self.prompt = prompt
def cql_protect_name(self, name):
+if isinstance(name, unicode):
+name = name.encode('utf8')
return cqlruleset.maybe_escape_name(name)
def cql_protect_value(self, value):
http://git-wip-us.apache.org/repos/asf/cassandra/blob/09d3e7f7/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 9c5f337..27cec89 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -884,6 +884,7 @@ class CqlTableDef:
value_cols = [self.column_class(self.value_alias,
self.default_validator)]
else:
value_cols = map(self.column_class.from_layout, self.coldefs)
+value_cols.sort(key=lambda c: c.name)
return partkey_cols + colalias_cols + value_cols
@@ -918,6 +919,7 @@ class CqlTableDef:
warn(UnexpectedTableStructure(Dynamic storage CF has a
value_alias (%r)
% (self.value_alias,)))
value_cols = map(self.column_class.from_layout, self.coldefs)
+value_cols.sort(key=lambda c: c.name)
return partkey_cols + colalias_cols + value_cols
[jira] [Commented] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458045#comment-13458045
]
Brandon Williams commented on CASSANDRA-4594:
-
Ok, I got it to merge cleanly and committed it to trunk.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4576) Error in non-upgraded node's log when upgrading another node to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458046#comment-13458046
]
Pavel Yaskevich commented on CASSANDRA-4576:
Sure, GossipDigestAckSerializer always expects boolean on deserialization, that
would only changed in 1.2 which doesn't write that boolean.
Error in non-upgraded node's log when upgrading another node to trunk
-
Key: CASSANDRA-4576
URL: https://issues.apache.org/jira/browse/CASSANDRA-4576
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Environment: ubuntu, ccm cluster with dtests
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.2.0
Attachments: CASSANDRA-4576.patch
I'm upgrading a 2-node cluster from cassandra-1.1 to trunk. On node1 I flush,
stop the node, upgrade it to trunk, and start it. The following error gets
written once a second in the log for node2:
{code}
ERROR [GossipStage:10] 2012-08-24 11:03:36,293 AbstractCassandraDaemon.java
(line 134) Exception in thread Thread[GossipStage:10,5,main]
java.lang.RuntimeException: java.net.UnknownHostException: addr is of illegal
length
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:89)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.UnknownHostException: addr is of illegal length
at java.net.InetAddress.getByAddress(InetAddress.java:935)
at java.net.InetAddress.getByAddress(InetAddress.java:1318)
at
org.apache.cassandra.net.CompactEndpointSerializationHelper.deserialize(CompactEndpointSerializationHelper.java:39)
at
org.apache.cassandra.gms.EndpointStatesSerializationHelper.deserialize(GossipDigestSynMessage.java:117)
at
org.apache.cassandra.gms.GossipDigestAckMessageSerializer.deserialize(GossipDigestAckMessage.java:83)
at
org.apache.cassandra.gms.GossipDigestAckMessageSerializer.deserialize(GossipDigestAckMessage.java:70)
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:60)
... 4 more
{code}
Here is the exact code I ran to produce the error:
{code}
from dtest import Tester, debug
FROM_VERSION = 'git:cassandra-1.1'
TO_VERSION = 'git:trunk'
class TestUpgradeOneNode(Tester):
def upgrade_test(self):
# Start a cluster
cluster = self.cluster
cluster.partitioner = 'org.apache.cassandra.dht.RandomPartitioner'
cluster.set_cassandra_dir(cassandra_version=FROM_VERSION)
cluster.populate(2).start()
(node1, node2) = cluster.nodelist()
node1.watch_log_for('Listening for thrift clients...')
node2.watch_log_for('Listening for thrift clients...')
# Bring one node down and upgrade it.
node1.flush()
node1.stop(wait_other_notice=True)
node1.set_cassandra_dir(cassandra_version=TO_VERSION)
node1.start(wait_other_notice=True)
import pdb; pdb.set_trace() # -- pause here and tail -f the
node2.logfilename()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458059#comment-13458059
]
Aleksey Yeschenko commented on CASSANDRA-4594:
--
The issue is now gone.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4594) COPY TO and COPY FROM don't default to consistent ordering of columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458059#comment-13458059
]
Aleksey Yeschenko edited comment on CASSANDRA-4594 at 9/19/12 5:59 AM:
---
The problem is now gone.
was (Author: iamaleksey):
The issue is now gone.
COPY TO and COPY FROM don't default to consistent ordering of columns
-
Key: CASSANDRA-4594
URL: https://issues.apache.org/jira/browse/CASSANDRA-4594
Project: Cassandra
Issue Type: Bug
Environment: Happens in CQLSH 2, may or may not happen in CQLSH 3
Reporter: Tyler Patterson
Assignee: paul cannon
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Here is the input:
{code}
CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
USE test;
CREATE TABLE airplanes (
name text PRIMARY KEY,
manufacturer ascii,
year int,
mach float
);
INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
COPY airplanes TO 'temp.cfg' WITH HEADER=true;
TRUNCATE airplanes;
COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
SELECT * FROM airplanes;
{code}
Here is what happens when executed. Note how it tried to import the float
into the int column:
{code}
cqlsh:test DROP KEYSPACE test;
cqlsh:test CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy' AND
strategy_options:replication_factor = 1;
cqlsh:test USE test;
cqlsh:test
cqlsh:test CREATE TABLE airplanes (
... name text PRIMARY KEY,
... manufacturer ascii,
... year int,
... mach float
... );
cqlsh:test
cqlsh:test INSERT INTO airplanes (name, manufacturer, year, mach) VALUES
('P38-Lightning', 'Lockheed', 1937, '.7');
cqlsh:test
cqlsh:test COPY airplanes TO 'temp.cfg' WITH HEADER=true;
1 rows exported in 0.003 seconds.
cqlsh:test TRUNCATE airplanes;
cqlsh:test
cqlsh:test COPY airplanes FROM 'temp.cfg' WITH HEADER=true;
Bad Request: unable to make int from '0.7'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.002 seconds.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4680) Show time drift between nodes when using nodetool ring
Patrick McFadin created CASSANDRA-4680: -- Summary: Show time drift between nodes when using nodetool ring Key: CASSANDRA-4680 URL: https://issues.apache.org/jira/browse/CASSANDRA-4680 Project: Cassandra Issue Type: Improvement Reporter: Patrick McFadin Priority: Minor From the docs: Server clock synchronization is more important in 1.2; replicas will use a coordinator-provided timestamp to determine when a request has timed out and is thus not worth proceeding with. Using a service like NTP is strongly recommended. Since this is now more important than ever, my proposed enhancement would be to the nodetool command. When displaying the ring information, add the time drift as relative to the current host. This would be a valuable tool to aid in diagnostics. -- 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-4680) Show time drift between nodes when using nodetool ring
[ https://issues.apache.org/jira/browse/CASSANDRA-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4680: Component/s: Core Fix Version/s: 1.2.0 beta 2 Show time drift between nodes when using nodetool ring -- Key: CASSANDRA-4680 URL: https://issues.apache.org/jira/browse/CASSANDRA-4680 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Patrick McFadin Priority: Minor Fix For: 1.2.0 beta 2 From the docs: Server clock synchronization is more important in 1.2; replicas will use a coordinator-provided timestamp to determine when a request has timed out and is thus not worth proceeding with. Using a service like NTP is strongly recommended. Since this is now more important than ever, my proposed enhancement would be to the nodetool command. When displaying the ring information, add the time drift as relative to the current host. This would be a valuable tool to aid in diagnostics. -- 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-4680) Show time drift between nodes when using nodetool ring
[ https://issues.apache.org/jira/browse/CASSANDRA-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458078#comment-13458078 ] Brandon Williams commented on CASSANDRA-4680: - 'ring' is somewhat deprecated with vnodes, it probably makes more sense in 'status' now. Show time drift between nodes when using nodetool ring -- Key: CASSANDRA-4680 URL: https://issues.apache.org/jira/browse/CASSANDRA-4680 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Patrick McFadin Priority: Minor Fix For: 1.2.0 beta 2 From the docs: Server clock synchronization is more important in 1.2; replicas will use a coordinator-provided timestamp to determine when a request has timed out and is thus not worth proceeding with. Using a service like NTP is strongly recommended. Since this is now more important than ever, my proposed enhancement would be to the nodetool command. When displaying the ring information, add the time drift as relative to the current host. This would be a valuable tool to aid in diagnostics. -- 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-3460) Increase precision of elapsed time in casandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kolar updated CASSANDRA-3460: --- Attachment: cassandra-nanoseconds.txt Display eta in 2 fraction digits, if total time is less then 10 ms. Increase precision of elapsed time in casandra-cli -- Key: CASSANDRA-3460 URL: https://issues.apache.org/jira/browse/CASSANDRA-3460 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.0.11, 1.1.5 Reporter: Radim Kolar Priority: Minor Labels: cli Attachments: cassandra-nanoseconds.txt Cassandra often return response in less then 1 ms from another datacenter [default@test] get sipdb[23]; Returned 0 results. Elapsed time: 219 msec(s). from own dataceter [default@test] get sipdb[13]; Returned 0 results. Elapsed time: 0 msec(s). Precession of this timer needs to be increased a bit, while looking at network latency adding 1 number should be enough like : 0.2 ms should be sufficient. It would be good to display sub milliseconds only if time elapsed is 1 ms. -- 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-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kibirev updated CASSANDRA-4681:
Description:
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the critical
path, even doing excessive atomic instructions or allocated unneeded ByteBuffer
instances has a measurable effect on performance
was:
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocated unneeded
ByteBuffer instances has a measurable effect on performance
--
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-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kibirev updated CASSANDRA-4681:
Attachment: SlabAllocator.java
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocated unneeded
ByteBuffer instances has a measurable effect on performance
--
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-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kibirev updated CASSANDRA-4681:
Description:
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the critical
path, even doing excessive atomic instructions or allocating unneeded extra
ByteBuffer instances has a measurable effect on performance
was:
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the critical
path, even doing excessive atomic instructions or allocated unneeded ByteBuffer
instances has a measurable effect on performance
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
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-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458173#comment-13458173
]
Brandon Williams commented on CASSANDRA-4681:
-
bq. I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached.
How many CFs were you using when you saw this? Any other details would be
appreciated.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
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-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458180#comment-13458180
]
Oleg Kibirev commented on CASSANDRA-4681:
-
The benchmark exercised two column families. I think the key is that I am using
a large number of very small column names/values and insert concurrently from
dozens of threads (due to characteristics of the real world use case). The
system used has 24 CPU cores and an SSD raid. So basically there is a very high
rate of allocations and large number of concurrent threads hitting the same
SlabAllocator.
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
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-4682) simple scripting bug in cassandra-env.sh
Yang Yang created CASSANDRA-4682: Summary: simple scripting bug in cassandra-env.sh Key: CASSANDRA-4682 URL: https://issues.apache.org/jira/browse/CASSANDRA-4682 Project: Cassandra Issue Type: Bug Reporter: Yang Yang Priority: Minor the case clause contains break, which is syntactically wrong. generally it does not show up in command line since the stderr and stdout is redirected -- 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-4576) Error in non-upgraded node's log when upgrading another node to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458242#comment-13458242
]
Brandon Williams commented on CASSANDRA-4576:
-
I see, thanks. +1
Error in non-upgraded node's log when upgrading another node to trunk
-
Key: CASSANDRA-4576
URL: https://issues.apache.org/jira/browse/CASSANDRA-4576
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Environment: ubuntu, ccm cluster with dtests
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.2.0
Attachments: CASSANDRA-4576.patch
I'm upgrading a 2-node cluster from cassandra-1.1 to trunk. On node1 I flush,
stop the node, upgrade it to trunk, and start it. The following error gets
written once a second in the log for node2:
{code}
ERROR [GossipStage:10] 2012-08-24 11:03:36,293 AbstractCassandraDaemon.java
(line 134) Exception in thread Thread[GossipStage:10,5,main]
java.lang.RuntimeException: java.net.UnknownHostException: addr is of illegal
length
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:89)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.UnknownHostException: addr is of illegal length
at java.net.InetAddress.getByAddress(InetAddress.java:935)
at java.net.InetAddress.getByAddress(InetAddress.java:1318)
at
org.apache.cassandra.net.CompactEndpointSerializationHelper.deserialize(CompactEndpointSerializationHelper.java:39)
at
org.apache.cassandra.gms.EndpointStatesSerializationHelper.deserialize(GossipDigestSynMessage.java:117)
at
org.apache.cassandra.gms.GossipDigestAckMessageSerializer.deserialize(GossipDigestAckMessage.java:83)
at
org.apache.cassandra.gms.GossipDigestAckMessageSerializer.deserialize(GossipDigestAckMessage.java:70)
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:60)
... 4 more
{code}
Here is the exact code I ran to produce the error:
{code}
from dtest import Tester, debug
FROM_VERSION = 'git:cassandra-1.1'
TO_VERSION = 'git:trunk'
class TestUpgradeOneNode(Tester):
def upgrade_test(self):
# Start a cluster
cluster = self.cluster
cluster.partitioner = 'org.apache.cassandra.dht.RandomPartitioner'
cluster.set_cassandra_dir(cassandra_version=FROM_VERSION)
cluster.populate(2).start()
(node1, node2) = cluster.nodelist()
node1.watch_log_for('Listening for thrift clients...')
node2.watch_log_for('Listening for thrift clients...')
# Bring one node down and upgrade it.
node1.flush()
node1.stop(wait_other_notice=True)
node1.set_cassandra_dir(cassandra_version=TO_VERSION)
node1.start(wait_other_notice=True)
import pdb; pdb.set_trace() # -- pause here and tail -f the
node2.logfilename()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4675) NPE in NTS when using LQ against a node (DC) that doesn't have replica
[
https://issues.apache.org/jira/browse/CASSANDRA-4675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458244#comment-13458244
]
Jackson Chung commented on CASSANDRA-4675:
--
1.0.10
NPE in NTS when using LQ against a node (DC) that doesn't have replica
--
Key: CASSANDRA-4675
URL: https://issues.apache.org/jira/browse/CASSANDRA-4675
Project: Cassandra
Issue Type: Bug
Reporter: Jackson Chung
Priority: Minor
in a NetworkTopologyStrategy where there are 2 DC:
{panel}
Address DC RackStatus State LoadOwns
Token
85070591730234615865843651857942052864
127.0.0.1 dc1 r1 Up Normal 115.78 KB 50.00%
0
127.0.0.2 dc2 r1 Up Normal 129.3 KB50.00%
85070591730234615865843651857942052864
{panel}
I have a KS that has replica is 1 of the dc (dc1):
{panel}
[default@unknown] describe Keyspace3;
Keyspace: Keyspace3:
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
Durable Writes: true
Options: [dc1:1]
Column Families:
ColumnFamily: testcf
{panel}
But if I connect to a node in dc2, using LOCAL_QUORUM, I get NPE in the
Cassandra node's log:
{panel}
[default@unknown] consistencylevel as LOCAL_QUORUM;
Consistency level is set to 'LOCAL_QUORUM'.
[default@unknown] use Keyspace3;
Authenticated to keyspace: Keyspace3
[default@Keyspace3] get testcf[utf8('k1')][utf8('c1')];
Internal error processing get
org.apache.thrift.TApplicationException: Internal error processing get
at
org.apache.thrift.TApplicationException.read(TApplicationException.java:108)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_get(Cassandra.java:511)
at
org.apache.cassandra.thrift.Cassandra$Client.get(Cassandra.java:492)
at org.apache.cassandra.cli.CliClient.executeGet(CliClient.java:648)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:209)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:348)
{panel}
node2's log:
{panel}
ERROR [Thrift:3] 2012-09-17 18:15:16,868 Cassandra.java (line 2999) Internal
error processing get
java.lang.NullPointerException
at
org.apache.cassandra.locator.NetworkTopologyStrategy.getReplicationFactor(NetworkTopologyStrategy.java:142)
at
org.apache.cassandra.service.DatacenterReadCallback.determineBlockFor(DatacenterReadCallback.java:90)
at
org.apache.cassandra.service.ReadCallback.init(ReadCallback.java:67)
at
org.apache.cassandra.service.DatacenterReadCallback.init(DatacenterReadCallback.java:63)
at
org.apache.cassandra.service.StorageProxy.getReadCallback(StorageProxy.java:775)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:609)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:564)
at
org.apache.cassandra.thrift.CassandraServer.readColumnFamily(CassandraServer.java:128)
at
org.apache.cassandra.thrift.CassandraServer.internal_get(CassandraServer.java:383)
at
org.apache.cassandra.thrift.CassandraServer.get(CassandraServer.java:401)
at
org.apache.cassandra.thrift.Cassandra$Processor$get.process(Cassandra.java:2989)
at
org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
{panel}
I could workaround it by adding dc2:0 to the option:
{panel}
[default@Keyspace3] describe Keyspace3;
Keyspace: Keyspace3:
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
Durable Writes: true
Options: [dc2:0, dc1:1]
Column Families:
ColumnFamily: testcf
{panel}
Now you get UA:
{panel}
[default@Keyspace3] get testcf[utf8('k1')][utf8('c1')];
null
UnavailableException()
at
[jira] [Commented] (CASSANDRA-4208) ColumnFamilyOutputFormat should support writing to multiple column families
[ https://issues.apache.org/jira/browse/CASSANDRA-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458247#comment-13458247 ] Michael Kjellman commented on CASSANDRA-4208: - yes- we have it working as well. but so far we have been unsuccessful in getting it to work with bulkoutputformat...i'm going to work on debugging that today ColumnFamilyOutputFormat should support writing to multiple column families --- Key: CASSANDRA-4208 URL: https://issues.apache.org/jira/browse/CASSANDRA-4208 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 1.1.0 Reporter: Robbie Strickland Attachments: cassandra-1.1-4208.txt, cassandra-1.1-4208-v2.txt, cassandra-1.1-4208-v3.txt, trunk-4208.txt, trunk-4208-v2.txt It is not currently possible to output records to more than one column family in a single reducer. Considering that writing values to Cassandra often involves multiple column families (i.e. updating your index when you insert a new value), this seems overly restrictive. I am submitting a patch that moves the specification of column family from the job configuration to the write() call in ColumnFamilyRecordWriter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: fix cross-version gossip messaging patch by Pavel Yaskevich; reviewed by Brandon Williams for CASSANDRA-4576
Updated Branches:
refs/heads/trunk 09d3e7f7f - 1693ee22f
fix cross-version gossip messaging
patch by Pavel Yaskevich; reviewed by Brandon Williams for CASSANDRA-4576
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1693ee22
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1693ee22
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1693ee22
Branch: refs/heads/trunk
Commit: 1693ee22fe70049ee3dd45eb211fb4f902dc8d9f
Parents: 09d3e7f
Author: Pavel Yaskevich xe...@apache.org
Authored: Tue Sep 18 18:32:53 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Wed Sep 19 01:24:52 2012 +0300
--
CHANGES.txt|1 +
.../org/apache/cassandra/gms/GossipDigestAck.java |4 ++--
.../org/apache/cassandra/gms/VersionedValue.java | 11 ---
3 files changed, 11 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1693ee22/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1dd875e..3ff91ad 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -64,6 +64,7 @@
* (cql3) Add ALTER KEYSPACE statement (CASSANDRA-4611)
* (cql3) Allow defining default consistency levels (CASSANDRA-4448)
* (cql3) Fix queries using LIMIT missing results (CASSANDRA-4579)
+ * fix cross-version gossip messaging (CASSANDRA-4576)
1.1.6
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1693ee22/src/java/org/apache/cassandra/gms/GossipDigestAck.java
--
diff --git a/src/java/org/apache/cassandra/gms/GossipDigestAck.java
b/src/java/org/apache/cassandra/gms/GossipDigestAck.java
index b7ea067..68dcff4 100644
--- a/src/java/org/apache/cassandra/gms/GossipDigestAck.java
+++ b/src/java/org/apache/cassandra/gms/GossipDigestAck.java
@@ -63,7 +63,7 @@ class GossipDigestAckSerializer implements
IVersionedSerializerGossipDigestAck
public void serialize(GossipDigestAck gDigestAckMessage, DataOutput dos,
int version) throws IOException
{
GossipDigestSerializationHelper.serialize(gDigestAckMessage.gDigestList, dos,
version);
-if (version = MessagingService.VERSION_10)
+if (version = MessagingService.VERSION_11)
dos.writeBoolean(true); // 0.6 compatibility
dos.writeInt(gDigestAckMessage.epStateMap.size());
for (Map.EntryInetAddress, EndpointState entry :
gDigestAckMessage.epStateMap.entrySet())
@@ -77,7 +77,7 @@ class GossipDigestAckSerializer implements
IVersionedSerializerGossipDigestAck
public GossipDigestAck deserialize(DataInput dis, int version) throws
IOException
{
ListGossipDigest gDigestList =
GossipDigestSerializationHelper.deserialize(dis, version);
-if (version = MessagingService.VERSION_10)
+if (version = MessagingService.VERSION_11)
dis.readBoolean(); // 0.6 compatibility
int size = dis.readInt();
MapInetAddress, EndpointState epStateMap = new HashMapInetAddress,
EndpointState(size);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1693ee22/src/java/org/apache/cassandra/gms/VersionedValue.java
--
diff --git a/src/java/org/apache/cassandra/gms/VersionedValue.java
b/src/java/org/apache/cassandra/gms/VersionedValue.java
index 8436adc..e2d68a7 100644
--- a/src/java/org/apache/cassandra/gms/VersionedValue.java
+++ b/src/java/org/apache/cassandra/gms/VersionedValue.java
@@ -260,14 +260,19 @@ public class VersionedValue implements
ComparableVersionedValue
if ((type.equals(STATUS_NORMAL)) ||
type.equals(STATUS_BOOTSTRAPPING))
{
-assert pieces.length = 3;
-outValue = versionString(pieces[0], pieces[2]);
+assert pieces.length = 2;
+outValue = versionString(pieces[0], pieces[1]);
}
if (type.equals(STATUS_LEFT))
{
assert pieces.length = 3;
-outValue = versionString(pieces[0], pieces[2], pieces[1]);
+
+// three component 'left' was adopted starting from
Cassandra 1.0
+// previous versions have 'type:token' format
+outValue = (version MessagingService.VERSION_10)
+? versionString(pieces[0], pieces[2])
+: versionString(pieces[0], pieces[2],
pieces[1]);
}
if ((type.equals(REMOVAL_COORDINATOR)) ||
(type.equals(REMOVING_TOKEN)) || (type.equals(REMOVED_TOKEN)))
[jira] [Comment Edited] (CASSANDRA-4208) ColumnFamilyOutputFormat should support writing to multiple column families
[ https://issues.apache.org/jira/browse/CASSANDRA-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458247#comment-13458247 ] Michael Kjellman edited comment on CASSANDRA-4208 at 9/19/12 9:36 AM: -- yes- we have it working as well (and thanks for the patch, it's a really important feature to us). but so far we have been unsuccessful in getting it to work with bulkoutputformat...i'm going to work on debugging that today was (Author: mkjellman): yes- we have it working as well. but so far we have been unsuccessful in getting it to work with bulkoutputformat...i'm going to work on debugging that today ColumnFamilyOutputFormat should support writing to multiple column families --- Key: CASSANDRA-4208 URL: https://issues.apache.org/jira/browse/CASSANDRA-4208 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 1.1.0 Reporter: Robbie Strickland Attachments: cassandra-1.1-4208.txt, cassandra-1.1-4208-v2.txt, cassandra-1.1-4208-v3.txt, trunk-4208.txt, trunk-4208-v2.txt It is not currently possible to output records to more than one column family in a single reducer. Considering that writing values to Cassandra often involves multiple column families (i.e. updating your index when you insert a new value), this seems overly restrictive. I am submitting a patch that moves the specification of column family from the job configuration to the write() call in ColumnFamilyRecordWriter. -- 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-4682) simple scripting bug in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458268#comment-13458268 ] Brandon Williams commented on CASSANDRA-4682: - A case insensitive search for 'break' returns no results. simple scripting bug in cassandra-env.sh Key: CASSANDRA-4682 URL: https://issues.apache.org/jira/browse/CASSANDRA-4682 Project: Cassandra Issue Type: Bug Reporter: Yang Yang Priority: Minor the case clause contains break, which is syntactically wrong. generally it does not show up in command line since the stderr and stdout is redirected -- 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-4683) running nodetool cleanup throws an exception
Bartłomiej Romański created CASSANDRA-4683: -- Summary: running nodetool cleanup throws an exception Key: CASSANDRA-4683 URL: https://issues.apache.org/jira/browse/CASSANDRA-4683 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.5 Reporter: Bartłomiej Romański We've just upgraded to 1.1.5 from 1.1.2. After that running nodetool cleanup we've got the following error: Exception in thread main java.lang.AssertionError at org.apache.cassandra.db.SystemTable.getCurrentLocalNodeId(SystemTable.java:462) at org.apache.cassandra.utils.NodeId$LocalNodeIdHistory.init(NodeId.java:195) at org.apache.cassandra.utils.NodeId$LocalIds.clinit(NodeId.java:43) at org.apache.cassandra.utils.NodeId.localIds(NodeId.java:50) at org.apache.cassandra.utils.NodeId.getLocalId(NodeId.java:55) at org.apache.cassandra.utils.NodeId$OneShotRenewer.init(NodeId.java:175) at org.apache.cassandra.service.StorageService.forceTableCleanup(StorageService.java:1769) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1447) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:89) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1292) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1380) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:812) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) at sun.rmi.transport.Transport$1.run(Transport.java:177) at sun.rmi.transport.Transport$1.run(Transport.java:174) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:173) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Any ideas? -- 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-4681) SlabAllocator spends a lot of time in Thread.yield
[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458362#comment-13458362
]
Jonathan Ellis commented on CASSANDRA-4681:
---
The fix here defeats the purpose of the SlabAllocator, and you will pay a
penalty in STW GC for non-uniform value sizes. So I'm unenthusiastic about
adopting this for general use.
Instead you might try preallocating a queue of buffers or regions to reduce
init time.
(Note that we never allocate unneeded bytebuffers, that is the point of the
UNINITIALIZED dance instead of just each thread creating the BB and CASing to
see who wins.)
SlabAllocator spends a lot of time in Thread.yield
--
Key: CASSANDRA-4681
URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: OEL Linux
Reporter: Oleg Kibirev
Attachments: SlabAllocator.java
When profiling high volume inserts into Cassandra running on a host with fast
SSD and CPU, Thread.yield() invoked by SlabAllocator appeared as the top item
in CPU samples. The fix is to return a regular byte buffer if current slab is
being initialized by another thread. So instead of:
if (oldOffset == UNINITIALIZED)
{
// The region doesn't have its data allocated yet.
// Since we found this in currentRegion, we know that
whoever
// CAS-ed it there is allocating it right now. So
spin-loop
// shouldn't spin long!
Thread.yield();
continue;
}
do:
if (oldOffset == UNINITIALIZED)
return ByteBuffer.allocate(size);
I achieved 4x speed up in my (admittedly specialized) benchmark by using an
optimized version of SlabAllocator attached. Since this code is in the
critical path, even doing excessive atomic instructions or allocating
unneeded extra ByteBuffer instances has a measurable effect on performance
--
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-4683) running nodetool cleanup throws an exception
[ https://issues.apache.org/jira/browse/CASSANDRA-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458364#comment-13458364 ] Jonathan Ellis commented on CASSANDRA-4683: --- Are you sure this node is on 1.1.5? That looks like the bug fixed in CASSANDRA-4626 to me. running nodetool cleanup throws an exception Key: CASSANDRA-4683 URL: https://issues.apache.org/jira/browse/CASSANDRA-4683 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.5 Reporter: Bartłomiej Romański We've just upgraded to 1.1.5 from 1.1.2. After that running nodetool cleanup we've got the following error: Exception in thread main java.lang.AssertionError at org.apache.cassandra.db.SystemTable.getCurrentLocalNodeId(SystemTable.java:462) at org.apache.cassandra.utils.NodeId$LocalNodeIdHistory.init(NodeId.java:195) at org.apache.cassandra.utils.NodeId$LocalIds.clinit(NodeId.java:43) at org.apache.cassandra.utils.NodeId.localIds(NodeId.java:50) at org.apache.cassandra.utils.NodeId.getLocalId(NodeId.java:55) at org.apache.cassandra.utils.NodeId$OneShotRenewer.init(NodeId.java:175) at org.apache.cassandra.service.StorageService.forceTableCleanup(StorageService.java:1769) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1447) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:89) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1292) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1380) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:812) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) at sun.rmi.transport.Transport$1.run(Transport.java:177) at sun.rmi.transport.Transport$1.run(Transport.java:174) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:173) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Any ideas? -- 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-4677) Change description of nodetool ring command
[
https://issues.apache.org/jira/browse/CASSANDRA-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4677:
Attachment: cassandra-1.1-4677.txt
Change description of nodetool ring command
---
Key: CASSANDRA-4677
URL: https://issues.apache.org/jira/browse/CASSANDRA-4677
Project: Cassandra
Issue Type: Task
Components: Tools
Affects Versions: 1.1.5
Reporter: Alexey Zotov
Priority: Trivial
Labels: ring
Attachments: cassandra-1.1-4677.txt, nodetool_ring_description.patch
Additional option of 'nodetool ring' command is not documented.
Old variant:
{code}
ring - Print information about the token ring
{code}
New variant
{code}
ring [keyspace]- Print information about the token ring for a given
keyspace (for all keyspaces if it is not specified)
{code}
Patch has been attached.
Some history (I think it will be useful for someone who will have the same
problem):
I have 4-nodes cluster. One of nodes is located in other DC (DC2). I've met
the problem that 'nodetool ring' shows that node in DC2 'Owns 0.00%'. I've
found following questions:
http://www.datastax.com/support-forums/topic/owns-in-nodetool
http://mail-archives.apache.org/mod_mbox/cassandra-user/201202.mbox/%3c323dbc99-8519-4e86-b69b-6520d53fa...@humbaba.net%3E
and task with fix:
https://issues.apache.org/jira/browse/CASSANDRA-3412
So you should use 'nodetool ring keyspace' for getting right information.
--
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-4677) Change description of nodetool ring command
[
https://issues.apache.org/jira/browse/CASSANDRA-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458431#comment-13458431
]
Alexey Zotov commented on CASSANDRA-4677:
-
I've attached cassandra-1.1-4677.txt. It was created such as described at
http://wiki.apache.org/cassandra/HowToContribute
Change description of nodetool ring command
---
Key: CASSANDRA-4677
URL: https://issues.apache.org/jira/browse/CASSANDRA-4677
Project: Cassandra
Issue Type: Task
Components: Tools
Affects Versions: 1.1.5
Reporter: Alexey Zotov
Priority: Trivial
Labels: ring
Attachments: cassandra-1.1-4677.txt, nodetool_ring_description.patch
Additional option of 'nodetool ring' command is not documented.
Old variant:
{code}
ring - Print information about the token ring
{code}
New variant
{code}
ring [keyspace]- Print information about the token ring for a given
keyspace (for all keyspaces if it is not specified)
{code}
Patch has been attached.
Some history (I think it will be useful for someone who will have the same
problem):
I have 4-nodes cluster. One of nodes is located in other DC (DC2). I've met
the problem that 'nodetool ring' shows that node in DC2 'Owns 0.00%'. I've
found following questions:
http://www.datastax.com/support-forums/topic/owns-in-nodetool
http://mail-archives.apache.org/mod_mbox/cassandra-user/201202.mbox/%3c323dbc99-8519-4e86-b69b-6520d53fa...@humbaba.net%3E
and task with fix:
https://issues.apache.org/jira/browse/CASSANDRA-3412
So you should use 'nodetool ring keyspace' for getting right information.
--
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-4678) Add possibility to stop repair session from nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458433#comment-13458433 ] Alexey Zotov commented on CASSANDRA-4678: - fixed. Add possibility to stop repair session from nodetool Key: CASSANDRA-4678 URL: https://issues.apache.org/jira/browse/CASSANDRA-4678 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.1.5 Reporter: Alexey Zotov Priority: Minor Labels: nodetool, repair Attachments: cassandra-1.1-4678.txt, nodetool_stoprepair_command_v1.patch I've added possibility to stop repair session from nodetool. 'stoprepair' command has been introduced. -- 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-4678) Add possibility to stop repair session from nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zotov updated CASSANDRA-4678: Attachment: cassandra-1.1-4678.txt Add possibility to stop repair session from nodetool Key: CASSANDRA-4678 URL: https://issues.apache.org/jira/browse/CASSANDRA-4678 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.1.5 Reporter: Alexey Zotov Priority: Minor Labels: nodetool, repair Attachments: cassandra-1.1-4678.txt, nodetool_stoprepair_command_v1.patch I've added possibility to stop repair session from nodetool. 'stoprepair' command has been introduced. -- 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
