[jira] [Created] (CASSANDRA-4628) CQL/JDBC: date vs. timestamp issues
Michael Krumpholz created CASSANDRA-4628: Summary: CQL/JDBC: date vs. timestamp issues Key: CASSANDRA-4628 URL: https://issues.apache.org/jira/browse/CASSANDRA-4628 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.4 Reporter: Michael Krumpholz Priority: Critical Cassandra's datatypes only have one Date/Time type named timestamp containing both date and time. Calling the validator org.apache.cassandra.db.marshal.DateType might be OK in general but can be confusing in the jdbc context where there is a distinction between date, time and timestamp. In terms of jdbc there should be more datatypes for dates and times or the jdbc driver should take one of the following options: - stick to timestamp - check if the date has a time part and distinguish by the data between date and timestamp automatically - use distinct datatypes according to the jdbc spec, the types would need to be in cassandra then too Now back to my actual problem: org.apache.cassandra.cql.jdbc.JdbcDate returns Types.DATE in getType(). Even if having inserted a complete date with time (making it a timestamp) the ResultSetMetaData.getColumnType() implementation still returns Types.DATE (source of this is in JdbcDate). If some other java code (where i don't have access to) uses the metadata to get the type and then getDate() to get the value the time is cut off the value and only the date is returned. But the ResultSet.getObject() implementation returns a complete java.util.Date including the time. -- 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-4629) CQL/JDBC: implement complete jdbc metadata
Michael Krumpholz created CASSANDRA-4629:
Summary: CQL/JDBC: implement complete jdbc metadata
Key: CASSANDRA-4629
URL: https://issues.apache.org/jira/browse/CASSANDRA-4629
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.1.4
Reporter: Michael Krumpholz
Please provide a more complete implementation of the jdbc spec for the
metadata. The CassandraDatabaseMetaData implementation of DatabaseMetaData
returns only empty result sets for the important methods. Also the
getIdentifierQuoteString() returns single quote (') instead of double quotes
(). should be the correct quote string for SQL identifiers at least in my
understanding!?
I have written some code at least for some parts of the jdbc api that we need
using cql queries on the system.schema_* tables. I put the code for our project
into separated classes to avoid direct changes to libs which will
change/improve in new versions. I don't know if it's complete and/or correct in
all cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Fix potential deadlock during counter writes
Updated Branches:
refs/heads/cassandra-1.1 4177b58f1 - 7371e10be
Fix potential deadlock during counter writes
patch by slebresne; reviewed by jbellis for CASSANDRA-4578
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7371e10b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7371e10b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7371e10b
Branch: refs/heads/cassandra-1.1
Commit: 7371e10be40d9a01167d36eb2db69526b6b0ce50
Parents: 4177b58
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 6 14:57:08 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Fri Sep 7 10:41:58 2012 +0200
--
CHANGES.txt|1 +
.../org/apache/cassandra/db/CounterColumn.java |2 +-
.../cassandra/db/CounterMutationVerbHandler.java | 32 +++---
.../locator/AbstractReplicationStrategy.java |8 ++--
.../service/AbstractWriteResponseHandler.java | 17 +++-
.../DatacenterSyncWriteResponseHandler.java| 10 ++--
.../service/DatacenterWriteResponseHandler.java| 10 ++--
.../org/apache/cassandra/service/StorageProxy.java | 17 +---
.../cassandra/service/WriteResponseHandler.java| 12 +++---
9 files changed, 72 insertions(+), 37 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7371e10b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4a5bfe9..f192be2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,7 @@
1.1.6
* (cql3) fix potential NPE with both equal and unequal restriction
(CASSANDRA-4532)
* (cql3) improves ORDER BY validation (CASSANDRA-4624)
+ * Fix potential deadlock during counter writes (CASSANDRA-4578)
1.1.5
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7371e10b/src/java/org/apache/cassandra/db/CounterColumn.java
--
diff --git a/src/java/org/apache/cassandra/db/CounterColumn.java
b/src/java/org/apache/cassandra/db/CounterColumn.java
index 2ea0779..b6e3909 100644
--- a/src/java/org/apache/cassandra/db/CounterColumn.java
+++ b/src/java/org/apache/cassandra/db/CounterColumn.java
@@ -370,7 +370,7 @@ public class CounterColumn extends Column
responseHandler.response(null);
StorageProxy.sendToHintedEndpoints((RowMutation) mutation,
targets, responseHandler, localDataCenter, consistency_level);
}
-});
+}, null);
// we don't wait for answers
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7371e10b/src/java/org/apache/cassandra/db/CounterMutationVerbHandler.java
--
diff --git a/src/java/org/apache/cassandra/db/CounterMutationVerbHandler.java
b/src/java/org/apache/cassandra/db/CounterMutationVerbHandler.java
index 01d7b50..3ecbe8b 100644
--- a/src/java/org/apache/cassandra/db/CounterMutationVerbHandler.java
+++ b/src/java/org/apache/cassandra/db/CounterMutationVerbHandler.java
@@ -35,7 +35,7 @@ public class CounterMutationVerbHandler implements
IVerbHandler
{
private static Logger logger =
LoggerFactory.getLogger(CounterMutationVerbHandler.class);
-public void doVerb(Message message, String id)
+public void doVerb(final Message message, final String id)
{
byte[] bytes = message.getMessageBody();
FastByteArrayInputStream buffer = new FastByteArrayInputStream(bytes);
@@ -43,15 +43,33 @@ public class CounterMutationVerbHandler implements
IVerbHandler
try
{
DataInputStream is = new DataInputStream(buffer);
-CounterMutation cm = CounterMutation.serializer().deserialize(is,
message.getVersion());
+final CounterMutation cm =
CounterMutation.serializer().deserialize(is, message.getVersion());
if (logger.isDebugEnabled())
logger.debug(Applying forwarded + cm);
String localDataCenter =
DatabaseDescriptor.getEndpointSnitch().getDatacenter(FBUtilities.getBroadcastAddress());
-StorageProxy.applyCounterMutationOnLeader(cm,
localDataCenter).get();
-WriteResponse response = new WriteResponse(cm.getTable(),
cm.key(), true);
-Message responseMessage =
WriteResponse.makeWriteResponseMessage(message, response);
-MessagingService.instance().sendReply(responseMessage, id,
message.getFrom());
+// We should not wait for the result of the write in this thread,
+// otherwise we could have a distributed deadlock between replicas
+// running this VerbHandler (see #4578).
+// Instead, we use a callback
[Cassandra Wiki] Update of Administration Tools by TomekKuprowski
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The Administration Tools page has been changed by TomekKuprowski: http://wiki.apache.org/cassandra/Administration%20Tools?action=diffrev1=6rev2=7 === Cassandra Explorer === * [[http://blog.shelan.org/2012/06/cassandra-gui-20-making-things-little.html]] Cassandra Explorer is a Data explorer for Cassandra. This will assist developers administrators to view data in a Cassandra cluster. + === Helenos === + + * [[https://github.com/tomekkup/helenos]] Helenos is a web based GUI tool that helps you to explore data and manage schema. +
[1/2] git commit: Merge branch 'cassandra-1.1' into trunk
Updated Branches: refs/heads/trunk 42c55896b - d5fc1932e Merge branch 'cassandra-1.1' into trunk Conflicts: CHANGES.txt src/java/org/apache/cassandra/db/CounterMutationVerbHandler.java src/java/org/apache/cassandra/service/StorageProxy.java src/java/org/apache/cassandra/service/WriteResponseHandler.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d5fc1932 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d5fc1932 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d5fc1932 Branch: refs/heads/trunk Commit: d5fc1932e965a32c944efcdf95fd0236624949fc Parents: 42c5589 7371e10 Author: Sylvain Lebresne sylv...@datastax.com Authored: Fri Sep 7 10:50:38 2012 +0200 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Fri Sep 7 10:50:38 2012 +0200 -- CHANGES.txt|6 .../org/apache/cassandra/db/CounterColumn.java |2 +- .../cassandra/db/CounterMutationVerbHandler.java | 23 +++ .../locator/AbstractReplicationStrategy.java |8 ++-- .../service/AbstractWriteResponseHandler.java | 17 +- .../DatacenterSyncWriteResponseHandler.java| 10 +++--- .../service/DatacenterWriteResponseHandler.java| 10 +++--- .../org/apache/cassandra/service/StorageProxy.java | 17 ++ .../cassandra/service/WriteResponseHandler.java| 12 9 files changed, 69 insertions(+), 36 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/d5fc1932/CHANGES.txt -- diff --cc CHANGES.txt index ec4992c,f192be2..0905cf9 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,58 -1,9 +1,64 @@@ +1.2-beta1 + * include message initiation time to replicas so they can more + accurately drop timed-out requests (CASSANDRA-2858) + * fix clientutil.jar dependencies (CASSANDRA-4566) + * optimize WriteResponse (CASSANDRA-4548) + * new metrics (CASSANDRA-4009) + * redesign KEYS indexes to avoid read-before-write (CASSANDRA-2897) + * debug tracing (CASSANDRA-1123) + * parallelize row cache loading (CASSANDRA-4282) + * Make compaction, flush JBOD-aware (CASSANDRA-4292) + * run local range scans on the read stage (CASSANDRA-3687) + * clean up ioexceptions (CASSANDRA-2116) + * add disk_failure_policy (CASSANDRA-2118) + * Introduce new json format with row level deletion (CASSANDRA-4054) + * remove redundant name column from schema_keyspaces (CASSANDRA-4433) + * improve nodetool ring handling of multi-dc clusters (CASSANDRA-3047) + * update NTS calculateNaturalEndpoints to be O(N log N) (CASSANDRA-3881) + * add UseCondCardMark XX jvm settings on jdk 1.7 (CASSANDRA-4366) + * split up rpc timeout by operation type (CASSANDRA-2819) + * rewrite key cache save/load to use only sequential i/o (CASSANDRA-3762) + * update MS protocol with a version handshake + broadcast address id + (CASSANDRA-4311) + * multithreaded hint replay (CASSANDRA-4189) + * add inter-node message compression (CASSANDRA-3127) + * remove COPP (CASSANDRA-2479) + * Track tombstone expiration and compact when tombstone content is + higher than a configurable threshold, default 20% (CASSANDRA-3442, 4234) + * update MurmurHash to version 3 (CASSANDRA-2975) + * (CLI) track elapsed time for `delete' operation (CASSANDRA-4060) + * (CLI) jline version is bumped to 1.0 to properly support + 'delete' key function (CASSANDRA-4132) + * Save IndexSummary into new SSTable 'Summary' component (CASSANDRA-2392, 4289) + * Add support for range tombstones (CASSANDRA-3708) + * Improve MessagingService efficiency (CASSANDRA-3617) + * Avoid ID conflicts from concurrent schema changes (CASSANDRA-3794) + * Set thrift HSHA server thread limit to unlimited by default (CASSANDRA-4277) + * Avoids double serialization of CF id in RowMutation messages + (CASSANDRA-4293) + * stream compressed sstables directly with java nio (CASSANDRA-4297) + * Support multiple ranges in SliceQueryFilter (CASSANDRA-3885) + * Add column metadata to system column families (CASSANDRA-4018) + * (cql3) Always use composite types by default (CASSANDRA-4329) + * (cql3) Add support for set, map and list (CASSANDRA-3647) + * Validate date type correctly (CASSANDRA-4441) + * (cql3) Allow definitions with only a PK (CASSANDRA-4361) + * (cql3) Add support for row key composites (CASSANDRA-4179) + * improve DynamicEndpointSnitch by using reservoir sampling (CASSANDRA-4038) + * (cql3) Add support for 2ndary indexes (CASSANDRA-3680) + * (cql3) fix defining more than one PK to be invalid (CASSANDRA-4477) + * remove schema agreement checking from all external APIs (Thrift, CQL and CQL3) (CASSANDRA-4487) + * add
[2/2] git commit: Fix potential deadlock during counter writes
Fix potential deadlock during counter writes
patch by slebresne; reviewed by jbellis for CASSANDRA-4578
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7371e10b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7371e10b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7371e10b
Branch: refs/heads/trunk
Commit: 7371e10be40d9a01167d36eb2db69526b6b0ce50
Parents: 4177b58
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Thu Sep 6 14:57:08 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Fri Sep 7 10:41:58 2012 +0200
--
CHANGES.txt|1 +
.../org/apache/cassandra/db/CounterColumn.java |2 +-
.../cassandra/db/CounterMutationVerbHandler.java | 32 +++---
.../locator/AbstractReplicationStrategy.java |8 ++--
.../service/AbstractWriteResponseHandler.java | 17 +++-
.../DatacenterSyncWriteResponseHandler.java| 10 ++--
.../service/DatacenterWriteResponseHandler.java| 10 ++--
.../org/apache/cassandra/service/StorageProxy.java | 17 +---
.../cassandra/service/WriteResponseHandler.java| 12 +++---
9 files changed, 72 insertions(+), 37 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7371e10b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4a5bfe9..f192be2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,7 @@
1.1.6
* (cql3) fix potential NPE with both equal and unequal restriction
(CASSANDRA-4532)
* (cql3) improves ORDER BY validation (CASSANDRA-4624)
+ * Fix potential deadlock during counter writes (CASSANDRA-4578)
1.1.5
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7371e10b/src/java/org/apache/cassandra/db/CounterColumn.java
--
diff --git a/src/java/org/apache/cassandra/db/CounterColumn.java
b/src/java/org/apache/cassandra/db/CounterColumn.java
index 2ea0779..b6e3909 100644
--- a/src/java/org/apache/cassandra/db/CounterColumn.java
+++ b/src/java/org/apache/cassandra/db/CounterColumn.java
@@ -370,7 +370,7 @@ public class CounterColumn extends Column
responseHandler.response(null);
StorageProxy.sendToHintedEndpoints((RowMutation) mutation,
targets, responseHandler, localDataCenter, consistency_level);
}
-});
+}, null);
// we don't wait for answers
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7371e10b/src/java/org/apache/cassandra/db/CounterMutationVerbHandler.java
--
diff --git a/src/java/org/apache/cassandra/db/CounterMutationVerbHandler.java
b/src/java/org/apache/cassandra/db/CounterMutationVerbHandler.java
index 01d7b50..3ecbe8b 100644
--- a/src/java/org/apache/cassandra/db/CounterMutationVerbHandler.java
+++ b/src/java/org/apache/cassandra/db/CounterMutationVerbHandler.java
@@ -35,7 +35,7 @@ public class CounterMutationVerbHandler implements
IVerbHandler
{
private static Logger logger =
LoggerFactory.getLogger(CounterMutationVerbHandler.class);
-public void doVerb(Message message, String id)
+public void doVerb(final Message message, final String id)
{
byte[] bytes = message.getMessageBody();
FastByteArrayInputStream buffer = new FastByteArrayInputStream(bytes);
@@ -43,15 +43,33 @@ public class CounterMutationVerbHandler implements
IVerbHandler
try
{
DataInputStream is = new DataInputStream(buffer);
-CounterMutation cm = CounterMutation.serializer().deserialize(is,
message.getVersion());
+final CounterMutation cm =
CounterMutation.serializer().deserialize(is, message.getVersion());
if (logger.isDebugEnabled())
logger.debug(Applying forwarded + cm);
String localDataCenter =
DatabaseDescriptor.getEndpointSnitch().getDatacenter(FBUtilities.getBroadcastAddress());
-StorageProxy.applyCounterMutationOnLeader(cm,
localDataCenter).get();
-WriteResponse response = new WriteResponse(cm.getTable(),
cm.key(), true);
-Message responseMessage =
WriteResponse.makeWriteResponseMessage(message, response);
-MessagingService.instance().sendReply(responseMessage, id,
message.getFrom());
+// We should not wait for the result of the write in this thread,
+// otherwise we could have a distributed deadlock between replicas
+// running this VerbHandler (see #4578).
+// Instead, we use a callback to send the response. Note that the
callback
+// will not be
git commit: Simplify and generalize startup message in binary protocol
Updated Branches: refs/heads/trunk d5fc1932e - f1711794c Simplify and generalize startup message in binary protocol patch by slebresne; reviewed by thepaul for CASSANDRA-4539 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f1711794 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f1711794 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f1711794 Branch: refs/heads/trunk Commit: f1711794cf911c349a3b60e0104064adb8124148 Parents: d5fc193 Author: Sylvain Lebresne sylv...@datastax.com Authored: Fri Sep 7 10:55:13 2012 +0200 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Fri Sep 7 10:55:13 2012 +0200 -- doc/native_protocol.spec | 30 +++--- .../org/apache/cassandra/transport/CBUtil.java | 48 + .../org/apache/cassandra/transport/Client.java |7 +- .../apache/cassandra/transport/SimpleClient.java |7 +- .../transport/messages/OptionsMessage.java | 20 +++- .../transport/messages/StartupMessage.java | 80 +++ .../transport/messages/SupportedMessage.java | 23 ++--- 7 files changed, 109 insertions(+), 106 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f1711794/doc/native_protocol.spec -- diff --git a/doc/native_protocol.spec b/doc/native_protocol.spec index d19963b..1de7a95 100644 --- a/doc/native_protocol.spec +++ b/doc/native_protocol.spec @@ -161,6 +161,11 @@ Table of Contents will be described when this is used. [option list] A [short] n, followed by n [option]. +[string map] A [short] n, followed by n pair kv where k and v + are [string]. +[string multimap] A [short] n, followed by n pair kv where k is a + [string] and v is a [string list]. + 4. Messages @@ -176,19 +181,16 @@ Table of Contents (in which case credentials will need to be provided using CREDENTIALS). This must be the first message of the connection, except for OPTIONS that can - be sent before to find out the option supported by the server. Once the + be sent before to find out the options supported by the server. Once the connection has been initialized, a client should not send any more STARTUP message. - The body is defined as: -versionoptions - where: -- version is a [string] representing the version of the CQL version to use. - Currently the only version supported is 3.0.0. Note that this is different - from the protocol version. -- options is an [option list]. Valid option ids are: -0x0001Compression: the value is a [string] representing the - algorithm to use (See section 5). + The body is a [string map] of options. Possible options are: +- CQL_VERSION: the version of CQL to use. This option is mandatory and + currenty, the only version supported is 3.0.0. Note that this is + different from the protocol version. +- COMPRESSION: the compression algorithm to use for frames (See section 5). + This is optional, if not specified no compression will be used. 4.1.2. CREDENTIALS @@ -284,10 +286,8 @@ Table of Contents Indicates which startup options are supported by the server. This message comes as a response to an OPTIONS message. - The body of a SUPPORTED message is a [string list] indicating which CQL - version the server support, followed by a second [string list] indicating - which compression algorithm is supported, if any (at the time of this writing, - only snappy compression is available if the library is in the classpath). + The body of a SUPPORTED message is a [string multimap]. This multimap gives + for each of the supported STARTUP options, the list of supported values. 4.2.5. RESULT @@ -397,7 +397,7 @@ Table of Contents use, which is done in the STARTUP message. As a consequence, a STARTUP message must never be compressed. However, once the STARTUP frame has been received by the server can be compressed (including the response to the STARTUP - request). Frame do not have to compressed however, even if compression has + request). Frame do not have to be compressed however, even if compression has been agreed upon (a server may only compress frame above a certain size at its discretion). A frame body should be compressed if and only if the compressed flag (see Section 2.2) is set. http://git-wip-us.apache.org/repos/asf/cassandra/blob/f1711794/src/java/org/apache/cassandra/transport/CBUtil.java -- diff --git a/src/java/org/apache/cassandra/transport/CBUtil.java
[jira] [Commented] (CASSANDRA-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450475#comment-13450475
]
Pavel Yaskevich commented on CASSANDRA-4561:
Yes it does, but it assumes that you have schema in agreement across the nodes
before it tries to fix timestamps. I can put that into NEWS.txt
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
Fix For: 1.1.5
Attachments: CASSANDRA-4561.patch
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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: Adds events push to binary protocol
Updated Branches: refs/heads/trunk f1711794c - f199fa39b Adds events push to binary protocol patch by slebresne; reviewed by thepaul for CASSANDRA-4480 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f199fa39 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f199fa39 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f199fa39 Branch: refs/heads/trunk Commit: f199fa39bb7a536a203a5154de24ae67c137ec23 Parents: f171179 Author: Sylvain Lebresne sylv...@datastax.com Authored: Wed Aug 8 17:12:20 2012 +0200 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Fri Sep 7 11:02:03 2012 +0200 -- doc/native_protocol.spec | 59 ++- .../org/apache/cassandra/transport/CBUtil.java | 29 +++ .../org/apache/cassandra/transport/Client.java | 13 ++ .../org/apache/cassandra/transport/Connection.java | 97 ++ src/java/org/apache/cassandra/transport/Event.java | 146 +++ src/java/org/apache/cassandra/transport/Frame.java |6 +- .../org/apache/cassandra/transport/Message.java|9 +- .../org/apache/cassandra/transport/Server.java | 74 +++- .../cassandra/transport/ServerConnection.java | 93 + .../apache/cassandra/transport/SimpleClient.java | 16 +-- .../transport/messages/CredentialsMessage.java |3 +- .../cassandra/transport/messages/EventMessage.java | 60 ++ .../transport/messages/ExecuteMessage.java |5 +- .../transport/messages/PrepareMessage.java |2 +- .../cassandra/transport/messages/QueryMessage.java |2 +- .../transport/messages/RegisterMessage.java| 80 .../transport/messages/StartupMessage.java |9 +- 17 files changed, 588 insertions(+), 115 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f199fa39/doc/native_protocol.spec -- diff --git a/doc/native_protocol.spec b/doc/native_protocol.spec index 1de7a95..07d5c69 100644 --- a/doc/native_protocol.spec +++ b/doc/native_protocol.spec @@ -8,8 +8,9 @@ Table of Contents 2. Frame header 2.1. version 2.2. flags -2.3. opcode -2.4. length +2.3. stream +2.4. opcode +2.5. length 3. Notations 4. Messages 4.1. Requests @@ -19,6 +20,7 @@ Table of Contents 4.1.4. QUERY 4.1.5. PREPARE 4.1.6. EXECUTE + 4.1.7. REGISTER 4.2. Responses 4.2.1. ERROR 4.2.2. READY @@ -29,6 +31,7 @@ Table of Contents 4.2.5.2. Rows 4.2.5.3. Set_keyspace 4.2.5.4. Prepared + 4.2.6. EVENT 5. Compression 6. Error codes @@ -100,9 +103,10 @@ Table of Contents A frame has a stream id (one signed byte). When sending request messages, this stream id must be set by the client to a positive byte (negative stream id - are reserved for future stream initiated by the server). If a client sends a - request message with the stream id X, it is guaranteed that the stream id of - the response to that message will be X. + are reserved for streams initiated by the server; currently all EVENT messages + (section 4.2.6) have a streamId of -1). If a client sends a request message + with the stream id X, it is guaranteed that the stream id of the response to + that message will be X. This allow to deal with the asynchronous nature of the protocol. If a client sends multiple messages simultaneously (without waiting for responses), there @@ -131,11 +135,13 @@ Table of Contents 0x08RESULT 0x09PREPARE 0x0AEXECUTE +0x0BREGISTER +0x0CEVENT Messages are described in Section 4. -2.4. length +2.5. length A 4 byte integer representing the length of the body of the frame (note: currently a frame is limited to 256MB in length). @@ -160,6 +166,11 @@ Table of Contents of size 0). The supported id (and the corresponding value) will be described when this is used. [option list] A [short] n, followed by n [option]. +[inet] An address (ip and port) to a node. It consists of one + [byte] n, that represents the address size, followed by n + [byte] repesenting the IP address (in practice n can only be + either 4 (IPv4) or 16 (IPv6)), following by one [int] + representing the port. [string map] A [short] n, followed by n pair kv where k and v are [string]. @@ -247,6 +258,21 @@ Table of Contents The response from the server will be a RESULT message. +4.1.7. REGISTER + + Register this connection to receive some type of events. The body of the + message is a [string
[jira] [Commented] (CASSANDRA-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450479#comment-13450479
]
Anton Winter commented on CASSANDRA-4561:
-
My schema is in agreement, but the timestamps aren't fixed, even though the log
suggests otherwise (is that previously mentioned NPE related?).
{code}
[default@unknown] describe cluster;
Cluster Information:
Snitch: org.apache.cassandra.locator.PropertyFileSnitch
Partitioner: org.apache.cassandra.dht.RandomPartitioner
Schema versions:
89b22434-5e34-381d-83d1-2a3cde1482fe: [x, x, x, x, x, x, x, x, x, x, x,
x, x, x, x, x, x, x, x, x, x, x, x, x, x]
[default@unknown]
{code}
Schema updates continue to silently fail.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
Fix For: 1.1.5
Attachments: CASSANDRA-4561.patch
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450480#comment-13450480 ] Sylvain Lebresne commented on CASSANDRA-4480: - bq. when I stop an existing node and start it again, I still receive a TOPOLOGY_CHANGE - NEW_NODE event after the two STATUS_CHANGE - UP events, even though the up'd node was previously known That's weird, but I'll blame gossip. I've doubled-checked and the patch don't send a NEW_NODE expect on gossiper.onJoin() calls. I don't know, maybe it's a know behavior of gossip though. Anyway, I've committed (since I'm pretty sure this has nothing to do with patch) this but I'll check why gossip do that. Regardless, clients will probably have to be resilient to that kind of things. Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 beta 1 Attachments: 4480.txt, 4480-v2.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4467) insufficient space for compaction when upgrade compaction strategy from SizeTiered to Leveled
[ https://issues.apache.org/jira/browse/CASSANDRA-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450484#comment-13450484 ] Vitalii Tymchyshyn commented on CASSANDRA-4467: --- I did also hit this. Upgrade requires double the space. As for me, workaround was to move large files out of data directory, upgrade, then move them back to be picked up. I'd say LeveledCompaction upgrade can do the same - convert not all at once, but as much as it can multiple times. It will be slower, but you won't have this: WARN [CompactionExecutor:17] 2012-09-07 12:09:47,600 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,600 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,600 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,601 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,601 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,601 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,601 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,602 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,602 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,602 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,602 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,602 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,603 CompactionTask.java (line 94) insufficient space to compact; aborting compaction WARN [CompactionExecutor:17] 2012-09-07 12:09:47,603 CompactionTask.java (line 94) insufficient space to compact; aborting compaction BTW: When I did return files and asked to discover new files, It've also picked up some files current compaction run was producing. Dunno if it's OK. insufficient space for compaction when upgrade compaction strategy from SizeTiered to Leveled - Key: CASSANDRA-4467 URL: https://issues.apache.org/jira/browse/CASSANDRA-4467 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Environment: Ubuntu,Oracle Java 1.7,Cassandra 1.0.10 Reporter: Cheng Zhang Assignee: Yuki Morishita Priority: Minor Cassandra has two data directories as follow: cassandra-disk0 use about 500G, about 250G free space cassandra-disk1 use about 500G, about 250G free space The max data file is about 400G. When I upgrade from SizeTieredCompactionStrategy to LeveledCompactionStrategy, there is no space to do this, for the free space of every data directory is small than the largest data file. But the total free space is enough for compaction. -- 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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450485#comment-13450485
]
Pavel Yaskevich commented on CASSANDRA-4561:
Interesting, why does it try to merge remote schema if all of your nodes are in
agreement, can you run in debug mode as attach the log? The thing is timestamps
are fixed long before the storage server is initialized and the process
involves truncate of the system.schema_* CFs so I don't see any other reason
why your schema still has old timestamps except some other node sent it
migration request...
NPE that you experience is also interesting, cfMetaData() is always not null as
CFs are copied from one map to another on KS initialization, and KS itself
could not be null or you would have the assertion error instead of NPE.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
Fix For: 1.1.5
Attachments: CASSANDRA-4561.patch
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4630) SSTable data file filedescriptor leak in mmap_index_only disk access mode
Wojciech Meler created CASSANDRA-4630: - Summary: SSTable data file filedescriptor leak in mmap_index_only disk access mode Key: CASSANDRA-4630 URL: https://issues.apache.org/jira/browse/CASSANDRA-4630 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.4 Environment: centos-6.2, Oracle jdk 1.7, 1.6, OpenJDK-1.6.0 Reporter: Wojciech Meler Priority: Blocker After upgrading one node from 0.8.10 to 1.1.4 I've got java.net.SocketException: Too many open files in system. lsof showed that one of CF is opened multiple times: 7 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-he-26595-Data.db 18 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-g-26576-Data.db 185 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-g-26536-Data.db 328 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-g-26580-Data.db 18194 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-g-26590-Data.db 21339 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-g-26512-Data.db 24416 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-g-26557-Data.db nodetool cfstats says that this CF was read about 80K times -- 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 update of CF comparator
Updated Branches:
refs/heads/trunk f199fa39b - ceca1997d
Fix update of CF comparator
patch by slebresne; reviewed by jbellis for CASSANDRA-4493
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ceca1997
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ceca1997
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ceca1997
Branch: refs/heads/trunk
Commit: ceca1997d045c8f09b198e73a956bfaddc11485a
Parents: f199fa3
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Fri Sep 7 11:58:02 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Fri Sep 7 11:58:02 2012 +0200
--
CHANGES.txt|1 +
.../cql3/statements/AlterTableStatement.java |8 +-
.../org/apache/cassandra/db/ColumnFamilyStore.java | 17 +++
3 files changed, 24 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ceca1997/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0905cf9..8245343 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -51,6 +51,7 @@
* add Murmur3Partitioner and make it default for new installations
(CASSANDRA-3772)
* (cql3) update pseudo-map syntax to use map syntax (CASSANDRA-4497)
* Finer grained exceptions hierarchy and provides error code with exceptions
(CASSANDRA-3979)
+ * Adds events push to binary protocol (CASSANDRA-4480)
1.1.6
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ceca1997/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
index 3204e81..4e35adb 100644
--- a/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterTableStatement.java
@@ -77,15 +77,19 @@ public class AlterTableStatement extends
SchemaAlteringStatement
}
}
+Integer componentIndex = cfDef.isComposite ?
((CompositeType)meta.comparator).types.size() - 1 : null;
AbstractType? type = validator.getType();
if (type instanceof CollectionType)
{
if (!cfDef.isComposite)
throw new InvalidRequestException(Cannot use
collection types with non-composite PRIMARY KEY);
+componentIndex--;
+
MapByteBuffer, CollectionType collections =
cfDef.hasCollections
? new
HashMapByteBuffer, CollectionType(cfDef.getCollectionType().defined)
: new
HashMapByteBuffer, CollectionType();
+collections.put(columnName.key, (CollectionType)type);
ColumnToCollectionType newColType =
ColumnToCollectionType.getInstance(collections);
ListAbstractType? ctypes = new
ArrayListAbstractType?(((CompositeType)cfm.comparator).types);
if (cfDef.hasCollections)
@@ -95,11 +99,11 @@ public class AlterTableStatement extends
SchemaAlteringStatement
cfm.comparator = CompositeType.getInstance(ctypes);
}
cfm.addColumnDefinition(new ColumnDefinition(columnName.key,
-
validator.getType(),
+ type,
null,
null,
null,
- cfDef.isComposite
? ((CompositeType)meta.comparator).types.size() - 1 : null));
+ componentIndex));
break;
case ALTER:
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ceca1997/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index caa8dbc..44dc23a 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -152,6 +152,23 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
maybeReloadCompactionStrategy();
[jira] [Commented] (CASSANDRA-4612) cql error with ORDER BY when using IN
[
https://issues.apache.org/jira/browse/CASSANDRA-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450503#comment-13450503
]
Sylvain Lebresne commented on CASSANDRA-4612:
-
lgtm, +1
cql error with ORDER BY when using IN
-
Key: CASSANDRA-4612
URL: https://issues.apache.org/jira/browse/CASSANDRA-4612
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.4
Environment: ubuntu, cassandra trunk (commit
769fe895a36868c47101f681f5fdd721bee1ad62 )
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.6
Attachments: CASSANDRA-4612.patch, CASSANDRA-4612-v2.patch
{code}
CREATE TABLE test(
my_id varchar,
col1 int,
value varchar,
PRIMARY KEY (my_id, col1)
);
INSERT INTO test(my_id, col1, value) VALUES ( 'key1', 1, 'a');
INSERT INTO test(my_id, col1, value) VALUES ( 'key2', 3, 'c');
INSERT INTO test(my_id, col1, value) VALUES ( 'key3', 2, 'b');
INSERT INTO test(my_id, col1, value) VALUES ( 'key4', 4, 'd');
SELECT col1 FROM test WHERE my_id in('key1', 'key2', 'key3') ORDER BY col1;
{code}
The following error results: TSocket read 0 bytes
The log gives a traceback:
{code}
ERROR [Thrift:8] 2012-09-04 12:02:15,894 CustomTThreadPoolServer.java (line
202) Error occurred during processing of message.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1356)
at
org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1343)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.cassandra.cql3.statements.SelectStatement.orderResults(SelectStatement.java:821)
at
org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:793)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:136)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:62)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:115)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1521)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3618)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3606)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
[ https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne reassigned CASSANDRA-4495: --- Assignee: Sylvain Lebresne Don't tie client side use of AbstractType to JDBC - Key: CASSANDRA-4495 URL: https://issues.apache.org/jira/browse/CASSANDRA-4495 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.3 We currently expose the AbstractType to java clients that want to reuse them though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL and will never be). Typically, there is a fair amount of the JDBC standard that cannot be implemented with C*, and there is a number of specificity of C* that are not in JDBC (typically the set and maps collections). So I propose to extract simple type classes with just a compose and decompose method (but without ties to jdbc, which would allow all the jdbc specific method those types have) in the purpose of exporting that in a separate jar for clients (we could put that in a org.apache.cassandra.type package for instance). We could then deprecate the jdbc classes with basically the same schedule than CQL2. Let me note that this is *not* saying there shouldn't be a JDBC driver for Cassandra. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4628) CQL/JDBC: date vs. timestamp issues
[ https://issues.apache.org/jira/browse/CASSANDRA-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450508#comment-13450508 ] Sylvain Lebresne commented on CASSANDRA-4628: - I'm a fairly strong believer that adding the Jdbc* classes was a mistake in the first place. See CASSANDRA-4495 for a bit more argumentation. So I must admit that I'm not sure I understand what it is you suggest exactly concerning Cassandra itself in this ticket, so I don't want to close this right way, but I have the feeling that whatever needs to be done probably concerns the jdbc driver, not Cassandra. As a side note, I wouldn't disagree that Cassandra/CQL handling of dates is a tad limited and it might probably be worth beefing it up at some point, but that's largely a different issue. CQL/JDBC: date vs. timestamp issues --- Key: CASSANDRA-4628 URL: https://issues.apache.org/jira/browse/CASSANDRA-4628 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.4 Reporter: Michael Krumpholz Priority: Critical Labels: cql, jdbc Cassandra's datatypes only have one Date/Time type named timestamp containing both date and time. Calling the validator org.apache.cassandra.db.marshal.DateType might be OK in general but can be confusing in the jdbc context where there is a distinction between date, time and timestamp. In terms of jdbc there should be more datatypes for dates and times or the jdbc driver should take one of the following options: - stick to timestamp - check if the date has a time part and distinguish by the data between date and timestamp automatically - use distinct datatypes according to the jdbc spec, the types would need to be in cassandra then too Now back to my actual problem: org.apache.cassandra.cql.jdbc.JdbcDate returns Types.DATE in getType(). Even if having inserted a complete date with time (making it a timestamp) the ResultSetMetaData.getColumnType() implementation still returns Types.DATE (source of this is in JdbcDate). If some other java code (where i don't have access to) uses the metadata to get the type and then getDate() to get the value the time is cut off the value and only the date is returned. But the ResultSet.getObject() implementation returns a complete java.util.Date including the time. -- 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-4629) CQL/JDBC: implement complete jdbc metadata
[
https://issues.apache.org/jira/browse/CASSANDRA-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-4629.
-
Resolution: Invalid
CassandraDatabaseMetadata is not a Cassandra class. You'd want to open an issue
at http://code.google.com/a/apache-extras.org/p/cassandra-jdbc/ (the jdbc
driver is not part of the Cassandra project).
CQL/JDBC: implement complete jdbc metadata
--
Key: CASSANDRA-4629
URL: https://issues.apache.org/jira/browse/CASSANDRA-4629
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.1.4
Reporter: Michael Krumpholz
Labels: cql, jdbc
Please provide a more complete implementation of the jdbc spec for the
metadata. The CassandraDatabaseMetaData implementation of DatabaseMetaData
returns only empty result sets for the important methods. Also the
getIdentifierQuoteString() returns single quote (') instead of double quotes
(). should be the correct quote string for SQL identifiers at least in my
understanding!?
I have written some code at least for some parts of the jdbc api that we need
using cql queries on the system.schema_* tables. I put the code for our
project into separated classes to avoid direct changes to libs which will
change/improve in new versions. I don't know if it's complete and/or correct
in all cases.
--
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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450512#comment-13450512
]
Sylvain Lebresne commented on CASSANDRA-4561:
-
Maybe we should reopen this if that didn't fully fixed the problem? I'd better
hold on a bit on 1.1.5 if this is not fixed yet as this seem to hit quite a few
people.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
Fix For: 1.1.5
Attachments: CASSANDRA-4561.patch
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4630) SSTable data file filedescriptor leak in mmap_index_only disk access mode
[ https://issues.apache.org/jira/browse/CASSANDRA-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-4630. - Resolution: Duplicate This is a duplicate of CASSANDRA-4571. SSTable data file filedescriptor leak in mmap_index_only disk access mode - Key: CASSANDRA-4630 URL: https://issues.apache.org/jira/browse/CASSANDRA-4630 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.4 Environment: centos-6.2, Oracle jdk 1.7, 1.6, OpenJDK-1.6.0 Reporter: Wojciech Meler Priority: Blocker After upgrading one node from 0.8.10 to 1.1.4 I've got java.net.SocketException: Too many open files in system. lsof showed that one of CF is opened multiple times: 7 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-he-26595-Data.db 18 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-g-26576-Data.db 185 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-g-26536-Data.db 328 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-g-26580-Data.db 18194 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-g-26590-Data.db 21339 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-g-26512-Data.db 24416 /var/lib/cassandra/data/mail/mta_logs/mail-mta_logs-g-26557-Data.db nodetool cfstats says that this CF was read about 80K times -- 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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450526#comment-13450526
]
Pavel Yaskevich commented on CASSANDRA-4561:
We are not yet sure what is the problem so I think we should hold on reopening
for a bit.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
Fix For: 1.1.5
Attachments: CASSANDRA-4561.patch
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450529#comment-13450529
]
Pavel Yaskevich commented on CASSANDRA-4561:
I just thought that a good addition to existing patch could be change in
ColumnSerializer.deserialize to fix timestamps from the future, that way
migrations from the remote locations would be deserialized with correct
timestamp even if they were sent with the wrong one...
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
Fix For: 1.1.5
Attachments: CASSANDRA-4561.patch
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450531#comment-13450531
]
Sylvain Lebresne commented on CASSANDRA-4561:
-
Well, Anton still sees timestamp in the future and is still unable to do schema
updates, it does sound a lot like there is a problem and it's related to this
ticket. I just meant that I prefer keeping that in mind before releasing 1.1.5
into the wild too quickly.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
Fix For: 1.1.5
Attachments: CASSANDRA-4561.patch
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4628) CQL/JDBC: date vs. timestamp issues
[ https://issues.apache.org/jira/browse/CASSANDRA-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450532#comment-13450532 ] Michael Krumpholz commented on CASSANDRA-4628: -- The JdbcDate class is not part of the jdbc driver package which is a separate project at google (as you mentioned in my other issue). But the getType there returns the JDBC datatype (from java.sql.Types) that is returned in the metadata according to the jdbc spec. The problem is that Types.DATE is the wrong type. It should be Types.TIMESTAMP because the data can be more that just a date, it can be a timestamp. Using ResultSet.getDate() because of the returned type cuts off the time part of the timestamp. JDBC has the date time distinction, cassandra not. in short words, but i assume you are aware of this: date != timestamp, timestamp = date + time CQL/JDBC: date vs. timestamp issues --- Key: CASSANDRA-4628 URL: https://issues.apache.org/jira/browse/CASSANDRA-4628 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.4 Reporter: Michael Krumpholz Priority: Critical Labels: cql, jdbc Cassandra's datatypes only have one Date/Time type named timestamp containing both date and time. Calling the validator org.apache.cassandra.db.marshal.DateType might be OK in general but can be confusing in the jdbc context where there is a distinction between date, time and timestamp. In terms of jdbc there should be more datatypes for dates and times or the jdbc driver should take one of the following options: - stick to timestamp - check if the date has a time part and distinguish by the data between date and timestamp automatically - use distinct datatypes according to the jdbc spec, the types would need to be in cassandra then too Now back to my actual problem: org.apache.cassandra.cql.jdbc.JdbcDate returns Types.DATE in getType(). Even if having inserted a complete date with time (making it a timestamp) the ResultSetMetaData.getColumnType() implementation still returns Types.DATE (source of this is in JdbcDate). If some other java code (where i don't have access to) uses the metadata to get the type and then getDate() to get the value the time is cut off the value and only the date is returned. But the ResultSet.getObject() implementation returns a complete java.util.Date including the time. -- 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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450534#comment-13450534
]
Pavel Yaskevich commented on CASSANDRA-4561:
I understand, but we don't know if that is caused by the fix not working or by
something else as exception indicates that something was send to the node, this
could be a separate issue. I will work on the ColumnSerializer change I
mentioned and we'll see if it helps.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
Fix For: 1.1.5
Attachments: CASSANDRA-4561.patch
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450545#comment-13450545
]
Pavel Yaskevich commented on CASSANDRA-4561:
As I see from the log - timestamps were actually fixed to 7 september 2012 cl
10:58 GMT but then overriten by remote migration, latest patch should help
with that.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
Fix For: 1.1.5
Attachments: CASSANDRA-4561-CS.patch, CASSANDRA-4561.patch
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450548#comment-13450548
]
Zenek Kraweznik commented on CASSANDRA-4561:
When cassandra 1.1.5 will be available?
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
Fix For: 1.1.5
Attachments: CASSANDRA-4561-CS.patch, CASSANDRA-4561.patch
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4559) implement token relocation
[
https://issues.apache.org/jira/browse/CASSANDRA-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450649#comment-13450649
]
Brandon Williams commented on CASSANDRA-4559:
-
I'm pretty sure any gossip-related issues were fixed with the last patch on
CASSANDRA-4383. But now there are other problems with missing data
occasionally. It's not entirely easy to replicate since it seems to depend on
what shuffle decides to do which is random, but here is the simplest example
I've distilled from the logs with a small amount of vnodes.
Given nodes A through C with the following tokens (which were evenly split
single tokens, but now are contiguous two-token ranges after upgrading):
A - 0,5
B - 1,2
C - 3,4
shuffle attempts to move them to:
A - 1,3
B - 0,5
C - 2,4
The first step begins as follows:
A begins taking 1 from B
B begins taking 5 from A
C begins taking 2 from B
At this point, one interesting is that pendingRanges on all nodes look like
this:
A: (4,1]
B: (5,5]
C: (2,2]
B and C both have the entire ring pending, which may or may not be significant.
Now A correctly requests (0,1] from B, B correctly requests (4,5] from A, and C
correctly requests (1,2] from B.
Next, A takes (2,3] from C, B takes (5,0] from A, but C already owns (3,4] and
does nothing.
At this point shuffle is complete, but there is at least one key missing from
each node, which is odd because it means C's first and only step was faulty.
Other shuffle combinations with these same tokens/layout can succeed, so I'm
not entirely sure what makes the failures special, but I'll keep looking into
it.
implement token relocation
--
Key: CASSANDRA-4559
URL: https://issues.apache.org/jira/browse/CASSANDRA-4559
Project: Cassandra
Issue Type: Sub-task
Components: Core, Tools
Affects Versions: 1.2.0 beta 1
Reporter: Eric Evans
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0 beta 1
Whatever the specifics of a _shuffle_ (see CASSANDRA-4443), it will be
necessary to relocate a range from one node to another.
_Edit0: Linked in new patch containing tests._
h3. Patches
||Compare||Raw diff||Description||
|[010_refactor_range_move|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move]|[010_refactor_range_move.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move.diff]|No
Description|
|[020_calculate_pending|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending]|[020_calculate_pending.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending.diff]|No
Description|
|[030_relocate_token|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token]|[030_relocate_token.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token.diff]|No
Description|
|[040_tests|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests]|[040_tests.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4628) CQL/JDBC: date vs. timestamp issues
[ https://issues.apache.org/jira/browse/CASSANDRA-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4628. --- Resolution: Invalid bq. the getType there returns the JDBC datatype that is an issue with the jdbc driver then, not Cassandra CQL/JDBC: date vs. timestamp issues --- Key: CASSANDRA-4628 URL: https://issues.apache.org/jira/browse/CASSANDRA-4628 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.4 Reporter: Michael Krumpholz Priority: Critical Labels: cql, jdbc Cassandra's datatypes only have one Date/Time type named timestamp containing both date and time. Calling the validator org.apache.cassandra.db.marshal.DateType might be OK in general but can be confusing in the jdbc context where there is a distinction between date, time and timestamp. In terms of jdbc there should be more datatypes for dates and times or the jdbc driver should take one of the following options: - stick to timestamp - check if the date has a time part and distinguish by the data between date and timestamp automatically - use distinct datatypes according to the jdbc spec, the types would need to be in cassandra then too Now back to my actual problem: org.apache.cassandra.cql.jdbc.JdbcDate returns Types.DATE in getType(). Even if having inserted a complete date with time (making it a timestamp) the ResultSetMetaData.getColumnType() implementation still returns Types.DATE (source of this is in JdbcDate). If some other java code (where i don't have access to) uses the metadata to get the type and then getDate() to get the value the time is cut off the value and only the date is returned. But the ResultSet.getObject() implementation returns a complete java.util.Date including the time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450653#comment-13450653 ] Brandon Williams commented on CASSANDRA-4480: - onJoin() is unfortunately not well named, but it doesn't indicate a new node (Gossiper doesn't decide membership) only that a node is up. If you actually want to track membership you'd probably want to check tMD in SS's onJoin. Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 beta 1 Attachments: 4480.txt, 4480-v2.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450659#comment-13450659 ] Sylvain Lebresne commented on CASSANDRA-4480: - Hum, I see. Out of curiosity, what's the difference between onJoin() and onAlive()? And what of onRemove()? In any case, I'll look at fixing that. Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 beta 1 Attachments: 4480.txt, 4480-v2.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450670#comment-13450670
]
Anton Winter commented on CASSANDRA-4561:
-
Ring upgraded with the second patch and I am now able to perform schema
updates. Thanks!
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
Fix For: 1.1.5
Attachments: CASSANDRA-4561-CS.patch, CASSANDRA-4561.patch
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4036) cqlsh: EOF during multiline statement
[ https://issues.apache.org/jira/browse/CASSANDRA-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Patterson resolved CASSANDRA-4036. Resolution: Cannot Reproduce I couldn't reproduce it either this time. cqlsh: EOF during multiline statement - Key: CASSANDRA-4036 URL: https://issues.apache.org/jira/browse/CASSANDRA-4036 Project: Cassandra Issue Type: Bug Reporter: Tyler Patterson Assignee: paul cannon Priority: Trivial Labels: cql, cqlsh press CTRL-d while at the beginning of a line in a multi-line statement. It should exit cqlsh or the multiline statement, but instead it only prints another.... -- 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-4626) Multiple values for CurrentLocal Node ID
[
https://issues.apache.org/jira/browse/CASSANDRA-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4626:
Attachment: 4626.txt
I think this can happen because of the commit log. Basically, it's possible
that when you restart a node that it doesn't pick the correct current NodeId if
he attempts to read the current NodeId before the commit log if fully replayed
(and the more recent NodeId is in the log, not yet replayed). This would then
lead to having 2 columns in the CurrentLocal row.
However, the main problem is that the way we maintain the CurrentLocal row is
fragile and honestly dumb (I wrote it so I'm blaming myself). We store all the
generated NodeId sorted by creation time in a separated row, so reading the
last column of that row is a much simpler and resilient way to do it. Attaching
a patch that does just that.
The patch also adds a forceFlush in SystemTable.writeCurrentNodeId to avoid the
problem of not reading the last NodeId because of log replay.
Multiple values for CurrentLocal Node ID
Key: CASSANDRA-4626
URL: https://issues.apache.org/jira/browse/CASSANDRA-4626
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.11
Reporter: Aaron Morton
Attachments: 4626.txt
From this email thread
http://www.mail-archive.com/user@cassandra.apache.org/msg24677.html
There are multiple columns for the CurrentLocal row in NodeIdInfo:
{noformat}
[default@system] list NodeIdInfo ;
Using default limit of 100
...
---
RowKey: 43757272656e744c6f63616c
= (column=01efa5d0-e133-11e1--51be601cd0ff, value=0a1020d2,
timestamp=1344414498989)
= (column=92109b80-ea0a-11e1--51be601cd0af, value=0a1020d2,
timestamp=1345386691897)
{noformat}
SystemTable.getCurrentLocalNodeId() throws an assertion that occurs when the
static constructor for o.a.c.utils.NodeId is in the stack.
The impact is a java.lang.NoClassDefFoundError when accessing a particular CF
(I assume on with counters) on a particular node.
Cannot see an obvious cause in the code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450687#comment-13450687 ] Jonathan Ellis commented on CASSANDRA-4480: --- I think we broke that, or maybe it never quite worked, because onJoin/onRemove were definitely intended to indicate membership changes. Checking 0.7 it's relatively straightforward that this is what is going on (we do blur things a bit by extending the join notification to generation changed indicating a restart as well). In 0.8 we refactored things to make it a lot less clear what's going on, at least in this respect. Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 beta 1 Attachments: 4480.txt, 4480-v2.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450689#comment-13450689 ] Brandon Williams commented on CASSANDRA-4480: - onAlive and onDead are basically relaying FD information, as in the node is known but has died or come back, whereas onJoin/onRestart indicate the node is new (but not necessarily a member) or rebooted (generation changed), which is where your problem is (but onJoin _and_ onRestart fire for that case.) onRemove means the node has left, by decom/removetoken/assassinate. But you'll want to ask tMD if the node is a member in any case, otherwise your events will fire for fat clients, like bootstrapping nodes that haven't fully joined yet. Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 beta 1 Attachments: 4480.txt, 4480-v2.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450696#comment-13450696 ] Jonathan Ellis commented on CASSANDRA-4480: --- bq. onJoin and onRestart fire for that case That's confusing, why wouldn't we want to fix that? (looks like onRestart was added in 0.8) Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 beta 1 Attachments: 4480.txt, 4480-v2.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4628) CQL/JDBC: date vs. timestamp issues
[ https://issues.apache.org/jira/browse/CASSANDRA-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450699#comment-13450699 ] Sylvain Lebresne commented on CASSANDRA-4628: - I guess it is true that JdbcDate could have been made to return java.sql.Types.TIMESTAMP rather than DATE for its getJdbcType method. CQL/JDBC: date vs. timestamp issues --- Key: CASSANDRA-4628 URL: https://issues.apache.org/jira/browse/CASSANDRA-4628 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.4 Reporter: Michael Krumpholz Priority: Critical Labels: cql, jdbc Cassandra's datatypes only have one Date/Time type named timestamp containing both date and time. Calling the validator org.apache.cassandra.db.marshal.DateType might be OK in general but can be confusing in the jdbc context where there is a distinction between date, time and timestamp. In terms of jdbc there should be more datatypes for dates and times or the jdbc driver should take one of the following options: - stick to timestamp - check if the date has a time part and distinguish by the data between date and timestamp automatically - use distinct datatypes according to the jdbc spec, the types would need to be in cassandra then too Now back to my actual problem: org.apache.cassandra.cql.jdbc.JdbcDate returns Types.DATE in getType(). Even if having inserted a complete date with time (making it a timestamp) the ResultSetMetaData.getColumnType() implementation still returns Types.DATE (source of this is in JdbcDate). If some other java code (where i don't have access to) uses the metadata to get the type and then getDate() to get the value the time is cut off the value and only the date is returned. But the ResultSet.getObject() implementation returns a complete java.util.Date including the time. -- 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-4626) Multiple values for CurrentLocal Node ID
[
https://issues.apache.org/jira/browse/CASSANDRA-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450701#comment-13450701
]
Jonathan Ellis commented on CASSANDRA-4626:
---
Maybe we should name the accessor methods CounterId instead of NodeId? NodeId
is confusingly similar to HostId.
Multiple values for CurrentLocal Node ID
Key: CASSANDRA-4626
URL: https://issues.apache.org/jira/browse/CASSANDRA-4626
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.11
Reporter: Aaron Morton
Fix For: 1.0.12
Attachments: 4626.txt
From this email thread
http://www.mail-archive.com/user@cassandra.apache.org/msg24677.html
There are multiple columns for the CurrentLocal row in NodeIdInfo:
{noformat}
[default@system] list NodeIdInfo ;
Using default limit of 100
...
---
RowKey: 43757272656e744c6f63616c
= (column=01efa5d0-e133-11e1--51be601cd0ff, value=0a1020d2,
timestamp=1344414498989)
= (column=92109b80-ea0a-11e1--51be601cd0af, value=0a1020d2,
timestamp=1345386691897)
{noformat}
SystemTable.getCurrentLocalNodeId() throws an assertion that occurs when the
static constructor for o.a.c.utils.NodeId is in the stack.
The impact is a java.lang.NoClassDefFoundError when accessing a particular CF
(I assume on with counters) on a particular node.
Cannot see an obvious cause in the code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CASSANDRA-4628) CQL/JDBC: date vs. timestamp issues
[ https://issues.apache.org/jira/browse/CASSANDRA-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reopened CASSANDRA-4628: --- Oops, I guess that is our code. CQL/JDBC: date vs. timestamp issues --- Key: CASSANDRA-4628 URL: https://issues.apache.org/jira/browse/CASSANDRA-4628 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.4 Reporter: Michael Krumpholz Priority: Critical Labels: cql, jdbc Cassandra's datatypes only have one Date/Time type named timestamp containing both date and time. Calling the validator org.apache.cassandra.db.marshal.DateType might be OK in general but can be confusing in the jdbc context where there is a distinction between date, time and timestamp. In terms of jdbc there should be more datatypes for dates and times or the jdbc driver should take one of the following options: - stick to timestamp - check if the date has a time part and distinguish by the data between date and timestamp automatically - use distinct datatypes according to the jdbc spec, the types would need to be in cassandra then too Now back to my actual problem: org.apache.cassandra.cql.jdbc.JdbcDate returns Types.DATE in getType(). Even if having inserted a complete date with time (making it a timestamp) the ResultSetMetaData.getColumnType() implementation still returns Types.DATE (source of this is in JdbcDate). If some other java code (where i don't have access to) uses the metadata to get the type and then getDate() to get the value the time is cut off the value and only the date is returned. But the ResultSet.getObject() implementation returns a complete java.util.Date including the time. -- 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: change JdbcDate to return Types.TIMESTAMP patch by Michael Krumpholz; reviewed by slebresne and jbellis for CASSANDRA-4628
Updated Branches:
refs/heads/trunk ceca1997d - e1201dff2
change JdbcDate to return Types.TIMESTAMP
patch by Michael Krumpholz; reviewed by slebresne and jbellis for CASSANDRA-4628
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e1201dff
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e1201dff
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e1201dff
Branch: refs/heads/trunk
Commit: e1201dff2c9c89ce2ff9a197ac5d99d9288c06e2
Parents: ceca199
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Sep 7 10:20:16 2012 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Sep 7 10:20:28 2012 -0500
--
.../org/apache/cassandra/cql/jdbc/JdbcDate.java|2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/e1201dff/src/java/org/apache/cassandra/cql/jdbc/JdbcDate.java
--
diff --git a/src/java/org/apache/cassandra/cql/jdbc/JdbcDate.java
b/src/java/org/apache/cassandra/cql/jdbc/JdbcDate.java
index 7d27bcb..912a37a 100644
--- a/src/java/org/apache/cassandra/cql/jdbc/JdbcDate.java
+++ b/src/java/org/apache/cassandra/cql/jdbc/JdbcDate.java
@@ -108,7 +108,7 @@ public class JdbcDate extends AbstractJdbcTypeDate
public int getJdbcType()
{
-return Types.DATE;
+return Types.TIMESTAMP;
}
public Date compose(ByteBuffer bytes)
[jira] [Updated] (CASSANDRA-4628) CQL/JDBC: date vs. timestamp issues
[ https://issues.apache.org/jira/browse/CASSANDRA-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4628: -- Priority: Minor (was: Critical) Affects Version/s: (was: 1.1.4) 0.8.0 Fix Version/s: 1.2.0 beta 1 CQL/JDBC: date vs. timestamp issues --- Key: CASSANDRA-4628 URL: https://issues.apache.org/jira/browse/CASSANDRA-4628 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 Reporter: Michael Krumpholz Priority: Minor Labels: cql, jdbc Fix For: 1.2.0 beta 1 Cassandra's datatypes only have one Date/Time type named timestamp containing both date and time. Calling the validator org.apache.cassandra.db.marshal.DateType might be OK in general but can be confusing in the jdbc context where there is a distinction between date, time and timestamp. In terms of jdbc there should be more datatypes for dates and times or the jdbc driver should take one of the following options: - stick to timestamp - check if the date has a time part and distinguish by the data between date and timestamp automatically - use distinct datatypes according to the jdbc spec, the types would need to be in cassandra then too Now back to my actual problem: org.apache.cassandra.cql.jdbc.JdbcDate returns Types.DATE in getType(). Even if having inserted a complete date with time (making it a timestamp) the ResultSetMetaData.getColumnType() implementation still returns Types.DATE (source of this is in JdbcDate). If some other java code (where i don't have access to) uses the metadata to get the type and then getDate() to get the value the time is cut off the value and only the date is returned. But the ResultSet.getObject() implementation returns a complete java.util.Date including the time. -- 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-4628) CQL/JDBC: date vs. timestamp issues
[ https://issues.apache.org/jira/browse/CASSANDRA-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4628. --- Resolution: Fixed Reviewer: jbellis Assignee: Michael Krumpholz fixed in e1201dff2c9c89ce2ff9a197ac5d99d9288c06e2 CQL/JDBC: date vs. timestamp issues --- Key: CASSANDRA-4628 URL: https://issues.apache.org/jira/browse/CASSANDRA-4628 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 Reporter: Michael Krumpholz Assignee: Michael Krumpholz Priority: Minor Labels: cql, jdbc Fix For: 1.2.0 beta 1 Cassandra's datatypes only have one Date/Time type named timestamp containing both date and time. Calling the validator org.apache.cassandra.db.marshal.DateType might be OK in general but can be confusing in the jdbc context where there is a distinction between date, time and timestamp. In terms of jdbc there should be more datatypes for dates and times or the jdbc driver should take one of the following options: - stick to timestamp - check if the date has a time part and distinguish by the data between date and timestamp automatically - use distinct datatypes according to the jdbc spec, the types would need to be in cassandra then too Now back to my actual problem: org.apache.cassandra.cql.jdbc.JdbcDate returns Types.DATE in getType(). Even if having inserted a complete date with time (making it a timestamp) the ResultSetMetaData.getColumnType() implementation still returns Types.DATE (source of this is in JdbcDate). If some other java code (where i don't have access to) uses the metadata to get the type and then getDate() to get the value the time is cut off the value and only the date is returned. But the ResultSet.getObject() implementation returns a complete java.util.Date including the time. -- 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-4631) minimum stack size for u34 and later is 180k
[ https://issues.apache.org/jira/browse/CASSANDRA-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4631: Attachment: 4631.txt Trivial patch. minimum stack size for u34 and later is 180k Key: CASSANDRA-4631 URL: https://issues.apache.org/jira/browse/CASSANDRA-4631 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor Fix For: 1.1.5 Attachments: 4631.txt We currently only set the stack to 180k for java 7, but it looks like java 6 u34 and later now need this too. Let's just set them all to 180k. -- 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-4628) CQL/JDBC: date vs. timestamp issues
[ https://issues.apache.org/jira/browse/CASSANDRA-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450719#comment-13450719 ] Michael Krumpholz commented on CASSANDRA-4628: -- yeah, as i wrote in the issue description, in the schema_columns table it is a DateType class, data type in the create statement is timestamp as it is and should be in the jdbc context. CQL/JDBC: date vs. timestamp issues --- Key: CASSANDRA-4628 URL: https://issues.apache.org/jira/browse/CASSANDRA-4628 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 Reporter: Michael Krumpholz Assignee: Michael Krumpholz Priority: Minor Labels: cql, jdbc Fix For: 1.2.0 beta 1 Cassandra's datatypes only have one Date/Time type named timestamp containing both date and time. Calling the validator org.apache.cassandra.db.marshal.DateType might be OK in general but can be confusing in the jdbc context where there is a distinction between date, time and timestamp. In terms of jdbc there should be more datatypes for dates and times or the jdbc driver should take one of the following options: - stick to timestamp - check if the date has a time part and distinguish by the data between date and timestamp automatically - use distinct datatypes according to the jdbc spec, the types would need to be in cassandra then too Now back to my actual problem: org.apache.cassandra.cql.jdbc.JdbcDate returns Types.DATE in getType(). Even if having inserted a complete date with time (making it a timestamp) the ResultSetMetaData.getColumnType() implementation still returns Types.DATE (source of this is in JdbcDate). If some other java code (where i don't have access to) uses the metadata to get the type and then getDate() to get the value the time is cut off the value and only the date is returned. But the ResultSet.getObject() implementation returns a complete java.util.Date including the time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4490) Improve IAuthority interface by introducing fine-grained access permissions and grant/revoke commands.
[ https://issues.apache.org/jira/browse/CASSANDRA-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450737#comment-13450737 ] Yuki Morishita commented on CASSANDRA-4490: --- Alright, then +1 on v2. Improve IAuthority interface by introducing fine-grained access permissions and grant/revoke commands. -- Key: CASSANDRA-4490 URL: https://issues.apache.org/jira/browse/CASSANDRA-4490 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1.6 Attachments: 4490-v3.txt, CASSANDRA-4490.patch, CASSANDRA-4490-v2.patch In order to improve IAuthority interface I propose to add the following new permissions: USE, SELECT, CREATE, ALTER, DROP, UPDATE, DELETE, ALL, NONE. And the following new commands to the CQL 3.0 which would give users possibility (with appropriate implementation) to dynamically change user's rights to access system objects: GRANT permission ON resource TO user [WITH GRANT OPTION]; REVOKE permission ON resource FROM user_name; LIST GRANTS FOR user; // Not 'SHOW' because it's reserved for cqlsh for commands like 'show cluster' where resource is Keyspace or ColumnFamily (initially, but extendable to indexes or configration options in the future), and permission is listed above. To keep the system backward compatible with old authorization interface implementations Permission class would include the mappings of the new to old permissions: READ - USE, SELECT WRITE - USE, CREATE, ALTER, DROP, UPDATE, DELETE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4631) minimum stack size for u34 and later is 180k
[ https://issues.apache.org/jira/browse/CASSANDRA-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450736#comment-13450736 ] Jonathan Ellis commented on CASSANDRA-4631: --- +1 minimum stack size for u34 and later is 180k Key: CASSANDRA-4631 URL: https://issues.apache.org/jira/browse/CASSANDRA-4631 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor Fix For: 1.1.5 Attachments: 4631.txt We currently only set the stack to 180k for java 7, but it looks like java 6 u34 and later now need this too. Let's just set them all to 180k. -- 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 cql error with ORDER BY when using IN patch by Pavel Yaskevich; reviewed by Sylvain Lebresne for CASSANDRA-4612
Updated Branches:
refs/heads/cassandra-1.1 7371e10be - 76e092b2d
Fix cql error with ORDER BY when using IN
patch by Pavel Yaskevich; reviewed by Sylvain Lebresne for CASSANDRA-4612
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/76e092b2
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/76e092b2
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/76e092b2
Branch: refs/heads/cassandra-1.1
Commit: 76e092b2d3785ac1549f1af16702839bee570c69
Parents: 7371e10
Author: Pavel Yaskevich xe...@apache.org
Authored: Thu Sep 6 18:11:05 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Fri Sep 7 18:59:46 2012 +0300
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/SelectStatement.java | 75 ++-
2 files changed, 53 insertions(+), 23 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/76e092b2/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f192be2..ed4f026 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -2,6 +2,7 @@
* (cql3) fix potential NPE with both equal and unequal restriction
(CASSANDRA-4532)
* (cql3) improves ORDER BY validation (CASSANDRA-4624)
* Fix potential deadlock during counter writes (CASSANDRA-4578)
+ * Fix cql error with ORDER BY when using IN (CASSANDRA-4612)
1.1.5
http://git-wip-us.apache.org/repos/asf/cassandra/blob/76e092b2/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 1d0918e..2f47f86 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -833,30 +833,38 @@ public class SelectStatement implements CQLStatement
if (parameters.orderings.size() == 1)
{
CFDefinition.Name ordering =
cfDef.get(parameters.orderings.keySet().iterator().next());
-Collections.sort(cqlRows, new
SingleColumnComparator(ordering.position + 1, ordering.type));
+Collections.sort(cqlRows, new
SingleColumnComparator(getColumnPositionInSelect(ordering), ordering.type));
return;
}
-// figures out where ordering would start in results (startPosition),
-// builds a composite type for multi-column comparison from the
comparators of the ordering components
+// builds a 'composite' type for multi-column comparison from the
comparators of the ordering components
// and passes collected position information and built composite
comparator to CompositeComparator to do
// an actual comparison of the CQL rows.
-int startPosition = -1;
-ListAbstractType? types = new ArrayListAbstractType?();
+ListAbstractType? types = new
ArrayListAbstractType?(parameters.orderings.size());
+int[] positions = new int[parameters.orderings.size()];
+int idx = 0;
for (ColumnIdentifier identifier : parameters.orderings.keySet())
{
CFDefinition.Name orderingColumn = cfDef.get(identifier);
-
-if (startPosition == -1)
-startPosition = orderingColumn.position + 1;
-
types.add(orderingColumn.type);
+positions[idx++] = getColumnPositionInSelect(orderingColumn);
}
-Collections.sort(cqlRows, new CompositeComparator(startPosition,
types));
+Collections.sort(cqlRows, new CompositeComparator(types, positions));
}
+// determine position of column in the select clause
+private int getColumnPositionInSelect(CFDefinition.Name columnName)
+{
+for (int i = 0; i selectedNames.size(); i++)
+{
+if (selectedNames.get(i).left.equals(columnName))
+return i;
+}
+
+throw new IllegalArgumentException(String.format(Column %s wasn't
found in select clause., columnName));
+}
/**
* For sparse composite, returns wheter two columns belong to the same
@@ -1073,6 +1081,28 @@ public class SelectStatement implements CQLStatement
if (stmt.isKeyRange())
throw new InvalidRequestException(ORDER BY is only
supported when the partition key is restricted by an EQ or an IN.);
+// check if we are trying to order by column that wouldn't be
included in the results
+if (!stmt.selectedNames.isEmpty()) // empty means wildcard was
used
+{
+for (ColumnIdentifier column :
git commit: Bump stack to 180k. Patch by brandonwilliams reviewed by jbellis for CASSANDRA-4631
Updated Branches: refs/heads/cassandra-1.1 76e092b2d - 567146e49 Bump stack to 180k. Patch by brandonwilliams reviewed by jbellis for CASSANDRA-4631 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/567146e4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/567146e4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/567146e4 Branch: refs/heads/cassandra-1.1 Commit: 567146e49201259f8c51dc7c84cbb8717e3c60c1 Parents: 76e092b Author: Brandon Williams brandonwilli...@apache.org Authored: Fri Sep 7 10:59:56 2012 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Fri Sep 7 11:01:59 2012 -0500 -- conf/cassandra-env.sh |8 ++-- 1 files changed, 2 insertions(+), 6 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/567146e4/conf/cassandra-env.sh -- diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh index 6fa37ed..95760dd 100644 --- a/conf/cassandra-env.sh +++ b/conf/cassandra-env.sh @@ -184,12 +184,8 @@ if [ `uname` = Linux ] ; then # thread-per-client. (Best practice is for client connections to # be pooled anyway.) Only do so on Linux where it is known to be # supported. -if startswith $JVM_VERSION '1.7.' -then -JVM_OPTS=$JVM_OPTS -Xss180k -else -JVM_OPTS=$JVM_OPTS -Xss160k -fi +# u34 and greater need 180k +JVM_OPTS=$JVM_OPTS -Xss180k fi echo xss = $JVM_OPTS
[1/3] git commit: Merge branch 'cassandra-1.0' into cassandra-1.1
Updated Branches: refs/heads/cassandra-1.0 08c654601 - d3917260b refs/heads/cassandra-1.1 567146e49 - 06893e4ff Merge branch 'cassandra-1.0' into cassandra-1.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/06893e4f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/06893e4f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/06893e4f Branch: refs/heads/cassandra-1.1 Commit: 06893e4ff4fe81161010e0e948af20b0bb587c4c Parents: 567146e d391726 Author: Brandon Williams brandonwilli...@apache.org Authored: Fri Sep 7 11:05:35 2012 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Fri Sep 7 11:05:35 2012 -0500 -- --
[2/3] git commit: Bump stack to 180k. Patch by brandonwilliams reviewed by jbellis for CASSANDRA-4631
Bump stack to 180k. Patch by brandonwilliams reviewed by jbellis for CASSANDRA-4631 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d3917260 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d3917260 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d3917260 Branch: refs/heads/cassandra-1.1 Commit: d3917260b97b5a76574823e9873a922e9333c5c8 Parents: 08c6546 Author: Brandon Williams brandonwilli...@apache.org Authored: Fri Sep 7 10:59:56 2012 -0500 Committer: Brandon Williams brandonwilli...@apache.org Committed: Fri Sep 7 11:05:08 2012 -0500 -- conf/cassandra-env.sh |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/d3917260/conf/cassandra-env.sh -- diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh index 5400fd9..7056668 100644 --- a/conf/cassandra-env.sh +++ b/conf/cassandra-env.sh @@ -150,7 +150,8 @@ if [ `uname` = Linux ] ; then # thread-per-client. (Best practice is for client connections to # be pooled anyway.) Only do so on Linux where it is known to be # supported. -JVM_OPTS=$JVM_OPTS -Xss160k +# u34 and greater need 180k +JVM_OPTS=$JVM_OPTS -Xss180k fi # GC tuning options
[jira] [Commented] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
[ https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450742#comment-13450742 ] Sylvain Lebresne commented on CASSANDRA-4495: - bq. why not just expose the AbstractType classes at that point? I though about that, but I think that at least currently that means pull pretty mull all of Cassandra (why the goal is to allow clients to pull just the minimum useful to them). Don't tie client side use of AbstractType to JDBC - Key: CASSANDRA-4495 URL: https://issues.apache.org/jira/browse/CASSANDRA-4495 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.3 We currently expose the AbstractType to java clients that want to reuse them though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL and will never be). Typically, there is a fair amount of the JDBC standard that cannot be implemented with C*, and there is a number of specificity of C* that are not in JDBC (typically the set and maps collections). So I propose to extract simple type classes with just a compose and decompose method (but without ties to jdbc, which would allow all the jdbc specific method those types have) in the purpose of exporting that in a separate jar for clients (we could put that in a org.apache.cassandra.type package for instance). We could then deprecate the jdbc classes with basically the same schedule than CQL2. Let me note that this is *not* saying there shouldn't be a JDBC driver for Cassandra. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: change ColumnSerializer.deserialize to be able fix timestamps from future, related to CASSANDRA-4561
Updated Branches:
refs/heads/cassandra-1.1 06893e4ff - 2c69e2ea7
change ColumnSerializer.deserialize to be able fix timestamps from future,
related to CASSANDRA-4561
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2c69e2ea
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2c69e2ea
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2c69e2ea
Branch: refs/heads/cassandra-1.1
Commit: 2c69e2ea757be9492a095aa22b5d51234c4b4102
Parents: 06893e4
Author: Pavel Yaskevich xe...@apache.org
Authored: Fri Sep 7 14:43:51 2012 +0300
Committer: Pavel Yaskevich xe...@apache.org
Committed: Fri Sep 7 19:07:31 2012 +0300
--
.../org/apache/cassandra/db/ColumnSerializer.java |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/2c69e2ea/src/java/org/apache/cassandra/db/ColumnSerializer.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnSerializer.java
b/src/java/org/apache/cassandra/db/ColumnSerializer.java
index cd7ba33..d5011aa 100644
--- a/src/java/org/apache/cassandra/db/ColumnSerializer.java
+++ b/src/java/org/apache/cassandra/db/ColumnSerializer.java
@@ -32,6 +32,7 @@ import org.slf4j.LoggerFactory;
import org.apache.cassandra.io.IColumnSerializer;
import org.apache.cassandra.io.util.FileDataInput;
import org.apache.cassandra.utils.ByteBufferUtil;
+import org.apache.cassandra.utils.FBUtilities;
public class ColumnSerializer implements IColumnSerializer
{
@@ -116,6 +117,11 @@ public class ColumnSerializer implements IColumnSerializer
else
{
long ts = dis.readLong();
+long now = FBUtilities.timestampMicros();
+
+if (ts now) // fixing the timestamp from the future to be 'now'
in micros
+ts = now; // helps with CASSANDRA-4561 as remote nodes can
send schema with wrong nanoTime() timestamps
+
ByteBuffer value = ByteBufferUtil.readWithLength(dis);
return (b COUNTER_UPDATE_MASK) != 0
? new CounterUpdateColumn(name, value, ts)
[jira] [Updated] (CASSANDRA-4624) ORDER BY validation is not restrictive enough
[ https://issues.apache.org/jira/browse/CASSANDRA-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4624: Fix Version/s: (was: 1.1.6) 1.1.5 ORDER BY validation is not restrictive enough - Key: CASSANDRA-4624 URL: https://issues.apache.org/jira/browse/CASSANDRA-4624 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.3 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Fix For: 1.1.5, 1.2.0 beta 1 Attachments: 4624.txt We're not able to do order by on anything that is a key range. However, we only refuse queries that have an empty where clause, but that doesn't exclude all key ranges at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4578) Dead lock in mutation stage when many concurrent writes to few columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4578:
Fix Version/s: (was: 1.1.6)
1.1.5
Dead lock in mutation stage when many concurrent writes to few columns
--
Key: CASSANDRA-4578
URL: https://issues.apache.org/jira/browse/CASSANDRA-4578
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.0
Environment: 15 cassandra instances
CentOS5
8 Core 64GB Memory
java version 1.6.0_33
Java(TM) SE Runtime Environment (build 1.6.0_33-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode)
Reporter: Suguru Namura
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.1.5
Attachments: 4578.txt, threaddump-1344957574788.tdump
When I send many request to increment counters to few counter columns,
sometimes mutation stage cause dead lock. When it happened, all of mutation
threads are locked and do not accept updates any more.
{noformat}
MutationStage:432 - Thread t@1389
java.lang.Thread.State: TIMED_WAITING
at java.lang.Object.wait(Native Method)
- waiting on b90b45b (a org.apache.cassandra.utils.SimpleCondition)
at java.lang.Object.wait(Object.java:443)
at java.util.concurrent.TimeUnit.timedWait(TimeUnit.java:292)
at
org.apache.cassandra.utils.SimpleCondition.await(SimpleCondition.java:54)
at
org.apache.cassandra.service.AbstractWriteResponseHandler.get(AbstractWriteResponseHandler.java:55)
at
org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:51)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- locked 4b1b0a6f (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4632) Increase default max_hint_window_in_ms to 3h
Jonathan Ellis created CASSANDRA-4632: - Summary: Increase default max_hint_window_in_ms to 3h Key: CASSANDRA-4632 URL: https://issues.apache.org/jira/browse/CASSANDRA-4632 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Trivial Fix For: 1.2.0 beta 1 It's clear at this point that CASSANDRA-2045 greatly reduced the impact of storing hints for a dead node. Let's increase the default window to make full AES repair that much less necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-4542: - Attachment: (was: CASSANDRA-4542-4543-4544-v2.patch) add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 Attachments: CASSANDRA-4542-4543-4544-v3.patch atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4632) Increase default max_hint_window_in_ms to 3h
[ https://issues.apache.org/jira/browse/CASSANDRA-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4632: -- Attachment: 4632.txt trivial patch is trivial Increase default max_hint_window_in_ms to 3h Key: CASSANDRA-4632 URL: https://issues.apache.org/jira/browse/CASSANDRA-4632 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Trivial Fix For: 1.2.0 beta 1 Attachments: 4632.txt It's clear at this point that CASSANDRA-2045 greatly reduced the impact of storing hints for a dead node. Let's increase the default window to make full AES repair that much less necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-4542: - Attachment: CASSANDRA-4542-4543-4544-v3.patch add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 Attachments: CASSANDRA-4542-4543-4544-v3.patch atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4632) Increase default max_hint_window_in_ms to 3h
[ https://issues.apache.org/jira/browse/CASSANDRA-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450758#comment-13450758 ] Brandon Williams commented on CASSANDRA-4632: - +1 Increase default max_hint_window_in_ms to 3h Key: CASSANDRA-4632 URL: https://issues.apache.org/jira/browse/CASSANDRA-4632 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Trivial Fix For: 1.2.0 beta 1 Attachments: 4632.txt It's clear at this point that CASSANDRA-2045 greatly reduced the impact of storing hints for a dead node. Let's increase the default window to make full AES repair that much less necessary. -- 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: Increase default max_hint_window_in_ms to 3h patch by jbellis; reviewed by brandonwilliams for CASSANDRA-4632
Updated Branches: refs/heads/trunk e1201dff2 - 2b6c625e4 Increase default max_hint_window_in_ms to 3h patch by jbellis; reviewed by brandonwilliams for CASSANDRA-4632 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2b6c625e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2b6c625e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2b6c625e Branch: refs/heads/trunk Commit: 2b6c625e4ed307002ca4e0b4e92194c031f7863c Parents: e1201df Author: Jonathan Ellis jbel...@apache.org Authored: Fri Sep 7 11:22:35 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Fri Sep 7 11:22:35 2012 -0500 -- CHANGES.txt |1 + conf/cassandra.yaml |2 +- 2 files changed, 2 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/2b6c625e/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 8245343..1aa27e1 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.2-beta1 + * increase default max_hint_window_in_ms to 3h (CASSANDRA-4632) * include message initiation time to replicas so they can more accurately drop timed-out requests (CASSANDRA-2858) * fix clientutil.jar dependencies (CASSANDRA-4566) http://git-wip-us.apache.org/repos/asf/cassandra/blob/2b6c625e/conf/cassandra.yaml -- diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml index 40d7ff8..058cd81 100644 --- a/conf/cassandra.yaml +++ b/conf/cassandra.yaml @@ -40,7 +40,7 @@ initial_token: hinted_handoff_enabled: true # this defines the maximum amount of time a dead host will have hints # generated. After it has been dead this long, hints will be dropped. -max_hint_window_in_ms: 360 # one hour +max_hint_window_in_ms: 1080 # 3 hours # throttle in KB's per second, per delivery thread hinted_handoff_throttle_in_kb: 1024 # Number of threads with which to deliver hints;
[jira] [Resolved] (CASSANDRA-4632) Increase default max_hint_window_in_ms to 3h
[ https://issues.apache.org/jira/browse/CASSANDRA-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4632. --- Resolution: Fixed committed Increase default max_hint_window_in_ms to 3h Key: CASSANDRA-4632 URL: https://issues.apache.org/jira/browse/CASSANDRA-4632 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Trivial Fix For: 1.2.0 beta 1 Attachments: 4632.txt It's clear at this point that CASSANDRA-2045 greatly reduced the impact of storing hints for a dead node. Let's increase the default window to make full AES repair that much less necessary. -- 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 changelog
Updated Branches:
refs/heads/cassandra-1.1 2c69e2ea7 - a1c8dad81
Fix changelog
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a1c8dad8
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a1c8dad8
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a1c8dad8
Branch: refs/heads/cassandra-1.1
Commit: a1c8dad819ea4f17cf76106fa39dfb3ae60dd797
Parents: 2c69e2e
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Fri Sep 7 18:27:31 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Fri Sep 7 18:27:31 2012 +0200
--
CHANGES.txt | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a1c8dad8/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ed4f026..54a74d4 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,10 +1,3 @@
-1.1.6
- * (cql3) fix potential NPE with both equal and unequal restriction
(CASSANDRA-4532)
- * (cql3) improves ORDER BY validation (CASSANDRA-4624)
- * Fix potential deadlock during counter writes (CASSANDRA-4578)
- * Fix cql error with ORDER BY when using IN (CASSANDRA-4612)
-
-
1.1.5
* add SecondaryIndex.reload API (CASSANDRA-4581)
* use millis + atomicint for commitlog segment creation instead of
@@ -21,6 +14,10 @@
* Respect five-minute flush moratorium after initial CL replay
(CASSANDRA-4474)
* Adds ntp as recommended in debian packaging (CASSANDRA-4606)
* Configurable transport in CF Record{Reader|Writer} (CASSANDRA-4558)
+ * (cql3) fix potential NPE with both equal and unequal restriction
(CASSANDRA-4532)
+ * (cql3) improves ORDER BY validation (CASSANDRA-4624)
+ * Fix potential deadlock during counter writes (CASSANDRA-4578)
+ * Fix cql error with ORDER BY when using IN (CASSANDRA-4612)
Merged from 1.0:
* increase Xss to 160k to accomodate latest 1.6 JVMs (CASSANDRA-4602)
* fix toString of hint destination tokens (CASSANDRA-4568)
[jira] [Commented] (CASSANDRA-4626) Multiple values for CurrentLocal Node ID
[
https://issues.apache.org/jira/browse/CASSANDRA-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450763#comment-13450763
]
Sylvain Lebresne commented on CASSANDRA-4626:
-
bq. Maybe we should name the accessor methods CounterId instead of NodeId?
That's a good idea, I'll do that.
Multiple values for CurrentLocal Node ID
Key: CASSANDRA-4626
URL: https://issues.apache.org/jira/browse/CASSANDRA-4626
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.11
Reporter: Aaron Morton
Fix For: 1.0.12
Attachments: 4626.txt
From this email thread
http://www.mail-archive.com/user@cassandra.apache.org/msg24677.html
There are multiple columns for the CurrentLocal row in NodeIdInfo:
{noformat}
[default@system] list NodeIdInfo ;
Using default limit of 100
...
---
RowKey: 43757272656e744c6f63616c
= (column=01efa5d0-e133-11e1--51be601cd0ff, value=0a1020d2,
timestamp=1344414498989)
= (column=92109b80-ea0a-11e1--51be601cd0af, value=0a1020d2,
timestamp=1345386691897)
{noformat}
SystemTable.getCurrentLocalNodeId() throws an assertion that occurs when the
static constructor for o.a.c.utils.NodeId is in the stack.
The impact is a java.lang.NoClassDefFoundError when accessing a particular CF
(I assume on with counters) on a particular node.
Cannot see an obvious cause in the code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Multiple values for CurrentLocal Node ID
Updated Branches:
refs/heads/cassandra-1.0 d3917260b - 19800189d
Multiple values for CurrentLocal Node ID
patch by slebresne; reviewed by jbellis for CASSANDRA-4626
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/19800189
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/19800189
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/19800189
Branch: refs/heads/cassandra-1.0
Commit: 19800189d76453cf08af60e21a544729565714ba
Parents: d391726
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Fri Sep 7 16:14:58 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Fri Sep 7 18:32:31 2012 +0200
--
CHANGES.txt |1 +
src/java/org/apache/cassandra/db/SystemTable.java | 44 +--
2 files changed, 16 insertions(+), 29 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/19800189/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 8a0ce59..6157022 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -4,6 +4,7 @@
* (Hadoop) fix setting key length for old-style mapred api (CASSANDRA-4534)
* (Hadoop) fix iterating through a resultset consisting entirely
of tombstoned rows (CASSANDRA-4466)
+ * Fix multiple values for CurrentLocal NodeID (CASSANDRA-4626)
1.0.11
http://git-wip-us.apache.org/repos/asf/cassandra/blob/19800189/src/java/org/apache/cassandra/db/SystemTable.java
--
diff --git a/src/java/org/apache/cassandra/db/SystemTable.java
b/src/java/org/apache/cassandra/db/SystemTable.java
index 628719b..7b96c6f 100644
--- a/src/java/org/apache/cassandra/db/SystemTable.java
+++ b/src/java/org/apache/cassandra/db/SystemTable.java
@@ -430,25 +430,19 @@ public class SystemTable
{
ByteBuffer id = null;
Table table = Table.open(Table.SYSTEM_TABLE);
-QueryFilter filter =
QueryFilter.getIdentityFilter(decorate(CURRENT_LOCAL_NODE_ID_KEY),
-new QueryPath(NODE_ID_CF));
+
+// Get the last NodeId (since NodeId are timeuuid is thus ordered from
the older to the newer one)
+QueryFilter filter =
QueryFilter.getSliceFilter(decorate(ALL_LOCAL_NODE_ID_KEY),
+new
QueryPath(NODE_ID_CF),
+
ByteBufferUtil.EMPTY_BYTE_BUFFER,
+
ByteBufferUtil.EMPTY_BYTE_BUFFER,
+true,
+1);
ColumnFamily cf =
table.getColumnFamilyStore(NODE_ID_CF).getColumnFamily(filter);
-if (cf != null)
-{
-// Even though gc_grace==0 on System table, we can have a race
where we get back tombstones (see CASSANDRA-2824)
-cf = ColumnFamilyStore.removeDeleted(cf, 0);
-assert cf.getColumnCount() = 1;
-if (cf.getColumnCount() 0)
-id = cf.iterator().next().name();
-}
-if (id != null)
-{
-return NodeId.wrap(id);
-}
+if (cf != null cf.getColumnCount() != 0)
+return NodeId.wrap(cf.iterator().next().name());
else
-{
return null;
-}
}
/**
@@ -465,24 +459,17 @@ public class SystemTable
ColumnFamily cf = ColumnFamily.create(Table.SYSTEM_TABLE, NODE_ID_CF);
cf.addColumn(new Column(newNodeId.bytes(), ip, now));
-ColumnFamily cf2 = cf.cloneMe();
-if (oldNodeId != null)
-{
-cf2.addColumn(new DeletedColumn(oldNodeId.bytes(), (int) (now /
1000), now));
-}
-RowMutation rmCurrent = new RowMutation(Table.SYSTEM_TABLE,
CURRENT_LOCAL_NODE_ID_KEY);
-RowMutation rmAll = new RowMutation(Table.SYSTEM_TABLE,
ALL_LOCAL_NODE_ID_KEY);
-rmCurrent.add(cf2);
-rmAll.add(cf);
+RowMutation rm = new RowMutation(Table.SYSTEM_TABLE,
ALL_LOCAL_NODE_ID_KEY);
+rm.add(cf);
try
{
-rmCurrent.apply();
-rmAll.apply();
+rm.apply();
}
catch (IOException e)
{
throw new RuntimeException(e);
}
+forceBlockingFlush(NODE_ID_CF);
}
public static ListNodeId.NodeIdRecord getOldLocalNodeIds()
@@ -490,8 +477,7 @@ public class SystemTable
ListNodeId.NodeIdRecord l = new ArrayListNodeId.NodeIdRecord();
Table table = Table.open(Table.SYSTEM_TABLE);
-QueryFilter filter =
QueryFilter.getIdentityFilter(decorate(ALL_LOCAL_NODE_ID_KEY),
-new
[jira] [Comment Edited] (CASSANDRA-4417) invalid counter shard detected
[ https://issues.apache.org/jira/browse/CASSANDRA-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450766#comment-13450766 ] Charles Brophy edited comment on CASSANDRA-4417 at 9/8/12 3:35 AM: --- We have a six node cluster with even key range balance, random partitioner, and with replication factor=2. I get these errors immediately following running nodetool repair but ONLY if a streaming repair happens as a result. We are serving live updates to our counters from our clickstream. My guess is that the sstable being streamed between the servers winds up becoming out of date for the duration of the streaming process and ends up containing these duplicates that are vetted during the subsequent compaction. In any case, for us it is 100% reproducible via: nodetool repair - streaming repair - subsequent compaction. Let me know if you need more details. Hope this helps! was (Author: charlesb_zulily): We have a six node cluster with even key range balance, random partitioner, and with relication factor=2. I get these errors immediately following running nodetool repair but ONLY if a streaming repair happens as a result. We are serving live updates to our counters from our clickstream. My guess is that the sstable being streamed between the servers winds up becoming out of date for the duration of the streaming process and ends up containing these duplicates that are vetted during the subsequent compaction. In any case, for us it is 100% reproducible via: nodetool repair - streaming repair - subsequent compaction. Let me know if you need more details. Hope this helps! invalid counter shard detected --- Key: CASSANDRA-4417 URL: https://issues.apache.org/jira/browse/CASSANDRA-4417 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1 Environment: Amazon Linux Reporter: Senthilvel Rangaswamy Seeing errors like these: 2012-07-06_07:00:27.22662 ERROR 07:00:27,226 invalid counter shard detected; (17bfd850-ac52-11e1--6ecd0b5b61e7, 1, 13) and (17bfd850-ac52-11e1--6ecd0b5b61e7, 1, 1) differ only in count; will pick highest to self-heal; this indicates a bug or corruption generated a bad counter shard What does it mean ? -- 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-4417) invalid counter shard detected
[ https://issues.apache.org/jira/browse/CASSANDRA-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450766#comment-13450766 ] Charles Brophy commented on CASSANDRA-4417: --- We have a six node cluster with even key range balance, random partitioner, and with relication factor=2. I get these errors immediately following running nodetool repair but ONLY if a streaming repair happens as a result. We are serving live updates to our counters from our clickstream. My guess is that the sstable being streamed between the servers winds up becoming out of date for the duration of the streaming process and ends up containing these duplicates that are vetted during the subsequent compaction. In any case, for us it is 100% reproducible via: nodetool repair - streaming repair - subsequent compaction. Let me know if you need more details. Hope this helps! invalid counter shard detected --- Key: CASSANDRA-4417 URL: https://issues.apache.org/jira/browse/CASSANDRA-4417 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1 Environment: Amazon Linux Reporter: Senthilvel Rangaswamy Seeing errors like these: 2012-07-06_07:00:27.22662 ERROR 07:00:27,226 invalid counter shard detected; (17bfd850-ac52-11e1--6ecd0b5b61e7, 1, 13) and (17bfd850-ac52-11e1--6ecd0b5b61e7, 1, 1) differ only in count; will pick highest to self-heal; this indicates a bug or corruption generated a bad counter shard What does it mean ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-4542: - Attachment: (was: CASSANDRA-4542-4543-4544-v3.patch) add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-4542: - Attachment: CASSANDRA-4542-4543-4544-v3.patch add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 Attachments: CASSANDRA-4542-4543-4544-v3.patch atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4417) invalid counter shard detected
[ https://issues.apache.org/jira/browse/CASSANDRA-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450766#comment-13450766 ] Charles Brophy edited comment on CASSANDRA-4417 at 9/8/12 3:39 AM: --- We have a six node cluster [1.1.3, jdk 1.6.33, CentOs 6] with even key range balance, random partitioner, and with replication factor=2. I get these errors immediately following running nodetool repair but ONLY if a streaming repair happens as a result. We are serving live updates to our counters from our clickstream. My guess is that the sstable being streamed between the servers winds up becoming out of date for the duration of the streaming process and ends up containing these duplicates that are vetted during the subsequent compaction. In any case, for us it is 100% reproducible via: nodetool repair - streaming repair - subsequent compaction. Let me know if you need more details. Hope this helps! was (Author: charlesb_zulily): We have a six node cluster with even key range balance, random partitioner, and with replication factor=2. I get these errors immediately following running nodetool repair but ONLY if a streaming repair happens as a result. We are serving live updates to our counters from our clickstream. My guess is that the sstable being streamed between the servers winds up becoming out of date for the duration of the streaming process and ends up containing these duplicates that are vetted during the subsequent compaction. In any case, for us it is 100% reproducible via: nodetool repair - streaming repair - subsequent compaction. Let me know if you need more details. Hope this helps! invalid counter shard detected --- Key: CASSANDRA-4417 URL: https://issues.apache.org/jira/browse/CASSANDRA-4417 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1 Environment: Amazon Linux Reporter: Senthilvel Rangaswamy Seeing errors like these: 2012-07-06_07:00:27.22662 ERROR 07:00:27,226 invalid counter shard detected; (17bfd850-ac52-11e1--6ecd0b5b61e7, 1, 13) and (17bfd850-ac52-11e1--6ecd0b5b61e7, 1, 1) differ only in count; will pick highest to self-heal; this indicates a bug or corruption generated a bad counter shard What does it mean ? -- 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/2] git commit: Merge branch 'cassandra-1.0' into cassandra-1.1
Updated Branches:
refs/heads/cassandra-1.1 a1c8dad81 - dafa548fd
Merge branch 'cassandra-1.0' into cassandra-1.1
Conflicts:
CHANGES.txt
src/java/org/apache/cassandra/db/SystemTable.java
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/dafa548f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/dafa548f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/dafa548f
Branch: refs/heads/cassandra-1.1
Commit: dafa548fdb677edb0abd8533c686dd0001e0b35a
Parents: a1c8dad 1980018
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Fri Sep 7 18:37:30 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Fri Sep 7 18:37:30 2012 +0200
--
CHANGES.txt |3 +
src/java/org/apache/cassandra/db/SystemTable.java | 46 +---
2 files changed, 18 insertions(+), 31 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/dafa548f/CHANGES.txt
--
diff --cc CHANGES.txt
index 54a74d4,6157022..61cede4
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,186 -1,15 +1,189 @@@
-1.0.12
+1.1.5
+ * add SecondaryIndex.reload API (CASSANDRA-4581)
+ * use millis + atomicint for commitlog segment creation instead of
+ nanotime, which has issues under some hypervisors (CASSANDRA-4601)
+ * fix FD leak in slice queries (CASSANDRA-4571)
+ * avoid recursion in leveled compaction (CASSANDRA-4587)
+ * increase stack size under Java7 to 180K
+ * Log(info) schema changes (CASSANDRA-4547)
+ * Change nodetool setcachecapcity to manipulate global caches
(CASSANDRA-4563)
+ * (cql3) fix setting compaction strategy (CASSANDRA-4597)
+ * fix broken system.schema_* timestamps on system startup (CASSANDRA-4561)
+ * fix wrong skip of cache saving (CASSANDRA-4533)
+ * Avoid NPE when lost+found is in data dir (CASSANDRA-4572)
+ * Respect five-minute flush moratorium after initial CL replay
(CASSANDRA-4474)
+ * Adds ntp as recommended in debian packaging (CASSANDRA-4606)
+ * Configurable transport in CF Record{Reader|Writer} (CASSANDRA-4558)
+ * (cql3) fix potential NPE with both equal and unequal restriction
(CASSANDRA-4532)
+ * (cql3) improves ORDER BY validation (CASSANDRA-4624)
+ * Fix potential deadlock during counter writes (CASSANDRA-4578)
+ * Fix cql error with ORDER BY when using IN (CASSANDRA-4612)
+Merged from 1.0:
* increase Xss to 160k to accomodate latest 1.6 JVMs (CASSANDRA-4602)
* fix toString of hint destination tokens (CASSANDRA-4568)
++ * Fix multiple values for CurrentLocal NodeID (CASSANDRA-4626)
+
+
+1.1.4
+ * fix offline scrub to catch = out of order rows (CASSANDRA-4411)
+ * fix cassandra-env.sh on RHEL and other non-dash-based systems
+ (CASSANDRA-4494)
+Merged from 1.0:
* (Hadoop) fix setting key length for old-style mapred api (CASSANDRA-4534)
+ * (Hadoop) fix iterating through a resultset consisting entirely
+of tombstoned rows (CASSANDRA-4466)
- * Fix multiple values for CurrentLocal NodeID (CASSANDRA-4626)
-1.0.11
+1.1.3
+ * munmap commitlog segments before rename (CASSANDRA-4337)
+ * (JMX) rename getRangeKeySample to sampleKeyRange to avoid returning
+ multi-MB results as an attribute (CASSANDRA-4452)
+ * flush based on data size, not throughput; overwritten columns no
+ longer artificially inflate liveRatio (CASSANDRA-4399)
+ * update default commitlog segment size to 32MB and total commitlog
+ size to 32/1024 MB for 32/64 bit JVMs, respectively (CASSANDRA-4422)
+ * avoid using global partitioner to estimate ranges in index sstables
+ (CASSANDRA-4403)
+ * restore pre-CASSANDRA-3862 approach to removing expired tombstones
+ from row cache during compaction (CASSANDRA-4364)
+ * (stress) support for CQL prepared statements (CASSANDRA-3633)
+ * Correctly catch exception when Snappy cannot be loaded (CASSANDRA-4400)
+ * (cql3) Support ORDER BY when IN condition is given in WHERE clause
(CASSANDRA-4327)
+ * (cql3) delete component_index column on DROP TABLE call (CASSANDRA-4420)
+ * change nanoTime() to currentTimeInMillis() in schema related code
(CASSANDRA-4432)
+ * add a token generation tool (CASSANDRA-3709)
+ * Fix LCS bug with sstable containing only 1 row (CASSANDRA-4411)
+ * fix Can't Modify Index Name problem on CF update (CASSANDRA-4439)
+ * Fix assertion error in getOverlappingSSTables during repair
(CASSANDRA-4456)
+ * fix nodetool's setcompactionthreshold command (CASSANDRA-4455)
+ * Ensure compacted files are never used, to avoid counter overcount
(CASSANDRA-4436)
+Merged from 1.0:
+ * Push the validation of secondary index values to the SecondaryIndexManager
(CASSANDRA-4240)
+ * (Hadoop) fix iterating through a resultset consisting
[2/2] git commit: Multiple values for CurrentLocal Node ID
Multiple values for CurrentLocal Node ID
patch by slebresne; reviewed by jbellis for CASSANDRA-4626
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/19800189
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/19800189
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/19800189
Branch: refs/heads/cassandra-1.1
Commit: 19800189d76453cf08af60e21a544729565714ba
Parents: d391726
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Fri Sep 7 16:14:58 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Fri Sep 7 18:32:31 2012 +0200
--
CHANGES.txt |1 +
src/java/org/apache/cassandra/db/SystemTable.java | 44 +--
2 files changed, 16 insertions(+), 29 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/19800189/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 8a0ce59..6157022 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -4,6 +4,7 @@
* (Hadoop) fix setting key length for old-style mapred api (CASSANDRA-4534)
* (Hadoop) fix iterating through a resultset consisting entirely
of tombstoned rows (CASSANDRA-4466)
+ * Fix multiple values for CurrentLocal NodeID (CASSANDRA-4626)
1.0.11
http://git-wip-us.apache.org/repos/asf/cassandra/blob/19800189/src/java/org/apache/cassandra/db/SystemTable.java
--
diff --git a/src/java/org/apache/cassandra/db/SystemTable.java
b/src/java/org/apache/cassandra/db/SystemTable.java
index 628719b..7b96c6f 100644
--- a/src/java/org/apache/cassandra/db/SystemTable.java
+++ b/src/java/org/apache/cassandra/db/SystemTable.java
@@ -430,25 +430,19 @@ public class SystemTable
{
ByteBuffer id = null;
Table table = Table.open(Table.SYSTEM_TABLE);
-QueryFilter filter =
QueryFilter.getIdentityFilter(decorate(CURRENT_LOCAL_NODE_ID_KEY),
-new QueryPath(NODE_ID_CF));
+
+// Get the last NodeId (since NodeId are timeuuid is thus ordered from
the older to the newer one)
+QueryFilter filter =
QueryFilter.getSliceFilter(decorate(ALL_LOCAL_NODE_ID_KEY),
+new
QueryPath(NODE_ID_CF),
+
ByteBufferUtil.EMPTY_BYTE_BUFFER,
+
ByteBufferUtil.EMPTY_BYTE_BUFFER,
+true,
+1);
ColumnFamily cf =
table.getColumnFamilyStore(NODE_ID_CF).getColumnFamily(filter);
-if (cf != null)
-{
-// Even though gc_grace==0 on System table, we can have a race
where we get back tombstones (see CASSANDRA-2824)
-cf = ColumnFamilyStore.removeDeleted(cf, 0);
-assert cf.getColumnCount() = 1;
-if (cf.getColumnCount() 0)
-id = cf.iterator().next().name();
-}
-if (id != null)
-{
-return NodeId.wrap(id);
-}
+if (cf != null cf.getColumnCount() != 0)
+return NodeId.wrap(cf.iterator().next().name());
else
-{
return null;
-}
}
/**
@@ -465,24 +459,17 @@ public class SystemTable
ColumnFamily cf = ColumnFamily.create(Table.SYSTEM_TABLE, NODE_ID_CF);
cf.addColumn(new Column(newNodeId.bytes(), ip, now));
-ColumnFamily cf2 = cf.cloneMe();
-if (oldNodeId != null)
-{
-cf2.addColumn(new DeletedColumn(oldNodeId.bytes(), (int) (now /
1000), now));
-}
-RowMutation rmCurrent = new RowMutation(Table.SYSTEM_TABLE,
CURRENT_LOCAL_NODE_ID_KEY);
-RowMutation rmAll = new RowMutation(Table.SYSTEM_TABLE,
ALL_LOCAL_NODE_ID_KEY);
-rmCurrent.add(cf2);
-rmAll.add(cf);
+RowMutation rm = new RowMutation(Table.SYSTEM_TABLE,
ALL_LOCAL_NODE_ID_KEY);
+rm.add(cf);
try
{
-rmCurrent.apply();
-rmAll.apply();
+rm.apply();
}
catch (IOException e)
{
throw new RuntimeException(e);
}
+forceBlockingFlush(NODE_ID_CF);
}
public static ListNodeId.NodeIdRecord getOldLocalNodeIds()
@@ -490,8 +477,7 @@ public class SystemTable
ListNodeId.NodeIdRecord l = new ArrayListNodeId.NodeIdRecord();
Table table = Table.open(Table.SYSTEM_TABLE);
-QueryFilter filter =
QueryFilter.getIdentityFilter(decorate(ALL_LOCAL_NODE_ID_KEY),
-new QueryPath(NODE_ID_CF));
+QueryFilter filter =
Git Push Summary
Updated Tags: refs/tags/1.1.5-tentative [deleted] acaa52465
[jira] [Commented] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
[
https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450782#comment-13450782
]
Rick Shaw commented on CASSANDRA-4495:
--
I would suggest adding {{getString(ByteBuffer bytes)}} and {{getType()}} as
well. The JDBC specific stuff like {{isCurrency()}} and {{isSigned()}} are of
course easily moved over to client side.
Don't tie client side use of AbstractType to JDBC
-
Key: CASSANDRA-4495
URL: https://issues.apache.org/jira/browse/CASSANDRA-4495
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.3
We currently expose the AbstractType to java clients that want to reuse them
though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC
standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL
and will never be). Typically, there is a fair amount of the JDBC standard
that cannot be implemented with C*, and there is a number of specificity of
C* that are not in JDBC (typically the set and maps collections).
So I propose to extract simple type classes with just a compose and decompose
method (but without ties to jdbc, which would allow all the jdbc specific
method those types have) in the purpose of exporting that in a separate jar
for clients (we could put that in a org.apache.cassandra.type package for
instance). We could then deprecate the jdbc classes with basically the same
schedule than CQL2.
Let me note that this is *not* saying there shouldn't be a JDBC driver for
Cassandra.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: explain how to work around exec problems in error message patch by jbellis for CASSANDRA-4590
Updated Branches:
refs/heads/cassandra-1.1 dafa548fd - e39530789
explain how to work around exec problems in error message
patch by jbellis for CASSANDRA-4590
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e3953078
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e3953078
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e3953078
Branch: refs/heads/cassandra-1.1
Commit: e395307893d93a01e976656f6e0f5cee1acf3c3b
Parents: dafa548
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Sep 7 11:57:19 2012 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Fri Sep 7 11:58:03 2012 -0500
--
src/java/org/apache/cassandra/utils/CLibrary.java |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/e3953078/src/java/org/apache/cassandra/utils/CLibrary.java
--
diff --git a/src/java/org/apache/cassandra/utils/CLibrary.java
b/src/java/org/apache/cassandra/utils/CLibrary.java
index bcb5bfa..97015a7 100644
--- a/src/java/org/apache/cassandra/utils/CLibrary.java
+++ b/src/java/org/apache/cassandra/utils/CLibrary.java
@@ -189,7 +189,10 @@ public final class CLibrary
}
catch (IOException ex)
{
-logger.error(Unable to create hard link, ex);
+String st = osname.startsWith(Windows)
+ ? Unable to create hard link. This probably means your
data directory path is too long. Exception follows:
+ : Unable to create hard link with exec. Suggest
installing JNA to avoid the need to exec entirely. Exception follows: ;
+logger.error(st, ex);
throw ex;
}
}
[jira] [Resolved] (CASSANDRA-4590) The system cannot find the path specified when creating hard link on Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-4590.
---
Resolution: Fixed
Fix Version/s: 1.1.5
Assignee: Jonathan Ellis
Updated error message as follows:
{code}
String st = osname.startsWith(Windows)
? Unable to create hard link. This probably means your
data directory path is too long. Exception follows:
: Unable to create hard link with exec. Suggest
installing JNA to avoid the need to exec entirely. Exception follows: ;
logger.error(st, ex);
{code}
The system cannot find the path specified when creating hard link on Windows
--
Key: CASSANDRA-4590
URL: https://issues.apache.org/jira/browse/CASSANDRA-4590
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Environment: Windows 7 - 64 bit
Reporter: Allen Servedio
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 1.1.5
When upgrading from Cassandra 1.0.5 to 1.1.3, we have a test case (uses
embedded Cassandra) that started failing as shown below. Other than the
upgrade, no changes were made to the code or config. I believe this MAY be
related to the change made in CASSANDRA-3101.
We verified that the file it is trying to create the hard link to does exist
- so it is purely the creation of the link that is failing.
Here is the basic failure:
# [11:31:00.307] [ERROR] [o.a.c.u.CLibrary] [createHardLinkWithExec] [Unable
to create hard link]
java.io.IOException: Exception while executing the command: cmd /c mklink /H
C:\XYZ\source_code\s7-t1\crs-inventory\inventory-core\target\test\cassandra\data\RevKeyspace\PropertyProductDefaultInventoryCounts\snapshots\1346340659980-PropertyProductDefaultInventoryCounts\RevKeyspace-PropertyProductDefaultInventoryCounts-he-1-CompressionInfo.db
C:\XYZ\source_code\s7-t1\crs-inventory\inventory-core\target\test\cassandra\data\RevKeyspace\PropertyProductDefaultInventoryCounts\RevKeyspace-PropertyProductDefaultInventoryCounts-he-1-CompressionInfo.db,
command error Code: 1, command output: The system cannot find the path
specified.
Here is a more complete log output:
# [11:30:59.975] [DEBUG] [o.a.c.d.CollationController] [collectAllData]
[collectAllData]
# [11:30:59.976] [DEBUG] [o.a.c.i.u.FileUtils] [deleteWithConfirm] [Deleting
system-schema_columnfamilies-he-4-Digest.sha1]
# [11:30:59.977] [DEBUG] [o.a.c.i.u.FileUtils] [deleteWithConfirm] [Deleting
system-schema_columnfamilies-he-4-Index.db]
# [11:30:59.978] [DEBUG] [o.a.c.i.u.FileUtils] [deleteWithConfirm] [Deleting
system-schema_columnfamilies-he-4-Filter.db]
# [11:30:59.978] [DEBUG] [o.a.c.d.CollationController] [collectAllData]
[collectAllData]
# [11:30:59.979] [DEBUG] [o.a.c.d.CollationController] [collectAllData]
[collectAllData]
# [11:30:59.979] [DEBUG] [o.a.c.i.u.FileUtils] [deleteWithConfirm] [Deleting
system-schema_columnfamilies-he-4-Statistics.db]
# [11:30:59.979] [DEBUG] [o.a.c.d.CollationController] [collectAllData]
[collectAllData]
# [11:30:59.980] [DEBUG] [o.a.c.d.CollationController] [collectAllData]
[collectAllData]
# [11:30:59.980] [DEBUG] [o.a.c.i.s.SSTable] [delete] [Deleted
target\test\cassandra\data\system\schema_columnfamilies\system-schema_columnfamilies-he-4]
# [11:30:59.981] [INFO ] [o.a.c.d.ColumnFamilyStore] [maybeSwitchMemtable]
[Enqueuing flush of
Memtable-PropertyProductDefaultInventoryCounts@2002512083(74/92
serialized/live bytes, 1 ops)]
# [11:30:59.981] [INFO ] [o.a.c.d.Memtable] [writeSortedContents] [Writing
Memtable-PropertyProductDefaultInventoryCounts@2002512083(74/92
serialized/live bytes, 1 ops)]
# [11:30:59.992] [DEBUG] [o.a.c.d.Directories]
[getLocationWithMaximumAvailableSpace] [expected data files size is 134;
largest free partition
(target\test\cassandra\data\RevKeyspace\PropertyProductDefaultInventoryCounts)
has 82645161984 bytes free]
# [11:31:00.012] [INFO ] [o.a.c.d.Memtable] [writeSortedContents] [Completed
flushing
target\test\cassandra\data\RevKeyspace\PropertyProductDefaultInventoryCounts\RevKeyspace-PropertyProductDefaultInventoryCounts-he-1-Data.db
(123 bytes) for commitlog position ReplayPosition(segmentId=592725621297887,
position=6701)]
# [11:31:00.013] [DEBUG] [o.a.c.u.I.IntervalNode] [init] [Creating
IntervalNode from
[Interval(DecoratedKey(70791399548943621833439300945136455431,
50726f706572747950726f6475637431323334),
DecoratedKey(70791399548943621833439300945136455431,
50726f706572747950726f6475637431323334))]]
# [11:31:00.013] [DEBUG] [o.a.c.d.DataTracker] [addNewSSTablesSize] [adding
[jira] [Updated] (CASSANDRA-4590) The system cannot find the path specified when creating hard link on Windows
[ https://issues.apache.org/jira/browse/CASSANDRA-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4590: -- Priority: Trivial (was: Minor) Affects Version/s: (was: 1.1.3) 1.1.0 The system cannot find the path specified when creating hard link on Windows -- Key: CASSANDRA-4590 URL: https://issues.apache.org/jira/browse/CASSANDRA-4590 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Environment: Windows 7 - 64 bit Reporter: Allen Servedio Assignee: Jonathan Ellis Priority: Trivial Fix For: 1.1.5 When upgrading from Cassandra 1.0.5 to 1.1.3, we have a test case (uses embedded Cassandra) that started failing as shown below. Other than the upgrade, no changes were made to the code or config. I believe this MAY be related to the change made in CASSANDRA-3101. We verified that the file it is trying to create the hard link to does exist - so it is purely the creation of the link that is failing. Here is the basic failure: # [11:31:00.307] [ERROR] [o.a.c.u.CLibrary] [createHardLinkWithExec] [Unable to create hard link] java.io.IOException: Exception while executing the command: cmd /c mklink /H C:\XYZ\source_code\s7-t1\crs-inventory\inventory-core\target\test\cassandra\data\RevKeyspace\PropertyProductDefaultInventoryCounts\snapshots\1346340659980-PropertyProductDefaultInventoryCounts\RevKeyspace-PropertyProductDefaultInventoryCounts-he-1-CompressionInfo.db C:\XYZ\source_code\s7-t1\crs-inventory\inventory-core\target\test\cassandra\data\RevKeyspace\PropertyProductDefaultInventoryCounts\RevKeyspace-PropertyProductDefaultInventoryCounts-he-1-CompressionInfo.db, command error Code: 1, command output: The system cannot find the path specified. Here is a more complete log output: # [11:30:59.975] [DEBUG] [o.a.c.d.CollationController] [collectAllData] [collectAllData] # [11:30:59.976] [DEBUG] [o.a.c.i.u.FileUtils] [deleteWithConfirm] [Deleting system-schema_columnfamilies-he-4-Digest.sha1] # [11:30:59.977] [DEBUG] [o.a.c.i.u.FileUtils] [deleteWithConfirm] [Deleting system-schema_columnfamilies-he-4-Index.db] # [11:30:59.978] [DEBUG] [o.a.c.i.u.FileUtils] [deleteWithConfirm] [Deleting system-schema_columnfamilies-he-4-Filter.db] # [11:30:59.978] [DEBUG] [o.a.c.d.CollationController] [collectAllData] [collectAllData] # [11:30:59.979] [DEBUG] [o.a.c.d.CollationController] [collectAllData] [collectAllData] # [11:30:59.979] [DEBUG] [o.a.c.i.u.FileUtils] [deleteWithConfirm] [Deleting system-schema_columnfamilies-he-4-Statistics.db] # [11:30:59.979] [DEBUG] [o.a.c.d.CollationController] [collectAllData] [collectAllData] # [11:30:59.980] [DEBUG] [o.a.c.d.CollationController] [collectAllData] [collectAllData] # [11:30:59.980] [DEBUG] [o.a.c.i.s.SSTable] [delete] [Deleted target\test\cassandra\data\system\schema_columnfamilies\system-schema_columnfamilies-he-4] # [11:30:59.981] [INFO ] [o.a.c.d.ColumnFamilyStore] [maybeSwitchMemtable] [Enqueuing flush of Memtable-PropertyProductDefaultInventoryCounts@2002512083(74/92 serialized/live bytes, 1 ops)] # [11:30:59.981] [INFO ] [o.a.c.d.Memtable] [writeSortedContents] [Writing Memtable-PropertyProductDefaultInventoryCounts@2002512083(74/92 serialized/live bytes, 1 ops)] # [11:30:59.992] [DEBUG] [o.a.c.d.Directories] [getLocationWithMaximumAvailableSpace] [expected data files size is 134; largest free partition (target\test\cassandra\data\RevKeyspace\PropertyProductDefaultInventoryCounts) has 82645161984 bytes free] # [11:31:00.012] [INFO ] [o.a.c.d.Memtable] [writeSortedContents] [Completed flushing target\test\cassandra\data\RevKeyspace\PropertyProductDefaultInventoryCounts\RevKeyspace-PropertyProductDefaultInventoryCounts-he-1-Data.db (123 bytes) for commitlog position ReplayPosition(segmentId=592725621297887, position=6701)] # [11:31:00.013] [DEBUG] [o.a.c.u.I.IntervalNode] [init] [Creating IntervalNode from [Interval(DecoratedKey(70791399548943621833439300945136455431, 50726f706572747950726f6475637431323334), DecoratedKey(70791399548943621833439300945136455431, 50726f706572747950726f6475637431323334))]] # [11:31:00.013] [DEBUG] [o.a.c.d.DataTracker] [addNewSSTablesSize] [adding target\test\cassandra\data\RevKeyspace\PropertyProductDefaultInventoryCounts\RevKeyspace-PropertyProductDefaultInventoryCounts-he-1 to list of files tracked for RevKeyspace.PropertyProductDefaultInventoryCounts] # [11:31:00.014] [DEBUG] [o.a.c.d.c.CompactionManager] [submitBackground] [Scheduling a background task check for RevKeyspace.PropertyProductDefaultInventoryCounts with SizeTieredCompactionStrategy] #
Git Push Summary
Updated Tags: refs/tags/1.1.5-tentative [created] e39530789
[jira] [Updated] (CASSANDRA-3974) Per-CF TTL
[ https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk True updated CASSANDRA-3974: - Attachment: trunk-3974v5.txt Per-CF TTL -- Key: CASSANDRA-3974 URL: https://issues.apache.org/jira/browse/CASSANDRA-3974 Project: Cassandra Issue Type: New Feature Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Assignee: Kirk True Priority: Minor Fix For: 1.2.0 Attachments: trunk-3974.txt, trunk-3974v2.txt, trunk-3974v3.txt, trunk-3974v4.txt, trunk-3974v5.txt Per-CF TTL would allow compaction optimizations (drop an entire sstable's worth of expired data) that we can't do with per-column. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-4542: - Attachment: (was: CASSANDRA-4542-4543-4544-v3.patch) add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 Attachments: CASSANDRA-4542-4543-4544-v3.patch atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-4542: - Attachment: CASSANDRA-4542-4543-4544-v3.patch add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 Attachments: CASSANDRA-4542-4543-4544-v3.patch atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4633) cassandra-stress: --enable-cql does not work with COUNTER_ADD
Cathy Daw created CASSANDRA-4633:
Summary: cassandra-stress: --enable-cql does not work with
COUNTER_ADD
Key: CASSANDRA-4633
URL: https://issues.apache.org/jira/browse/CASSANDRA-4633
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Cathy Daw
Priority: Minor
When I remove --enable-cql the following runs successfully.
Note: INSERT/READ are fine.
{code}
./cassandra-stress --operation=COUNTER_ADD --enable-cql --replication-factor=3
--consistency-level=ONE --num-keys=1 --columns=20
total,interval_op_rate,interval_key_rate,avg_latency,elapsed_time
Operation [1] retried 10 times - error incrementing key 0001
((InvalidRequestException): cannot parse 'C58' as hex bytes)
Operation [0] retried 10 times - error incrementing key
((InvalidRequestException): cannot parse 'C58' as hex bytes)
0,0,0,NaN,0
FAILURE
{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-4559) implement token relocation
[
https://issues.apache.org/jira/browse/CASSANDRA-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-4559:
Attachment: 4559.txt
For all the trouble this was the figure out, the cause and solution are
remarkably simple.
calculateStreamAndFetchRanges breaks on the first intersection while iterating
the range, which works fine with a single token, but not with many since there
can be further intersections. Simply removing the breaks here so the loops
continue makes everything work correctly.
Also, since RangeRelocator calculates ranges upon instantiation, I moved this
until after the ring delay sleep for announcement, purely as an optimization so
the node can catch more relocation announcements while it sleeps before
deciding what to stream.
implement token relocation
--
Key: CASSANDRA-4559
URL: https://issues.apache.org/jira/browse/CASSANDRA-4559
Project: Cassandra
Issue Type: Sub-task
Components: Core, Tools
Affects Versions: 1.2.0 beta 1
Reporter: Eric Evans
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0 beta 1
Attachments: 4559.txt
Whatever the specifics of a _shuffle_ (see CASSANDRA-4443), it will be
necessary to relocate a range from one node to another.
_Edit0: Linked in new patch containing tests._
h3. Patches
||Compare||Raw diff||Description||
|[010_refactor_range_move|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move]|[010_refactor_range_move.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move.diff]|No
Description|
|[020_calculate_pending|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending]|[020_calculate_pending.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending.diff]|No
Description|
|[030_relocate_token|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token]|[030_relocate_token.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token.diff]|No
Description|
|[040_tests|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests]|[040_tests.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4559) implement token relocation
[
https://issues.apache.org/jira/browse/CASSANDRA-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450935#comment-13450935
]
Brandon Williams edited comment on CASSANDRA-4559 at 9/8/12 7:19 AM:
-
For all the trouble this was to figure out, the cause and solution are
remarkably simple.
calculateStreamAndFetchRanges breaks on the first intersection while iterating
the range, which works fine with a single token, but not with many since there
can be further intersections. Simply removing the breaks here so the loops
continue makes everything work correctly.
Also, since RangeRelocator calculates ranges upon instantiation, I moved this
until after the ring delay sleep for announcement, purely as an optimization so
the node can catch more relocation announcements while it sleeps before
deciding what to stream.
was (Author: brandon.williams):
For all the trouble this was the figure out, the cause and solution are
remarkably simple.
calculateStreamAndFetchRanges breaks on the first intersection while iterating
the range, which works fine with a single token, but not with many since there
can be further intersections. Simply removing the breaks here so the loops
continue makes everything work correctly.
Also, since RangeRelocator calculates ranges upon instantiation, I moved this
until after the ring delay sleep for announcement, purely as an optimization so
the node can catch more relocation announcements while it sleeps before
deciding what to stream.
implement token relocation
--
Key: CASSANDRA-4559
URL: https://issues.apache.org/jira/browse/CASSANDRA-4559
Project: Cassandra
Issue Type: Sub-task
Components: Core, Tools
Affects Versions: 1.2.0 beta 1
Reporter: Eric Evans
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0 beta 1
Attachments: 4559.txt
Whatever the specifics of a _shuffle_ (see CASSANDRA-4443), it will be
necessary to relocate a range from one node to another.
_Edit0: Linked in new patch containing tests._
h3. Patches
||Compare||Raw diff||Description||
|[010_refactor_range_move|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move]|[010_refactor_range_move.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move.diff]|No
Description|
|[020_calculate_pending|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending]|[020_calculate_pending.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending.diff]|No
Description|
|[030_relocate_token|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token]|[030_relocate_token.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token.diff]|No
Description|
|[040_tests|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests]|[040_tests.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4559) implement token relocation
[
https://issues.apache.org/jira/browse/CASSANDRA-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450947#comment-13450947
]
Brandon Williams edited comment on CASSANDRA-4559 at 9/8/12 7:33 AM:
-
Every once in a long while you can see this exception:
{noformat}
ERROR 20:30:18,355 Exception in thread Thread[OptionalTasks:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.locator.TokenMetadata.removeFromRelocating(TokenMetadata.java:443)
at
org.apache.cassandra.service.StorageService$2.run(StorageService.java:1252)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
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)
{noformat}
I suspect this is because we're using the same interval (RING_DELAY) and
sometimes they coincide. We can just double the relocation removal.
was (Author: brandon.williams):
Every once in a long while you can see this exception:
{{noformat}}
ERROR 20:30:18,355 Exception in thread Thread[OptionalTasks:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.locator.TokenMetadata.removeFromRelocating(TokenMetadata.java:443)
at
org.apache.cassandra.service.StorageService$2.run(StorageService.java:1252)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
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)
{{noformat}
I suspect this is because we're using the same interval (RING_DELAY) and
sometimes they coincide. We can just double the relocation removal.
implement token relocation
--
Key: CASSANDRA-4559
URL: https://issues.apache.org/jira/browse/CASSANDRA-4559
Project: Cassandra
Issue Type: Sub-task
Components: Core, Tools
Affects Versions: 1.2.0 beta 1
Reporter: Eric Evans
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0 beta 1
Attachments: 4559.txt
Whatever the specifics of a _shuffle_ (see CASSANDRA-4443), it will be
necessary to relocate a range from one node to another.
_Edit0: Linked in new patch containing tests._
h3. Patches
||Compare||Raw diff||Description||
|[010_refactor_range_move|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move]|[010_refactor_range_move.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move.diff]|No
Description|
|[020_calculate_pending|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending]|[020_calculate_pending.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending.diff]|No
Description|
|[030_relocate_token|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token]|[030_relocate_token.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token.diff]|No
Description|
|[040_tests|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests]|[040_tests.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
This
[jira] [Commented] (CASSANDRA-4559) implement token relocation
[
https://issues.apache.org/jira/browse/CASSANDRA-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450947#comment-13450947
]
Brandon Williams commented on CASSANDRA-4559:
-
Every once in a long while you can see this exception:
{{noformat}}
ERROR 20:30:18,355 Exception in thread Thread[OptionalTasks:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.locator.TokenMetadata.removeFromRelocating(TokenMetadata.java:443)
at
org.apache.cassandra.service.StorageService$2.run(StorageService.java:1252)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
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)
{{noformat}
I suspect this is because we're using the same interval (RING_DELAY) and
sometimes they coincide. We can just double the relocation removal.
implement token relocation
--
Key: CASSANDRA-4559
URL: https://issues.apache.org/jira/browse/CASSANDRA-4559
Project: Cassandra
Issue Type: Sub-task
Components: Core, Tools
Affects Versions: 1.2.0 beta 1
Reporter: Eric Evans
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0 beta 1
Attachments: 4559.txt
Whatever the specifics of a _shuffle_ (see CASSANDRA-4443), it will be
necessary to relocate a range from one node to another.
_Edit0: Linked in new patch containing tests._
h3. Patches
||Compare||Raw diff||Description||
|[010_refactor_range_move|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move]|[010_refactor_range_move.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move.diff]|No
Description|
|[020_calculate_pending|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending]|[020_calculate_pending.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending.diff]|No
Description|
|[030_relocate_token|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token]|[030_relocate_token.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token.diff]|No
Description|
|[040_tests|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests]|[040_tests.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4559) implement token relocation
[
https://issues.apache.org/jira/browse/CASSANDRA-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450962#comment-13450962
]
Jonathan Ellis commented on CASSANDRA-4559:
---
bq. I suspect this is because we're using the same interval (RING_DELAY) and
sometimes they coincide. We can just double the relocation removal.
I don't follow how the interval means we can remove the same token twice.
implement token relocation
--
Key: CASSANDRA-4559
URL: https://issues.apache.org/jira/browse/CASSANDRA-4559
Project: Cassandra
Issue Type: Sub-task
Components: Core, Tools
Affects Versions: 1.2.0 beta 1
Reporter: Eric Evans
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0 beta 1
Attachments: 4559.txt
Whatever the specifics of a _shuffle_ (see CASSANDRA-4443), it will be
necessary to relocate a range from one node to another.
_Edit0: Linked in new patch containing tests._
h3. Patches
||Compare||Raw diff||Description||
|[010_refactor_range_move|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move]|[010_refactor_range_move.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move.diff]|No
Description|
|[020_calculate_pending|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending]|[020_calculate_pending.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending.diff]|No
Description|
|[030_relocate_token|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token]|[030_relocate_token.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token.diff]|No
Description|
|[040_tests|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests]|[040_tests.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4559) implement token relocation
[
https://issues.apache.org/jira/browse/CASSANDRA-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450968#comment-13450968
]
Brandon Williams commented on CASSANDRA-4559:
-
Hmm, you're right... and that's the only place we remove it.
implement token relocation
--
Key: CASSANDRA-4559
URL: https://issues.apache.org/jira/browse/CASSANDRA-4559
Project: Cassandra
Issue Type: Sub-task
Components: Core, Tools
Affects Versions: 1.2.0 beta 1
Reporter: Eric Evans
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0 beta 1
Attachments: 4559.txt
Whatever the specifics of a _shuffle_ (see CASSANDRA-4443), it will be
necessary to relocate a range from one node to another.
_Edit0: Linked in new patch containing tests._
h3. Patches
||Compare||Raw diff||Description||
|[010_refactor_range_move|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move]|[010_refactor_range_move.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move.diff]|No
Description|
|[020_calculate_pending|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending]|[020_calculate_pending.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending.diff]|No
Description|
|[030_relocate_token|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token]|[030_relocate_token.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token.diff]|No
Description|
|[040_tests|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests]|[040_tests.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4537) We should emit number of sstables in each level from JMX
[
https://issues.apache.org/jira/browse/CASSANDRA-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-4537:
--
Attachment: 4537.txt
Attaching patch that adds SSTableCountPerLevel to ColulmnFamilyStoreMBean,
which returns number of SSTable for each level in _int[]_ and prints it with
nodetool cfstats.
Output looks like below:
{code}
...
Column Family: Standard1
SSTable count: 19
SSTables in each level: [0, 8, 11, 0, 0, 0, 0, 0]
Space used (live): 100923462
Space used (total): 101012612
...
{code}
compactionstats displays info only when compaction is happening, so I chose
cfstats to show info.
cfstats output is long, but let CASSANDRA-4191 handle it.
We should emit number of sstables in each level from JMX
Key: CASSANDRA-4537
URL: https://issues.apache.org/jira/browse/CASSANDRA-4537
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: sankalp kohli
Assignee: Yuki Morishita
Priority: Minor
Labels: compaction, leveled
Fix For: 1.2.1
Attachments: 4537.txt
Original Estimate: 12h
Remaining Estimate: 12h
We should add methods to this Mbean
org.apache.cassandra.db.ColumnFamilyStoreMBean
These metrics will be helpful to see how sstables are distributed in
different levels and how they move to higher level with time.
Currently we can see this by looking at the json file but with JMX, we can
monitor the historic values over time using any monitoring tool.
--
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-4537) We should emit number of sstables in each level from JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450985#comment-13450985 ] Jonathan Ellis commented on CASSANDRA-4537: --- Idea: show number of sstables / desired max, when we exceed the desired threshold? This would give you a quick eyeball of here's where compaction is behind. SSTables in each level: [43/0, 8, 102/100, 123, 0, 0, 0, 0] We should emit number of sstables in each level from JMX Key: CASSANDRA-4537 URL: https://issues.apache.org/jira/browse/CASSANDRA-4537 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.0 Reporter: sankalp kohli Assignee: Yuki Morishita Priority: Minor Labels: compaction, leveled Fix For: 1.2.1 Attachments: 4537.txt Original Estimate: 12h Remaining Estimate: 12h We should add methods to this Mbean org.apache.cassandra.db.ColumnFamilyStoreMBean These metrics will be helpful to see how sstables are distributed in different levels and how they move to higher level with time. Currently we can see this by looking at the json file but with JMX, we can monitor the historic values over time using any monitoring tool. -- 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-4541) Replace Throttle with Guava's RateLimiter
[
https://issues.apache.org/jira/browse/CASSANDRA-4541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-4541:
-
Assignee: Aleksey Yeschenko (was: Yuki Morishita)
Replace Throttle with Guava's RateLimiter
-
Key: CASSANDRA-4541
URL: https://issues.apache.org/jira/browse/CASSANDRA-4541
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Michaël Figuière
Assignee: Aleksey Yeschenko
Priority: Minor
Guava 13 introduced {{RateLimiter}} [1] which should be a good replacement
for {{o.a.c.utils.Throttle}} that is used in Compaction and Streaming as a
throughput limiter.
[1]
[http://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/util/concurrent/RateLimiter.java]
--
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: update guava to r13
Updated Branches: refs/heads/trunk 2b6c625e4 - a85b57770 update guava to r13 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a85b5777 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a85b5777 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a85b5777 Branch: refs/heads/trunk Commit: a85b57770e2cc2437065b453b1776c43e7a28d71 Parents: 2b6c625 Author: Jonathan Ellis jbel...@apache.org Authored: Fri Sep 7 16:18:21 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Fri Sep 7 16:18:21 2012 -0500 -- lib/guava-12.0.jar| Bin 1795936 - 0 bytes lib/guava-13.0.1.jar | Bin 0 - 1891110 bytes lib/licenses/guava-12.0.txt | 202 lib/licenses/guava-13.0.1.txt | 202 4 files changed, 202 insertions(+), 202 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a85b5777/lib/guava-12.0.jar -- diff --git a/lib/guava-12.0.jar b/lib/guava-12.0.jar deleted file mode 100644 index fefd6b2..000 Binary files a/lib/guava-12.0.jar and /dev/null differ http://git-wip-us.apache.org/repos/asf/cassandra/blob/a85b5777/lib/guava-13.0.1.jar -- diff --git a/lib/guava-13.0.1.jar b/lib/guava-13.0.1.jar new file mode 100644 index 000..09c5449 Binary files /dev/null and b/lib/guava-13.0.1.jar differ http://git-wip-us.apache.org/repos/asf/cassandra/blob/a85b5777/lib/licenses/guava-12.0.txt -- diff --git a/lib/licenses/guava-12.0.txt b/lib/licenses/guava-12.0.txt deleted file mode 100644 index d645695..000 --- a/lib/licenses/guava-12.0.txt +++ /dev/null @@ -1,202 +0,0 @@ - - Apache License - Version 2.0, January 2004 -http://www.apache.org/licenses/ - - TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION - - 1. Definitions. - - License shall mean the terms and conditions for use, reproduction, - and distribution as defined by Sections 1 through 9 of this document. - - Licensor shall mean the copyright owner or entity authorized by - the copyright owner that is granting the License. - - Legal Entity shall mean the union of the acting entity and all - other entities that control, are controlled by, or are under common - control with that entity. For the purposes of this definition, - control means (i) the power, direct or indirect, to cause the - direction or management of such entity, whether by contract or - otherwise, or (ii) ownership of fifty percent (50%) or more of the - outstanding shares, or (iii) beneficial ownership of such entity. - - You (or Your) shall mean an individual or Legal Entity - exercising permissions granted by this License. - - Source form shall mean the preferred form for making modifications, - including but not limited to software source code, documentation - source, and configuration files. - - Object form shall mean any form resulting from mechanical - transformation or translation of a Source form, including but - not limited to compiled object code, generated documentation, - and conversions to other media types. - - Work shall mean the work of authorship, whether in Source or - Object form, made available under the License, as indicated by a - copyright notice that is included in or attached to the work - (an example is provided in the Appendix below). - - Derivative Works shall mean any work, whether in Source or Object - form, that is based on (or derived from) the Work and for which the - editorial revisions, annotations, elaborations, or other modifications - represent, as a whole, an original work of authorship. For the purposes - of this License, Derivative Works shall not include works that remain - separable from, or merely link (or bind by name) to the interfaces of, - the Work and Derivative Works thereof. - - Contribution shall mean any work of authorship, including - the original version of the Work and any modifications or additions - to that Work or Derivative Works thereof, that is intentionally - submitted to Licensor for inclusion in the Work by the copyright owner - or by an individual or Legal Entity authorized to submit on behalf of - the copyright owner. For the purposes of this definition, submitted - means any form of electronic, verbal, or written communication sent - to the Licensor or its representatives, including but
[jira] [Updated] (CASSANDRA-4633) cassandra-stress: --enable-cql does not work with COUNTER_ADD
[
https://issues.apache.org/jira/browse/CASSANDRA-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4633:
--
Reviewer: xedin
Fix Version/s: 1.2.0
Assignee: Aleksey Yeschenko
cassandra-stress: --enable-cql does not work with COUNTER_ADD
--
Key: CASSANDRA-4633
URL: https://issues.apache.org/jira/browse/CASSANDRA-4633
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Cathy Daw
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.2.0
When I remove --enable-cql the following runs successfully.
Note: INSERT/READ are fine.
{code}
./cassandra-stress --operation=COUNTER_ADD --enable-cql
--replication-factor=3 --consistency-level=ONE --num-keys=1 --columns=20
total,interval_op_rate,interval_key_rate,avg_latency,elapsed_time
Operation [1] retried 10 times - error incrementing key 0001
((InvalidRequestException): cannot parse 'C58' as hex bytes)
Operation [0] retried 10 times - error incrementing key
((InvalidRequestException): cannot parse 'C58' as hex bytes)
0,0,0,NaN,0
FAILURE
{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] [Resolved] (CASSANDRA-4544) fix acknowledge_by for batch_mutate
[ https://issues.apache.org/jira/browse/CASSANDRA-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko resolved CASSANDRA-4544. -- Resolution: Fixed This has already been implemented in 4542. fix acknowledge_by for batch_mutate --- Key: CASSANDRA-4544 URL: https://issues.apache.org/jira/browse/CASSANDRA-4544 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Priority: Minor Attachments: CASSANDRA-4544.patch CASSANDRA-4414 added TimedOutException.acknowledged_by, but for a batch write will send back the acknowledged_by for a random row, which usually does not reflect the status for the batch as a whole. Should override this to -1 in that case. -- 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-4543) batchlog replay
[ https://issues.apache.org/jira/browse/CASSANDRA-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko resolved CASSANDRA-4543. -- Resolution: Fixed This has already been implemented in 4542. batchlog replay --- Key: CASSANDRA-4543 URL: https://issues.apache.org/jira/browse/CASSANDRA-4543 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4542: -- Attachment: 4542-diff.txt Nice work, I think we're almost done! I've attached a diff with a couple minor changes: - moves availability check into mutateAtomically - handles batchlog targets being unavailable unsure what changes to sendToHintedEndpoints are doing. if this is just refactoring for clarity let's back that out for a separate patch. The big change I think we still need is, batchlog writes shouldn't be doing hinted writes; if we can't write to the batchlog, too bad, we ignore it and move on. No sense in replaying a hint later, after the write itself has probably succeeded. add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 Attachments: 4542-diff.txt, CASSANDRA-4542-4543-4544-v3.patch atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4542: -- Attachment: 4542-v4.txt v4 attached that refactors unhinted writes for batchlog to not go through the entire MultiMap business that full sendToHintedEndpoints does. to-do: - update getBatchlogEndpoints to not include local node, unless it's the only node in the DC - update batchlog replay to only wait RING_DELAY before first replay instead of 10 minutes add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 Attachments: 4542-diff.txt, 4542-v4.txt, CASSANDRA-4542-4543-4544-v3.patch atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13451150#comment-13451150 ] Aleksey Yeschenko commented on CASSANDRA-4542: -- Attached v5. add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 Attachments: 4542-diff.txt, 4542-v4.txt, 4542-v5.patch, CASSANDRA-4542-4543-4544-v3.patch atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-4542: - Attachment: 4542-v5.patch add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 Attachments: 4542-diff.txt, 4542-v4.txt, 4542-v5.patch, CASSANDRA-4542-4543-4544-v3.patch atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
