[jira] [Created] (CASSANDRA-7418) Cannot upgrade: Tried to create duplicate hard link
Tom van den Berge created CASSANDRA-7418: Summary: Cannot upgrade: Tried to create duplicate hard link Key: CASSANDRA-7418 URL: https://issues.apache.org/jira/browse/CASSANDRA-7418 Project: Cassandra Issue Type: Bug Reporter: Tom van den Berge Priority: Critical I'm trying to migrate a cluster from 1.2.14 to 2.0.8. When starting up 2.0.8, I'm seeing the following error in the logs: INFO 17:40:25,405 Snapshotting drillster, Account to pre-sstablemetamigration ERROR 17:40:25,407 Exception encountered during startup java.lang.RuntimeException: Tried to create duplicate hard link to /Users/tom/cassandra-data/data/drillster/Account/snapshots/pre-sstablemetamigration/drillster-Account-ic-65-Filter.db at org.apache.cassandra.io.util.FileUtils.createHardLink(FileUtils.java:75) at org.apache.cassandra.db.compaction.LegacyLeveledManifest.snapshotWithoutCFS(LegacyLeveledManifest.java:129) at org.apache.cassandra.db.compaction.LegacyLeveledManifest.migrateManifests(LegacyLeveledManifest.java:91) at org.apache.cassandra.db.compaction.LeveledManifest.maybeMigrateManifests(LeveledManifest.java:617) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:274) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585) As a result, I can't start up 2.0.8, and switching back to 1.2.14 also doesn't work. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7311) Enable incremental backup on a per-keyspace level
[ https://issues.apache.org/jira/browse/CASSANDRA-7311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pankaj mishra updated CASSANDRA-7311: - Attachment: cassandra_incremental_latest.patch Patch with thrift changes removed. Enable incremental backup on a per-keyspace level - Key: CASSANDRA-7311 URL: https://issues.apache.org/jira/browse/CASSANDRA-7311 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: lhf Attachments: CASSANDRA-7311-formated.patch, cassandra.patch, cassandra_incremental.patch, cassandra_incremental_latest.patch Currently incremental backups are globally defined, however this is not always appropriate or required for all keyspaces in a cluster. As this is quite expensive, it would be preferred to either specify the keyspaces that need this (or exclude the ones that don't). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7344) Read at SERIAL can lead to unnecessary contention
[ https://issues.apache.org/jira/browse/CASSANDRA-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037097#comment-14037097 ] Sylvain Lebresne commented on CASSANDRA-7344: - bq. By getting the last accepted commit and seeing whether it is empty. But getting it locally is not enough since the point of SERIAL read is to unsure there is no ongoing update we are not part of. So we'd need one round-trip to get the last accepted commit, which is not better that doing the prepare. Besides, the last accepted commit will generally not be empty unless no update have ever been committed on the partition, so in practice we'd always have to do the prepare and thus have 2 round-trips in general instead of one. Or am I misunderstanding what you are suggesting? Read at SERIAL can lead to unnecessary contention -- Key: CASSANDRA-7344 URL: https://issues.apache.org/jira/browse/CASSANDRA-7344 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor If two clients are doing a read at serial on the same row, it does a full prepare step to figure out whether there is any updates or cas in flight or uncompleted. This can cause contention between then leading to waste of time in retrying. One of the request will not get a promise and will need to sleep. Instead they can check whether there is anything to finish and if not continue. If there is something to be done, then they can do the full prepare. -- This message was sent by Atlassian JIRA (v6.2#6252)
[1/2] git commit: Account for range tombstones in min/max column names
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 baf524fe4 - 3ff7a776a
Account for range tombstones in min/max column names
Patch by Oleg Anastasyev, reviewed by marcuse for CASSANDRA-7235
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/303ff22d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/303ff22d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/303ff22d
Branch: refs/heads/cassandra-2.1
Commit: 303ff22dd608d4971a12de52f91184dcd82895c0
Parents: dd87228
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jun 19 08:50:27 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jun 19 08:50:27 2014 +0200
--
CHANGES.txt | 1 +
.../org/apache/cassandra/db/ColumnFamily.java | 3 +
.../db/compaction/LazilyCompactedRow.java | 11 +--
.../cassandra/io/sstable/SSTableWriter.java | 3 +
.../apache/cassandra/db/ColumnFamilyTest.java | 12 +++
.../db/compaction/CompactionsTest.java | 97 +++-
6 files changed, 120 insertions(+), 7 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/303ff22d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 16e0531..65e3161 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -17,6 +17,7 @@
* Make StreamSession#closeSession() idempotent (CASSANDRA-7262)
* Fix infinite loop on exception while streaming (CASSANDRA-7330)
* Reference sstables before populating key cache (CASSANDRA-7234)
+ * Account for range tombstones in min/max column names (CASSANDRA-7235)
Merged from 1.2:
* cqlsh: ignore .cassandra permission errors (CASSANDRA-7266)
* Errors in FlushRunnable may leave threads hung (CASSANDRA-7275)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/303ff22d/src/java/org/apache/cassandra/db/ColumnFamily.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamily.java
b/src/java/org/apache/cassandra/db/ColumnFamily.java
index ec6a395..638eacc 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamily.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamily.java
@@ -426,6 +426,9 @@ public abstract class ColumnFamily implements
IterableColumn, IRowCacheEntry
{
RangeTombstone rangeTombstone = it.next();
tombstones.update(rangeTombstone.getLocalDeletionTime());
+
+minColumnNamesSeen =
ColumnNameHelper.minComponents(minColumnNamesSeen, rangeTombstone.min,
metadata.comparator);
+maxColumnNamesSeen =
ColumnNameHelper.maxComponents(maxColumnNamesSeen, rangeTombstone.max,
metadata.comparator);
}
for (Column column : this)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/303ff22d/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
--
diff --git
a/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
b/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
index e10fb2c..7cd0842 100644
--- a/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
+++ b/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
@@ -252,6 +252,11 @@ public class LazilyCompactedRow extends
AbstractCompactedRow implements Iterable
}
else
{
+tombstones.update(t.getLocalDeletionTime());
+
+minColumnNameSeen =
ColumnNameHelper.minComponents(minColumnNameSeen, t.min,
controller.cfs.metadata.comparator);
+maxColumnNameSeen =
ColumnNameHelper.maxComponents(maxColumnNameSeen, t.max,
controller.cfs.metadata.comparator);
+
return t;
}
}
@@ -278,12 +283,6 @@ public class LazilyCompactedRow extends
AbstractCompactedRow implements Iterable
int localDeletionTime =
purged.deletionInfo().getTopLevelDeletion().localDeletionTime;
if (localDeletionTime Integer.MAX_VALUE)
tombstones.update(localDeletionTime);
-IteratorRangeTombstone rangeTombstoneIterator =
purged.deletionInfo().rangeIterator();
-while (rangeTombstoneIterator.hasNext())
-{
-RangeTombstone rangeTombstone =
rangeTombstoneIterator.next();
-tombstones.update(rangeTombstone.getLocalDeletionTime());
-}
columns++;
minTimestampSeen = Math.min(minTimestampSeen,
reduced.minTimestamp());
maxTimestampSeen = Math.max(maxTimestampSeen,
git commit: Account for range tombstones in min/max column names
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 dd8722807 - 303ff22dd
Account for range tombstones in min/max column names
Patch by Oleg Anastasyev, reviewed by marcuse for CASSANDRA-7235
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/303ff22d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/303ff22d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/303ff22d
Branch: refs/heads/cassandra-2.0
Commit: 303ff22dd608d4971a12de52f91184dcd82895c0
Parents: dd87228
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jun 19 08:50:27 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jun 19 08:50:27 2014 +0200
--
CHANGES.txt | 1 +
.../org/apache/cassandra/db/ColumnFamily.java | 3 +
.../db/compaction/LazilyCompactedRow.java | 11 +--
.../cassandra/io/sstable/SSTableWriter.java | 3 +
.../apache/cassandra/db/ColumnFamilyTest.java | 12 +++
.../db/compaction/CompactionsTest.java | 97 +++-
6 files changed, 120 insertions(+), 7 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/303ff22d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 16e0531..65e3161 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -17,6 +17,7 @@
* Make StreamSession#closeSession() idempotent (CASSANDRA-7262)
* Fix infinite loop on exception while streaming (CASSANDRA-7330)
* Reference sstables before populating key cache (CASSANDRA-7234)
+ * Account for range tombstones in min/max column names (CASSANDRA-7235)
Merged from 1.2:
* cqlsh: ignore .cassandra permission errors (CASSANDRA-7266)
* Errors in FlushRunnable may leave threads hung (CASSANDRA-7275)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/303ff22d/src/java/org/apache/cassandra/db/ColumnFamily.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamily.java
b/src/java/org/apache/cassandra/db/ColumnFamily.java
index ec6a395..638eacc 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamily.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamily.java
@@ -426,6 +426,9 @@ public abstract class ColumnFamily implements
IterableColumn, IRowCacheEntry
{
RangeTombstone rangeTombstone = it.next();
tombstones.update(rangeTombstone.getLocalDeletionTime());
+
+minColumnNamesSeen =
ColumnNameHelper.minComponents(minColumnNamesSeen, rangeTombstone.min,
metadata.comparator);
+maxColumnNamesSeen =
ColumnNameHelper.maxComponents(maxColumnNamesSeen, rangeTombstone.max,
metadata.comparator);
}
for (Column column : this)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/303ff22d/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
--
diff --git
a/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
b/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
index e10fb2c..7cd0842 100644
--- a/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
+++ b/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
@@ -252,6 +252,11 @@ public class LazilyCompactedRow extends
AbstractCompactedRow implements Iterable
}
else
{
+tombstones.update(t.getLocalDeletionTime());
+
+minColumnNameSeen =
ColumnNameHelper.minComponents(minColumnNameSeen, t.min,
controller.cfs.metadata.comparator);
+maxColumnNameSeen =
ColumnNameHelper.maxComponents(maxColumnNameSeen, t.max,
controller.cfs.metadata.comparator);
+
return t;
}
}
@@ -278,12 +283,6 @@ public class LazilyCompactedRow extends
AbstractCompactedRow implements Iterable
int localDeletionTime =
purged.deletionInfo().getTopLevelDeletion().localDeletionTime;
if (localDeletionTime Integer.MAX_VALUE)
tombstones.update(localDeletionTime);
-IteratorRangeTombstone rangeTombstoneIterator =
purged.deletionInfo().rangeIterator();
-while (rangeTombstoneIterator.hasNext())
-{
-RangeTombstone rangeTombstone =
rangeTombstoneIterator.next();
-tombstones.update(rangeTombstone.getLocalDeletionTime());
-}
columns++;
minTimestampSeen = Math.min(minTimestampSeen,
reduced.minTimestamp());
maxTimestampSeen = Math.max(maxTimestampSeen,
[3/3] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk
Conflicts:
test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7d8ba3be
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7d8ba3be
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7d8ba3be
Branch: refs/heads/trunk
Commit: 7d8ba3be55ff0800dc0f7fdcc3f4dded1ed02770
Parents: 4155033 3ff7a77
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jun 19 10:08:31 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jun 19 10:08:31 2014 +0200
--
CHANGES.txt | 1 +
.../org/apache/cassandra/db/ColumnFamily.java | 21 ++--
.../db/compaction/LazilyCompactedRow.java | 10 +-
.../cassandra/io/sstable/SSTableWriter.java | 3 +
.../apache/cassandra/db/ColumnFamilyTest.java | 12 ++
.../db/compaction/CompactionsTest.java | 117 ---
6 files changed, 135 insertions(+), 29 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7d8ba3be/CHANGES.txt
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7d8ba3be/src/java/org/apache/cassandra/db/ColumnFamily.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7d8ba3be/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7d8ba3be/test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java
--
diff --cc test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java
index a720375,c60b650..58473b4
--- a/test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java
+++ b/test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java
@@@ -18,20 -18,9 +18,16 @@@
*/
package org.apache.cassandra.db.compaction;
- import static org.junit.Assert.assertEquals;
- import static org.junit.Assert.assertFalse;
- import static org.junit.Assert.assertTrue;
- import static org.junit.Assert.assertNotNull;
-
-import java.io.*;
+import java.io.File;
++import java.io.IOException;
import java.nio.ByteBuffer;
-import java.util.*;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Iterator;
+import java.util.Map;
+import java.util.Set;
+import java.util.UUID;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.TimeUnit;
@@@ -59,14 -51,9 +52,16 @@@ import org.apache.cassandra.service.Sto
import org.apache.cassandra.utils.ByteBufferUtil;
import org.apache.cassandra.utils.FBUtilities;
import org.apache.cassandra.utils.Pair;
+import org.junit.Ignore;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+
+import com.google.common.base.Function;
+import com.google.common.collect.Iterables;
+import com.google.common.collect.Sets;
+ import static org.junit.Assert.*;
+
@RunWith(OrderedJUnit4ClassRunner.class)
public class CompactionsTest extends SchemaLoader
{
[1/3] git commit: Account for range tombstones in min/max column names
Repository: cassandra
Updated Branches:
refs/heads/trunk 415503353 - 7d8ba3be5
Account for range tombstones in min/max column names
Patch by Oleg Anastasyev, reviewed by marcuse for CASSANDRA-7235
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/303ff22d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/303ff22d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/303ff22d
Branch: refs/heads/trunk
Commit: 303ff22dd608d4971a12de52f91184dcd82895c0
Parents: dd87228
Author: Marcus Eriksson marc...@apache.org
Authored: Thu Jun 19 08:50:27 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Thu Jun 19 08:50:27 2014 +0200
--
CHANGES.txt | 1 +
.../org/apache/cassandra/db/ColumnFamily.java | 3 +
.../db/compaction/LazilyCompactedRow.java | 11 +--
.../cassandra/io/sstable/SSTableWriter.java | 3 +
.../apache/cassandra/db/ColumnFamilyTest.java | 12 +++
.../db/compaction/CompactionsTest.java | 97 +++-
6 files changed, 120 insertions(+), 7 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/303ff22d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 16e0531..65e3161 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -17,6 +17,7 @@
* Make StreamSession#closeSession() idempotent (CASSANDRA-7262)
* Fix infinite loop on exception while streaming (CASSANDRA-7330)
* Reference sstables before populating key cache (CASSANDRA-7234)
+ * Account for range tombstones in min/max column names (CASSANDRA-7235)
Merged from 1.2:
* cqlsh: ignore .cassandra permission errors (CASSANDRA-7266)
* Errors in FlushRunnable may leave threads hung (CASSANDRA-7275)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/303ff22d/src/java/org/apache/cassandra/db/ColumnFamily.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamily.java
b/src/java/org/apache/cassandra/db/ColumnFamily.java
index ec6a395..638eacc 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamily.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamily.java
@@ -426,6 +426,9 @@ public abstract class ColumnFamily implements
IterableColumn, IRowCacheEntry
{
RangeTombstone rangeTombstone = it.next();
tombstones.update(rangeTombstone.getLocalDeletionTime());
+
+minColumnNamesSeen =
ColumnNameHelper.minComponents(minColumnNamesSeen, rangeTombstone.min,
metadata.comparator);
+maxColumnNamesSeen =
ColumnNameHelper.maxComponents(maxColumnNamesSeen, rangeTombstone.max,
metadata.comparator);
}
for (Column column : this)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/303ff22d/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
--
diff --git
a/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
b/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
index e10fb2c..7cd0842 100644
--- a/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
+++ b/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java
@@ -252,6 +252,11 @@ public class LazilyCompactedRow extends
AbstractCompactedRow implements Iterable
}
else
{
+tombstones.update(t.getLocalDeletionTime());
+
+minColumnNameSeen =
ColumnNameHelper.minComponents(minColumnNameSeen, t.min,
controller.cfs.metadata.comparator);
+maxColumnNameSeen =
ColumnNameHelper.maxComponents(maxColumnNameSeen, t.max,
controller.cfs.metadata.comparator);
+
return t;
}
}
@@ -278,12 +283,6 @@ public class LazilyCompactedRow extends
AbstractCompactedRow implements Iterable
int localDeletionTime =
purged.deletionInfo().getTopLevelDeletion().localDeletionTime;
if (localDeletionTime Integer.MAX_VALUE)
tombstones.update(localDeletionTime);
-IteratorRangeTombstone rangeTombstoneIterator =
purged.deletionInfo().rangeIterator();
-while (rangeTombstoneIterator.hasNext())
-{
-RangeTombstone rangeTombstone =
rangeTombstoneIterator.next();
-tombstones.update(rangeTombstone.getLocalDeletionTime());
-}
columns++;
minTimestampSeen = Math.min(minTimestampSeen,
reduced.minTimestamp());
maxTimestampSeen = Math.max(maxTimestampSeen,
reduced.maxTimestamp());
[2/2] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt src/java/org/apache/cassandra/db/ColumnFamily.java src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3ff7a776 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3ff7a776 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3ff7a776 Branch: refs/heads/cassandra-2.1 Commit: 3ff7a776a76d5ca9c3ee569067896f6098075885 Parents: baf524f 303ff22 Author: Marcus Eriksson marc...@apache.org Authored: Thu Jun 19 09:51:28 2014 +0200 Committer: Marcus Eriksson marc...@apache.org Committed: Thu Jun 19 09:51:28 2014 +0200 -- CHANGES.txt | 1 + .../org/apache/cassandra/db/ColumnFamily.java | 21 ++-- .../db/compaction/LazilyCompactedRow.java | 10 +- .../cassandra/io/sstable/SSTableWriter.java | 3 + .../apache/cassandra/db/ColumnFamilyTest.java | 12 +++ .../db/compaction/CompactionsTest.java | 100 ++- 6 files changed, 132 insertions(+), 15 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3ff7a776/CHANGES.txt -- diff --cc CHANGES.txt index af6e8c0,65e3161..ad5fb1c --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,25 -1,23 +1,26 @@@ -2.0.9 - * Fix assertion error in CL.ANY timeout handling (CASSANDRA-7364) - * Handle empty CFs in Memtable#maybeUpdateLiveRatio() (CASSANDRA-7401) +2.1.0 + * Avoid incremental compaction on Windows (CASSANDRA-7365) + * Fix exception when querying a composite-keyed table with a collection index + (CASSANDRA-7372) + * Use node's host id in place of counter ids (CASSANDRA-7366) * Fix native protocol CAS batches (CASSANDRA-7337) + * Reduce likelihood of contention on local paxos locking (CASSANDRA-7359) + * Upgrade to Pig 0.12.1 (CASSANDRA-6556) + * Make sure we clear out repair sessions from netstats (CASSANDRA-7329) + * Don't fail streams on failure detector downs (CASSANDRA-3569) + * Add optional keyspace to DROP INDEX statement (CASSANDRA-7314) + * Reduce run time for CQL tests (CASSANDRA-7327) + * Fix heap size calculation on Windows (CASSANDRA-7352, 7353) + * RefCount native frames from netty (CASSANDRA-7245) + * Use tarball dir instead of /var for default paths (CASSANDRA-7136) + * Remove rows_per_partition_to_cache keyword (CASSANDRA-7193) +Merged from 2.0: + * Fix assertion error in CL.ANY timeout handling (CASSANDRA-7364) * Add per-CF range read request latency metrics (CASSANDRA-7338) * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323) - * Add conditional CREATE/DROP USER support (CASSANDRA-7264) - * Swap local and global default read repair chances (CASSANDRA-7320) - * Add missing iso8601 patterns for date strings (CASSANDRA-6973) - * Support selecting multiple rows in a partition using IN (CASSANDRA-6875) - * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274) - * Copy compaction options to make sure they are reloaded (CASSANDRA-7290) - * Add option to do more aggressive tombstone compactions (CASSANDRA-6563) - * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288) - * Add authentication support to shuffle (CASSANDRA-6484) - * Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325) * Make StreamSession#closeSession() idempotent (CASSANDRA-7262) * Fix infinite loop on exception while streaming (CASSANDRA-7330) - * Reference sstables before populating key cache (CASSANDRA-7234) + * Account for range tombstones in min/max column names (CASSANDRA-7235) Merged from 1.2: * cqlsh: ignore .cassandra permission errors (CASSANDRA-7266) * Errors in FlushRunnable may leave threads hung (CASSANDRA-7275) http://git-wip-us.apache.org/repos/asf/cassandra/blob/3ff7a776/src/java/org/apache/cassandra/db/ColumnFamily.java -- diff --cc src/java/org/apache/cassandra/db/ColumnFamily.java index 45b8eff,638eacc..38e1591 --- a/src/java/org/apache/cassandra/db/ColumnFamily.java +++ b/src/java/org/apache/cassandra/db/ColumnFamily.java @@@ -402,36 -418,31 +402,41 @@@ public abstract class ColumnFamily impl int maxLocalDeletionTime = Integer.MIN_VALUE; ListByteBuffer minColumnNamesSeen = Collections.emptyList(); ListByteBuffer maxColumnNamesSeen = Collections.emptyList(); +boolean hasLegacyCounterShards = false; + + if (deletionInfo().getTopLevelDeletion().localDeletionTime Integer.MAX_VALUE) + tombstones.update(deletionInfo().getTopLevelDeletion().localDeletionTime); + IteratorRangeTombstone
[2/3] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt src/java/org/apache/cassandra/db/ColumnFamily.java src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3ff7a776 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3ff7a776 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3ff7a776 Branch: refs/heads/trunk Commit: 3ff7a776a76d5ca9c3ee569067896f6098075885 Parents: baf524f 303ff22 Author: Marcus Eriksson marc...@apache.org Authored: Thu Jun 19 09:51:28 2014 +0200 Committer: Marcus Eriksson marc...@apache.org Committed: Thu Jun 19 09:51:28 2014 +0200 -- CHANGES.txt | 1 + .../org/apache/cassandra/db/ColumnFamily.java | 21 ++-- .../db/compaction/LazilyCompactedRow.java | 10 +- .../cassandra/io/sstable/SSTableWriter.java | 3 + .../apache/cassandra/db/ColumnFamilyTest.java | 12 +++ .../db/compaction/CompactionsTest.java | 100 ++- 6 files changed, 132 insertions(+), 15 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3ff7a776/CHANGES.txt -- diff --cc CHANGES.txt index af6e8c0,65e3161..ad5fb1c --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,25 -1,23 +1,26 @@@ -2.0.9 - * Fix assertion error in CL.ANY timeout handling (CASSANDRA-7364) - * Handle empty CFs in Memtable#maybeUpdateLiveRatio() (CASSANDRA-7401) +2.1.0 + * Avoid incremental compaction on Windows (CASSANDRA-7365) + * Fix exception when querying a composite-keyed table with a collection index + (CASSANDRA-7372) + * Use node's host id in place of counter ids (CASSANDRA-7366) * Fix native protocol CAS batches (CASSANDRA-7337) + * Reduce likelihood of contention on local paxos locking (CASSANDRA-7359) + * Upgrade to Pig 0.12.1 (CASSANDRA-6556) + * Make sure we clear out repair sessions from netstats (CASSANDRA-7329) + * Don't fail streams on failure detector downs (CASSANDRA-3569) + * Add optional keyspace to DROP INDEX statement (CASSANDRA-7314) + * Reduce run time for CQL tests (CASSANDRA-7327) + * Fix heap size calculation on Windows (CASSANDRA-7352, 7353) + * RefCount native frames from netty (CASSANDRA-7245) + * Use tarball dir instead of /var for default paths (CASSANDRA-7136) + * Remove rows_per_partition_to_cache keyword (CASSANDRA-7193) +Merged from 2.0: + * Fix assertion error in CL.ANY timeout handling (CASSANDRA-7364) * Add per-CF range read request latency metrics (CASSANDRA-7338) * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323) - * Add conditional CREATE/DROP USER support (CASSANDRA-7264) - * Swap local and global default read repair chances (CASSANDRA-7320) - * Add missing iso8601 patterns for date strings (CASSANDRA-6973) - * Support selecting multiple rows in a partition using IN (CASSANDRA-6875) - * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274) - * Copy compaction options to make sure they are reloaded (CASSANDRA-7290) - * Add option to do more aggressive tombstone compactions (CASSANDRA-6563) - * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288) - * Add authentication support to shuffle (CASSANDRA-6484) - * Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325) * Make StreamSession#closeSession() idempotent (CASSANDRA-7262) * Fix infinite loop on exception while streaming (CASSANDRA-7330) - * Reference sstables before populating key cache (CASSANDRA-7234) + * Account for range tombstones in min/max column names (CASSANDRA-7235) Merged from 1.2: * cqlsh: ignore .cassandra permission errors (CASSANDRA-7266) * Errors in FlushRunnable may leave threads hung (CASSANDRA-7275) http://git-wip-us.apache.org/repos/asf/cassandra/blob/3ff7a776/src/java/org/apache/cassandra/db/ColumnFamily.java -- diff --cc src/java/org/apache/cassandra/db/ColumnFamily.java index 45b8eff,638eacc..38e1591 --- a/src/java/org/apache/cassandra/db/ColumnFamily.java +++ b/src/java/org/apache/cassandra/db/ColumnFamily.java @@@ -402,36 -418,31 +402,41 @@@ public abstract class ColumnFamily impl int maxLocalDeletionTime = Integer.MIN_VALUE; ListByteBuffer minColumnNamesSeen = Collections.emptyList(); ListByteBuffer maxColumnNamesSeen = Collections.emptyList(); +boolean hasLegacyCounterShards = false; + + if (deletionInfo().getTopLevelDeletion().localDeletionTime Integer.MAX_VALUE) + tombstones.update(deletionInfo().getTopLevelDeletion().localDeletionTime); + IteratorRangeTombstone it =
[jira] [Updated] (CASSANDRA-7418) Cannot upgrade: Tried to create duplicate hard link
[ https://issues.apache.org/jira/browse/CASSANDRA-7418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom van den Berge updated CASSANDRA-7418: - Environment: OSX Cannot upgrade: Tried to create duplicate hard link --- Key: CASSANDRA-7418 URL: https://issues.apache.org/jira/browse/CASSANDRA-7418 Project: Cassandra Issue Type: Bug Environment: OSX Reporter: Tom van den Berge Priority: Critical I'm trying to migrate a cluster from 1.2.14 to 2.0.8. When starting up 2.0.8, I'm seeing the following error in the logs: INFO 17:40:25,405 Snapshotting drillster, Account to pre-sstablemetamigration ERROR 17:40:25,407 Exception encountered during startup java.lang.RuntimeException: Tried to create duplicate hard link to /Users/tom/cassandra-data/data/drillster/Account/snapshots/pre-sstablemetamigration/drillster-Account-ic-65-Filter.db at org.apache.cassandra.io.util.FileUtils.createHardLink(FileUtils.java:75) at org.apache.cassandra.db.compaction.LegacyLeveledManifest.snapshotWithoutCFS(LegacyLeveledManifest.java:129) at org.apache.cassandra.db.compaction.LegacyLeveledManifest.migrateManifests(LegacyLeveledManifest.java:91) at org.apache.cassandra.db.compaction.LeveledManifest.maybeMigrateManifests(LeveledManifest.java:617) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:274) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585) As a result, I can't start up 2.0.8, and switching back to 1.2.14 also doesn't work. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CASSANDRA-7062) Extension of static columns for compound cluster keys
[
https://issues.apache.org/jira/browse/CASSANDRA-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-7062.
-
Resolution: Won't Fix
Extension of static columns for compound cluster keys
-
Key: CASSANDRA-7062
URL: https://issues.apache.org/jira/browse/CASSANDRA-7062
Project: Cassandra
Issue Type: New Feature
Reporter: Constance Eustace
CASSANDRA-6561 implemented static columns for a given partition key.
What this is proposing for a compound cluster key is a static column that is
static at intermediate parts of a compound cluster key. This example shows a
table modelling a moderately complex EAV pattern :
{code}
CREATE TABLE t (
entityID text,
propertyName text,
valueIndex text,
entityName text static (entityID),
propertyType text static (entityID, propertyName),
propertyRelations Listtext static (entityID, propertyName),
data text,
PRIMARY KEY (entityID, (propertyName,valueIndex))
)
{code}
So in this example has the following static columns:
- the entityName column behaves exactly as CASSANDRA-6561 details, so all
cluster rows have the same value
- the propertyType and propertyRelations columns are static with respect to
the remaining parts of the cluster key (that is, across all valueIndex values
for a given propertyName), so an update to those values for an entityID and a
propertyName will be shared/constant by all the value rows...
Is this a relatively simple extension of the same mechanism in -6561, or is
this a whoa, you have no idea what you are proposing?
Sample data:
Mary and Jane aren't married...
{code}
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0001','MARY MATALIN','married','SingleValue','0','false');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0002','JANE JOHNSON','married','SingleValue','0','false');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex)
VALUES ('0001','MARY MATALIN','kids','NOVALUE','');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex)
VALUES ('0002','JANE JOHNSON','kids','NOVALUE','');
{code}
{code}
SELECT * FROM t:
0001 MARY MATALIN married SingleValue 0 false
0001 MARY MATALIN kids NOVALUE null
0002 JANE JOHNSON married SingleValue 0 false
0002 JANE JOHNSON kids NOVALUE null
{code}
Then mary and jane get married (so the entityName column that is static on
the partition key is updated just like CASSANDRA-6561 )
{code}
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0001','MARY SMITH','married','SingleValue','0','TRUE');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0002','JANE JONES','married','SingleValue','0','TRUE');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids NOVALUE null
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids NOVALUE null
{code}
Then mary and jane have a kid, so we add another value to the kids attribute:
{code}
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0001','kids','SingleValue','0','JIM-BOB');
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0002','kids','SingleValue','0','JENNY');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids SingleValuenull
0001 MARY SMITH kids SingleValue 0 JIM-BOB
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids SingleValuenull
0002 JANE JONES kids SingleValue 0 JENNY
{code}
Then Mary has ANOTHER kid, which demonstrates the partially static column
relative to the cluster key, as ALL value rows for the property 'kids' get
updated to the new value:
{code}
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0001','kids','MultiValue','1','HARRY');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids MultiValue null
0001 MARY SMITH kids MultiValue 0 JIM-BOB
0001 MARY SMITH kids MultiValue 1 HARRY
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids SingleValuenull
0002 JANE JONES kids SingleValue 0 JENNY
{code}
... ok, hopefully that example isn't TOO complicated. Yes, there's a stupid
hack bug in there with the null/empty row for the kids attribute, but please
bear with me on that
Generally speaking, this will
[jira] [Commented] (CASSANDRA-7062) Extension of static columns for compound cluster keys
[
https://issues.apache.org/jira/browse/CASSANDRA-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037149#comment-14037149
]
Sylvain Lebresne commented on CASSANDRA-7062:
-
This is definitively *a lot* more complicated than the simple static columns we
have (even without considering any future change) and honestly not worth the
complexity so closing as 'won't fix'. If someday the storage engine has change
enough that it's trivial to implement, then I'd be happy to reconsider but
we've far from that.
As an aside of this is really complicated, I'm also not too convinced that
it's all that useful in practice. I'm pretty sure that in most case you can get
something equivalent with a mix of collections and UDT.
Extension of static columns for compound cluster keys
-
Key: CASSANDRA-7062
URL: https://issues.apache.org/jira/browse/CASSANDRA-7062
Project: Cassandra
Issue Type: New Feature
Reporter: Constance Eustace
CASSANDRA-6561 implemented static columns for a given partition key.
What this is proposing for a compound cluster key is a static column that is
static at intermediate parts of a compound cluster key. This example shows a
table modelling a moderately complex EAV pattern :
{code}
CREATE TABLE t (
entityID text,
propertyName text,
valueIndex text,
entityName text static (entityID),
propertyType text static (entityID, propertyName),
propertyRelations Listtext static (entityID, propertyName),
data text,
PRIMARY KEY (entityID, (propertyName,valueIndex))
)
{code}
So in this example has the following static columns:
- the entityName column behaves exactly as CASSANDRA-6561 details, so all
cluster rows have the same value
- the propertyType and propertyRelations columns are static with respect to
the remaining parts of the cluster key (that is, across all valueIndex values
for a given propertyName), so an update to those values for an entityID and a
propertyName will be shared/constant by all the value rows...
Is this a relatively simple extension of the same mechanism in -6561, or is
this a whoa, you have no idea what you are proposing?
Sample data:
Mary and Jane aren't married...
{code}
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0001','MARY MATALIN','married','SingleValue','0','false');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0002','JANE JOHNSON','married','SingleValue','0','false');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex)
VALUES ('0001','MARY MATALIN','kids','NOVALUE','');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex)
VALUES ('0002','JANE JOHNSON','kids','NOVALUE','');
{code}
{code}
SELECT * FROM t:
0001 MARY MATALIN married SingleValue 0 false
0001 MARY MATALIN kids NOVALUE null
0002 JANE JOHNSON married SingleValue 0 false
0002 JANE JOHNSON kids NOVALUE null
{code}
Then mary and jane get married (so the entityName column that is static on
the partition key is updated just like CASSANDRA-6561 )
{code}
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0001','MARY SMITH','married','SingleValue','0','TRUE');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0002','JANE JONES','married','SingleValue','0','TRUE');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids NOVALUE null
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids NOVALUE null
{code}
Then mary and jane have a kid, so we add another value to the kids attribute:
{code}
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0001','kids','SingleValue','0','JIM-BOB');
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0002','kids','SingleValue','0','JENNY');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids SingleValuenull
0001 MARY SMITH kids SingleValue 0 JIM-BOB
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids SingleValuenull
0002 JANE JONES kids SingleValue 0 JENNY
{code}
Then Mary has ANOTHER kid, which demonstrates the partially static column
relative to the cluster key, as ALL value rows for the property 'kids' get
updated to the new value:
{code}
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0001','kids','MultiValue','1','HARRY');
{code}
{code}
SELECT * FROM t:
0001
buildbot failure in ASF Buildbot on cassandra-2.0
The Buildbot has detected a new failure on builder cassandra-2.0 while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-2.0/builds/86 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch cassandra-2.0] 303ff22dd608d4971a12de52f91184dcd82895c0 Blamelist: Marcus Eriksson marc...@apache.org BUILD FAILED: failed shell sincerely, -The Buildbot
[jira] [Commented] (CASSANDRA-7418) Cannot upgrade: Tried to create duplicate hard link
[ https://issues.apache.org/jira/browse/CASSANDRA-7418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037157#comment-14037157 ] Marcus Eriksson commented on CASSANDRA-7418: IIRC this happens if you try upgrading twice, maybe something (else) went wrong the first time? I guess you can try removing the old snapshot (or just renaming the directory should be enough) and then trying to upgrade again Cannot upgrade: Tried to create duplicate hard link --- Key: CASSANDRA-7418 URL: https://issues.apache.org/jira/browse/CASSANDRA-7418 Project: Cassandra Issue Type: Bug Environment: OSX Reporter: Tom van den Berge Priority: Critical I'm trying to migrate a cluster from 1.2.14 to 2.0.8. When starting up 2.0.8, I'm seeing the following error in the logs: INFO 17:40:25,405 Snapshotting drillster, Account to pre-sstablemetamigration ERROR 17:40:25,407 Exception encountered during startup java.lang.RuntimeException: Tried to create duplicate hard link to /Users/tom/cassandra-data/data/drillster/Account/snapshots/pre-sstablemetamigration/drillster-Account-ic-65-Filter.db at org.apache.cassandra.io.util.FileUtils.createHardLink(FileUtils.java:75) at org.apache.cassandra.db.compaction.LegacyLeveledManifest.snapshotWithoutCFS(LegacyLeveledManifest.java:129) at org.apache.cassandra.db.compaction.LegacyLeveledManifest.migrateManifests(LegacyLeveledManifest.java:91) at org.apache.cassandra.db.compaction.LeveledManifest.maybeMigrateManifests(LeveledManifest.java:617) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:274) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585) As a result, I can't start up 2.0.8, and switching back to 1.2.14 also doesn't work. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037158#comment-14037158 ] Oded Peer commented on CASSANDRA-7304: -- I think it's confusing since it's applicable to regular statements as well. The following statements all do the same thing: UPDATE table SET column = 3 WHERE key = 2; UPDATE table USING IGNORE_NULLS true SET column = 3 WHERE key = 2; UPDATE table USING IGNORE_NULLS false SET column = 3 WHERE key = 2; I would like to avoid having more than one way to perform an action Ability to distinguish between NULL and UNSET values in Prepared Statements --- Key: CASSANDRA-7304 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304 Project: Cassandra Issue Type: Improvement Reporter: Drew Kutcharian Currently Cassandra inserts tombstones when a value of a column is bound to NULL in a prepared statement. At higher insert rates managing all these tombstones becomes an unnecessary overhead. This limits the usefulness of the prepared statements since developers have to either create multiple prepared statements (each with a different combination of column names, which at times is just unfeasible because of the sheer number of possible combinations) or fall back to using regular (non-prepared) statements. This JIRA is here to explore the possibility of either: A. Have a flag on prepared statements that once set, tells Cassandra to ignore null columns or B. Have an UNSET value which makes Cassandra skip the null columns and not tombstone them Basically, in the context of a prepared statement, a null value means delete, but we don’t have anything that means ignore (besides creating a new prepared statement without the ignored column). Please refer to the original conversation on DataStax Java Driver mailing list for more background: https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037175#comment-14037175
]
Sylvain Lebresne commented on CASSANDRA-7304:
-
How does having the option at the protocol level change this in any way? You're
just hiding things a bit more making it easier for people to don't understand
what's going on, but you'll still have statements with 'ignore null' set but
who don't set any value to null. Besides, there's many way to have 2 different
statements doing the same thing so it's not like we'd create some kind of
horrible inconsistency. Take:
{noformat}
UPDATE table SET s = s + { 3 }, s = s + { 4 } WHERE k = 2;
UPDATE table SET s = s + { 3, 4 } WHERE k = 2;
UPDATE table SET s = s + { 3, 4 } WHERE k = blobAsInt(intAsBlob(2));
{noformat}
Besides, people are not stupid. No-one will get completely confused that
IGNORE_NULLS is a no-op if there is no null in the query.
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Improvement
Reporter: Drew Kutcharian
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new
prepared statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing
list for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CASSANDRA-7413) Native Protocol V3 CREATE Response
[ https://issues.apache.org/jira/browse/CASSANDRA-7413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne reassigned CASSANDRA-7413: --- Assignee: Sylvain Lebresne Native Protocol V3 CREATE Response -- Key: CASSANDRA-7413 URL: https://issues.apache.org/jira/browse/CASSANDRA-7413 Project: Cassandra Issue Type: Task Reporter: Robert Stupp Assignee: Sylvain Lebresne Native protocol v3 changes the EVENT (opcode 12) SCHEMA_CHANGE to include the target type that changed : changetargetkeyspacename. The RESULT (opcode 8) SCHEMA_CHANGE has the old layout (changekeyspacetable. Is this difference intentional or does the protocol spec needs change for RESULT/SCHEMA_CHANGE? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7413) Native Protocol V3 CREATE Response
[ https://issues.apache.org/jira/browse/CASSANDRA-7413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-7413: Fix Version/s: 2.1 rc2 Native Protocol V3 CREATE Response -- Key: CASSANDRA-7413 URL: https://issues.apache.org/jira/browse/CASSANDRA-7413 Project: Cassandra Issue Type: Task Reporter: Robert Stupp Assignee: Sylvain Lebresne Fix For: 2.1 rc2 Attachments: 7413.txt Native protocol v3 changes the EVENT (opcode 12) SCHEMA_CHANGE to include the target type that changed : changetargetkeyspacename. The RESULT (opcode 8) SCHEMA_CHANGE has the old layout (changekeyspacetable. Is this difference intentional or does the protocol spec needs change for RESULT/SCHEMA_CHANGE? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7413) Native Protocol V3 CREATE Response
[ https://issues.apache.org/jira/browse/CASSANDRA-7413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-7413: Attachment: 7413.txt It's an oversight. There is no reason to do a difference between the response we send on a schema change, and the schema change event. Attaching simple patch to fix the discrepancy (the patch makes sure we reuse the same code in both case too so we don't have to update 2 places next time we change something). Native Protocol V3 CREATE Response -- Key: CASSANDRA-7413 URL: https://issues.apache.org/jira/browse/CASSANDRA-7413 Project: Cassandra Issue Type: Task Reporter: Robert Stupp Assignee: Sylvain Lebresne Fix For: 2.1 rc2 Attachments: 7413.txt Native protocol v3 changes the EVENT (opcode 12) SCHEMA_CHANGE to include the target type that changed : changetargetkeyspacename. The RESULT (opcode 8) SCHEMA_CHANGE has the old layout (changekeyspacetable. Is this difference intentional or does the protocol spec needs change for RESULT/SCHEMA_CHANGE? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7351) Make BEGIN COUNTER BATCH syntax optional
[ https://issues.apache.org/jira/browse/CASSANDRA-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-7351: Fix Version/s: (was: 2.1.0) 2.1 rc2 Make BEGIN COUNTER BATCH syntax optional Key: CASSANDRA-7351 URL: https://issues.apache.org/jira/browse/CASSANDRA-7351 Project: Cassandra Issue Type: Improvement Reporter: T Jake Luciani Assignee: T Jake Luciani Priority: Trivial Labels: cql3 Fix For: 2.1 rc2 Attachments: 7351-rebase.txt, 7351.txt, 7351v2.txt AFAIK there is no need to supply COUNTER in Batch statements. The server should just throw an syntax error if you try to mix counter and non counter statements in the same batch. What value does this keyword add? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-6755) Optimise CellName/Composite comparisons for NativeCell
[ https://issues.apache.org/jira/browse/CASSANDRA-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-6755: Fix Version/s: (was: 2.1.0) 2.1 rc2 Optimise CellName/Composite comparisons for NativeCell -- Key: CASSANDRA-6755 URL: https://issues.apache.org/jira/browse/CASSANDRA-6755 Project: Cassandra Issue Type: Improvement Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc2 Attachments: 6755.txt, 6755v2.txt As discussed in CASSANDRA-6694, to reduce temporary garbage generation we should minimise the incidence of CellName component extraction. The biggest win will be to perform comparisons on Cell where possible, instead of CellName, so that Native*Cell can use its extra information to avoid creating any ByteBuffer objects -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7373) Commit logs no longer deleting and MemtablePostFlusher pending growing
[
https://issues.apache.org/jira/browse/CASSANDRA-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-7373:
Fix Version/s: (was: 2.1.0)
2.1 rc2
Commit logs no longer deleting and MemtablePostFlusher pending growing
--
Key: CASSANDRA-7373
URL: https://issues.apache.org/jira/browse/CASSANDRA-7373
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: RHEL 6.5
Cassandra 1.12.16
Replication factor of 3
Reporter: Francois Richard
Assignee: Mikhail Stepura
Fix For: 1.2.17, 2.0.9, 2.1 rc2
Attachments: 0001-Move-latch.countDown-into-finally-block.patch,
0002-Handle-possible-integer-overflow.patch, 7373-v2.txt
We have this issue where once in a while, we get into a situation where the
MemtablePostFlusher is not executing and the space used by the commit logs on
disks keeps on increasing and increasing.
We can observe the problem by invoking nodetool tpstats:
{code}
Pool NameActive Pending Completed Blocked All
time blocked
ReadStage 6 6 46650213 0
0
RequestResponseStage 0 0 130547421 0
0
MutationStage 2 2 116813206 0
0
ReadRepairStage 0 02322201 0
0
ReplicateOnWriteStage 0 0 0 0
0
GossipStage 0 0 120780 0
0
AntiEntropyStage 0 0 0 0
0
MigrationStage0 0 0 0
0
MemoryMeter 0 0456 0
0
MemtablePostFlusher 1 447 6344 0
0
FlushWriter 0 0 6132 0
62
MiscStage 0 0 0 0
0
PendingRangeCalculator0 0 6 0
0
commitlog_archiver0 0 0 0
0
InternalResponseStage 0 0 0 0
0
HintedHandoff 2 2 4 0
0
Message type Dropped
RANGE_SLICE 0
READ_REPAIR 0
BINARY 0
READ 0
MUTATION 0
_TRACE 0
REQUEST_RESPONSE 0
COUNTER_MUTATION 0
{code}
Here is a potential error in the logs that can explain this:
{code}
ERROR [FlushWriter:2693] 2014-06-09 22:05:38,452 CassandraDaemon.java (line
191) Exception in thread Thread[FlushWriter:2693,5,main]
java.lang.NegativeArraySizeException
at
org.apache.cassandra.io.util.FastByteArrayOutputStream.expand(FastByteArrayOutputStream.java:104)
at
org.apache.cassandra.io.util.FastByteArrayOutputStream.write(FastByteArrayOutputStream.java:220)
at java.io.DataOutputStream.write(DataOutputStream.java:107)
at
org.apache.cassandra.io.util.DataOutputBuffer.write(DataOutputBuffer.java:60)
at
org.apache.cassandra.utils.ByteBufferUtil.write(ByteBufferUtil.java:328)
at
org.apache.cassandra.utils.ByteBufferUtil.writeWithLength(ByteBufferUtil.java:315)
at
org.apache.cassandra.db.ColumnSerializer.serialize(ColumnSerializer.java:55)
at
org.apache.cassandra.db.ColumnSerializer.serialize(ColumnSerializer.java:30)
at
org.apache.cassandra.db.OnDiskAtom$Serializer.serializeForSSTable(OnDiskAtom.java:62)
at org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:181)
at
org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:133)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:185)
at
org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:430)
at
org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:385)
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7407) COPY command does not work properly with collections causing failure to import data
[
https://issues.apache.org/jira/browse/CASSANDRA-7407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-7407:
Reviewer: Brandon Williams (was: Aleksey Yeschenko)
Reproduced In: 2.0.7, 1.2.16 (was: 1.2.16, 2.0.7)
Fix Version/s: 2.1 rc2
Labels: (was: patch)
+1
COPY command does not work properly with collections causing failure to
import data
---
Key: CASSANDRA-7407
URL: https://issues.apache.org/jira/browse/CASSANDRA-7407
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: cqlsh 4.1.1,
Cassandra 2.0.7.31,
CQL spec 3.1.1,
Thrift protocol 19.39.0
Reporter: Jose Martinez Poblete
Assignee: Mikhail Stepura
Fix For: 1.2.17, 2.0.9, 2.1 rc2
Attachments: CASSANDRA-1.2-7407.patch
The COPY command does not properly format collections in the output CSV - to
be able to re-import the data.
Here is how you can replicate the problem:
{noformat}
CREATE TABLE user_colors (
user_id int PRIMARY KEY,
colors listascii
);
UPDATE user_colors SET colors = ['red','blue'] WHERE user_id=5;
UPDATE user_colors SET colors = ['purple','yellow'] WHERE user_id=6;
UPDATE user_colors SET colors = ['black''] WHERE user_id=7;
COPY user_colors (user_id, colors) TO 'output.csv';
CREATE TABLE user_colors2 (
user_id int PRIMARY KEY,
colors listascii
);
COPY user_colors2 (user_id, colors ) FROM 'user_colors.csv';
Bad Request: line 1:68 no viable alternative at input ']'
Aborting import at record #0 (line 1). Previously-inserted values still
present.
0 rows imported in 0.007 seconds.
{noformat}
The CSV file seems to be malformed
- The single quotes within the collection are missing
- The double quotes for collection on user_id=7 are missing and causing COPY
to fail.
{noformat}
5,[red, blue]
7,[black]
6,[purple, yellow]
{noformat}
Should be like this
{noformat}
5,['red', 'blue']
7,['black']
6,['purple', 'yellow']
{noformat}
Once the file is changed, the import works
{noformat}
COPY user_colors2 (user_id, colors ) FROM 'user_colors.csv';
3 rows imported in 0.012 seconds.
SELECT * FROM user_colors2;
user_id | colors
-+--
5 | [red, blue]
7 | [black]
6 | [purple, yellow]
(3 rows)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7346) Modify reconcile logic to always pick a tombstone over a counter cell
[
https://issues.apache.org/jira/browse/CASSANDRA-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037334#comment-14037334
]
Sylvain Lebresne commented on CASSANDRA-7346:
-
Lgtm, +1.
One small nit: I'd put some isLive() in DeletionTime and replace the
{{topLevel.markedForDeleteAt Long.MIN_VALUE}} by {{!topLevel.isLive()}}.
Feels more explicit/readable.
Modify reconcile logic to always pick a tombstone over a counter cell
-
Key: CASSANDRA-7346
URL: https://issues.apache.org/jira/browse/CASSANDRA-7346
Project: Cassandra
Issue Type: Improvement
Reporter: Richard Low
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 2.1 rc2
For counters, timestamps are automatically computed to be milliseconds since
the epoch. For everything else, when not specified manually, they are
microseconds since the epoch. This means if you delete a counter row,
subsequent updates are lost unexpectedly.
I know that deleting counters is not recommended, but that's only because
deletes and incs don't commute. If you know you have stopped incs, then
delete, then start again (with some external synchronization) then deleting
is fine.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6766) allow now() - uuid compatibility
[ https://issues.apache.org/jira/browse/CASSANDRA-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037350#comment-14037350 ] Sylvain Lebresne commented on CASSANDRA-6766: - bq. ReversedType makes the isValueCompatibleWith() logic a little hairy. Why can't we just add a ReversedType.isValueCompatibleWith override that calls isValueCompatibleWith on the base type? allow now() - uuid compatibility - Key: CASSANDRA-6766 URL: https://issues.apache.org/jira/browse/CASSANDRA-6766 Project: Cassandra Issue Type: Bug Components: API Reporter: Jonathan Ellis Assignee: Tyler Hobbs Priority: Minor Labels: cql Fix For: 2.0.9 Attachments: 6766.txt Bad Request: Type error: cannot assign result of function now (type timeuuid) to id (type uuid) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6839) Support non equal conditions (for LWT)
[
https://issues.apache.org/jira/browse/CASSANDRA-6839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037389#comment-14037389
]
Sylvain Lebresne commented on CASSANDRA-6839:
-
Mostly looks good, a few minor remarks:
* Should include operator in ColumnCondition.Bound hashCode methods.
* In ColumnCondition.setAppliesTo and mapAppliesTo, the Set/Map in parameter
are already properly sorted (Sets/Maps.Value make sure of that) so we can
iterate on them directly and save the allocation/copy (the previous logic was
creating new TreeSet/TreeMap for other reasons that were misguided).
* Note sure why CFDefinition.Name is made @VisibleForTesting?
* What's the reason for removing the lines in
MultiColumnRelationTest.testMultipleClusteringColumnInequalityReversedComponents.
bq. It seems like we should also add support for IN. I can add do that in this
ticket, if we'd like, or I can create a new ticket for that.
Agreed that it's worth adding. I don't mind if we move that to a follow up
ticket, though if we do then I think we need to validate it's currently not
used for conditions (I don't think it's done currently and so an AssertionError
will be thrown). Maybe it's easier to just go ahead and add support to this
patch directly (unless it adds too much complexity but it sounds like it
shouldn't)?
Support non equal conditions (for LWT)
--
Key: CASSANDRA-6839
URL: https://issues.apache.org/jira/browse/CASSANDRA-6839
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Tyler Hobbs
Priority: Minor
Fix For: 2.0.9
Attachments: 6839.txt
We currently only support equal conditions in conditional updates, but it
would be relatively trivial to support non-equal ones as well. At the very
least we should support '', '=', '' and '=', though it would probably
also make sense to add a non-equal relation too ('!=').
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7373) Commit logs no longer deleting and MemtablePostFlusher pending growing
[
https://issues.apache.org/jira/browse/CASSANDRA-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037434#comment-14037434
]
Jonathan Ellis commented on CASSANDRA-7373:
---
+1
Commit logs no longer deleting and MemtablePostFlusher pending growing
--
Key: CASSANDRA-7373
URL: https://issues.apache.org/jira/browse/CASSANDRA-7373
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: RHEL 6.5
Cassandra 1.12.16
Replication factor of 3
Reporter: Francois Richard
Assignee: Mikhail Stepura
Fix For: 1.2.17, 2.0.9, 2.1 rc2
Attachments: 0001-Move-latch.countDown-into-finally-block.patch,
0002-Handle-possible-integer-overflow.patch, 7373-v2.txt
We have this issue where once in a while, we get into a situation where the
MemtablePostFlusher is not executing and the space used by the commit logs on
disks keeps on increasing and increasing.
We can observe the problem by invoking nodetool tpstats:
{code}
Pool NameActive Pending Completed Blocked All
time blocked
ReadStage 6 6 46650213 0
0
RequestResponseStage 0 0 130547421 0
0
MutationStage 2 2 116813206 0
0
ReadRepairStage 0 02322201 0
0
ReplicateOnWriteStage 0 0 0 0
0
GossipStage 0 0 120780 0
0
AntiEntropyStage 0 0 0 0
0
MigrationStage0 0 0 0
0
MemoryMeter 0 0456 0
0
MemtablePostFlusher 1 447 6344 0
0
FlushWriter 0 0 6132 0
62
MiscStage 0 0 0 0
0
PendingRangeCalculator0 0 6 0
0
commitlog_archiver0 0 0 0
0
InternalResponseStage 0 0 0 0
0
HintedHandoff 2 2 4 0
0
Message type Dropped
RANGE_SLICE 0
READ_REPAIR 0
BINARY 0
READ 0
MUTATION 0
_TRACE 0
REQUEST_RESPONSE 0
COUNTER_MUTATION 0
{code}
Here is a potential error in the logs that can explain this:
{code}
ERROR [FlushWriter:2693] 2014-06-09 22:05:38,452 CassandraDaemon.java (line
191) Exception in thread Thread[FlushWriter:2693,5,main]
java.lang.NegativeArraySizeException
at
org.apache.cassandra.io.util.FastByteArrayOutputStream.expand(FastByteArrayOutputStream.java:104)
at
org.apache.cassandra.io.util.FastByteArrayOutputStream.write(FastByteArrayOutputStream.java:220)
at java.io.DataOutputStream.write(DataOutputStream.java:107)
at
org.apache.cassandra.io.util.DataOutputBuffer.write(DataOutputBuffer.java:60)
at
org.apache.cassandra.utils.ByteBufferUtil.write(ByteBufferUtil.java:328)
at
org.apache.cassandra.utils.ByteBufferUtil.writeWithLength(ByteBufferUtil.java:315)
at
org.apache.cassandra.db.ColumnSerializer.serialize(ColumnSerializer.java:55)
at
org.apache.cassandra.db.ColumnSerializer.serialize(ColumnSerializer.java:30)
at
org.apache.cassandra.db.OnDiskAtom$Serializer.serializeForSSTable(OnDiskAtom.java:62)
at org.apache.cassandra.db.ColumnIndex$Builder.add(ColumnIndex.java:181)
at
org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:133)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:185)
at
org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:430)
at
org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:385)
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6839) Support non equal conditions (for LWT)
[
https://issues.apache.org/jira/browse/CASSANDRA-6839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037442#comment-14037442
]
Sylvain Lebresne commented on CASSANDRA-6839:
-
bq. Note sure why CFDefinition.Name is made @VisibleForTesting?
Nevermind this one. Crappy git manipulation made me miss the added
ColumnConditionTest file that uses that.
Support non equal conditions (for LWT)
--
Key: CASSANDRA-6839
URL: https://issues.apache.org/jira/browse/CASSANDRA-6839
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Tyler Hobbs
Priority: Minor
Fix For: 2.0.9
Attachments: 6839.txt
We currently only support equal conditions in conditional updates, but it
would be relatively trivial to support non-equal ones as well. At the very
least we should support '', '=', '' and '=', though it would probably
also make sense to add a non-equal relation too ('!=').
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6766) allow now() - uuid compatibility
[
https://issues.apache.org/jira/browse/CASSANDRA-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037454#comment-14037454
]
Tyler Hobbs commented on CASSANDRA-6766:
Because you have to assume that you're always calling
{{someReversedTypeInstance.isValueCompatibleWith(someOtherType)}} (i.e.,
{{LongType.instance.isValueCompatibleWith(ReversedType.getInstance(LongType.instance))}}
would return false). With the current usage, that would work, but it seems
very prone to bugs.
allow now() - uuid compatibility
-
Key: CASSANDRA-6766
URL: https://issues.apache.org/jira/browse/CASSANDRA-6766
Project: Cassandra
Issue Type: Bug
Components: API
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
Priority: Minor
Labels: cql
Fix For: 2.0.9
Attachments: 6766.txt
Bad Request: Type error: cannot assign result of function now (type timeuuid)
to id (type uuid)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6839) Support non equal conditions (for LWT)
[
https://issues.apache.org/jira/browse/CASSANDRA-6839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037459#comment-14037459
]
Tyler Hobbs commented on CASSANDRA-6839:
bq. What's the reason for removing the lines in
MultiColumnRelationTest.testMultipleClusteringColumnInequalityReversedComponents.
Adding a new unit test changed the ordering of the tests. Since that test
added rows that none of the other tests did, it caused a failure in another
test with the new order. The fix in this patch is pretty lame, but since the
tests are done the Right Way in 2.1, I didn't go through too much trouble to
fix it.
bq. Maybe it's easier to just go ahead and add support to this patch directly
(unless it adds too much complexity but it sounds like it shouldn't)?
It shouldn't add too much complexity. I'll add it here.
Support non equal conditions (for LWT)
--
Key: CASSANDRA-6839
URL: https://issues.apache.org/jira/browse/CASSANDRA-6839
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Tyler Hobbs
Priority: Minor
Fix For: 2.0.9
Attachments: 6839.txt
We currently only support equal conditions in conditional updates, but it
would be relatively trivial to support non-equal ones as well. At the very
least we should support '', '=', '' and '=', though it would probably
also make sense to add a non-equal relation too ('!=').
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7254) NPE on startup if another Cassandra instance is already running
[
https://issues.apache.org/jira/browse/CASSANDRA-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-7254:
---
Fix Version/s: 2.1.0
NPE on startup if another Cassandra instance is already running
---
Key: CASSANDRA-7254
URL: https://issues.apache.org/jira/browse/CASSANDRA-7254
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Priority: Minor
Fix For: 2.1.0
After CASSANDRA-7087, if you try to start cassandra while another instance is
already running, you'll see something like this:
{noformat}
$ bin/cassandra -f
Error: Exception thrown by the agent : java.lang.NullPointerException
{noformat}
This is probably a JVM bug, but we should confirm that, open a JVM ticket,
and see if we can give a more useful error message on the C* side.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CASSANDRA-7254) NPE on startup if another Cassandra instance is already running
[
https://issues.apache.org/jira/browse/CASSANDRA-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs reassigned CASSANDRA-7254:
--
Assignee: Chris Lohfink
[~cnlwsu] can you take this one?
NPE on startup if another Cassandra instance is already running
---
Key: CASSANDRA-7254
URL: https://issues.apache.org/jira/browse/CASSANDRA-7254
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Chris Lohfink
Priority: Minor
Fix For: 2.1.0
After CASSANDRA-7087, if you try to start cassandra while another instance is
already running, you'll see something like this:
{noformat}
$ bin/cassandra -f
Error: Exception thrown by the agent : java.lang.NullPointerException
{noformat}
This is probably a JVM bug, but we should confirm that, open a JVM ticket,
and see if we can give a more useful error message on the C* side.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6766) allow now() - uuid compatibility
[
https://issues.apache.org/jira/browse/CASSANDRA-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037477#comment-14037477
]
Sylvain Lebresne commented on CASSANDRA-6766:
-
Fair enough, Then what about splitting into 2 methods: the real
{{isValueCompatibleWith}} in AbstractType would check if the argument is
ReversedType and if so, would unwrap it, and otherwise would call an
auxiliary {{isValueCompatibleWithInternal}} which is the one the subclasses
would override. Not absolutely sublime, but at least deal with ReversedType in
one place versus doing it in very override of isValueCompatibleWith.
allow now() - uuid compatibility
-
Key: CASSANDRA-6766
URL: https://issues.apache.org/jira/browse/CASSANDRA-6766
Project: Cassandra
Issue Type: Bug
Components: API
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
Priority: Minor
Labels: cql
Fix For: 2.0.9
Attachments: 6766.txt
Bad Request: Type error: cannot assign result of function now (type timeuuid)
to id (type uuid)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
git commit: ninja assert
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 3ff7a776a - 4f381a2a6
ninja assert
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4f381a2a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4f381a2a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4f381a2a
Branch: refs/heads/cassandra-2.1
Commit: 4f381a2a60c95bba9b3d7153aab8db504b3b7720
Parents: 3ff7a77
Author: Jake Luciani j...@apache.org
Authored: Thu Jun 19 12:18:58 2014 -0400
Committer: Jake Luciani j...@apache.org
Committed: Thu Jun 19 12:18:58 2014 -0400
--
src/java/org/apache/cassandra/db/RangeTombstoneList.java | 2 ++
1 file changed, 2 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4f381a2a/src/java/org/apache/cassandra/db/RangeTombstoneList.java
--
diff --git a/src/java/org/apache/cassandra/db/RangeTombstoneList.java
b/src/java/org/apache/cassandra/db/RangeTombstoneList.java
index 757a1d0..fd2e100 100644
--- a/src/java/org/apache/cassandra/db/RangeTombstoneList.java
+++ b/src/java/org/apache/cassandra/db/RangeTombstoneList.java
@@ -128,6 +128,8 @@ public class RangeTombstoneList implements
IterableRangeTombstone, IMeasurable
for (int i = 0; i size; i++)
{
+assert !(starts[i] instanceof AbstractNativeCell || ends[i]
instanceof AbstractNativeCell); //this should never happen
+
copy.starts[i] = starts[i].copy(null, allocator);
copy.ends[i] = ends[i].copy(null, allocator);
}
[4/9] git commit: ninja assert
ninja assert
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4f381a2a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4f381a2a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4f381a2a
Branch: refs/heads/trunk
Commit: 4f381a2a60c95bba9b3d7153aab8db504b3b7720
Parents: 3ff7a77
Author: Jake Luciani j...@apache.org
Authored: Thu Jun 19 12:18:58 2014 -0400
Committer: Jake Luciani j...@apache.org
Committed: Thu Jun 19 12:18:58 2014 -0400
--
src/java/org/apache/cassandra/db/RangeTombstoneList.java | 2 ++
1 file changed, 2 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4f381a2a/src/java/org/apache/cassandra/db/RangeTombstoneList.java
--
diff --git a/src/java/org/apache/cassandra/db/RangeTombstoneList.java
b/src/java/org/apache/cassandra/db/RangeTombstoneList.java
index 757a1d0..fd2e100 100644
--- a/src/java/org/apache/cassandra/db/RangeTombstoneList.java
+++ b/src/java/org/apache/cassandra/db/RangeTombstoneList.java
@@ -128,6 +128,8 @@ public class RangeTombstoneList implements
IterableRangeTombstone, IMeasurable
for (int i = 0; i size; i++)
{
+assert !(starts[i] instanceof AbstractNativeCell || ends[i]
instanceof AbstractNativeCell); //this should never happen
+
copy.starts[i] = starts[i].copy(null, allocator);
copy.ends[i] = ends[i].copy(null, allocator);
}
[3/9] git commit: Improve validation of sub range repair
Improve validation of sub range repair
also prevent -pr repair not to work with -dc/-hosts/-local.
patch by yukim; reviewed by krummas for CASSANDRA-7317
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/434b5d68
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/434b5d68
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/434b5d68
Branch: refs/heads/trunk
Commit: 434b5d683ec7520acf1a5a2d421ee5aba2ede0e8
Parents: 303ff22
Author: Yuki Morishita yu...@apache.org
Authored: Thu Jun 19 10:47:14 2014 -0500
Committer: Yuki Morishita yu...@apache.org
Committed: Thu Jun 19 10:47:14 2014 -0500
--
.../cassandra/service/ActiveRepairService.java | 3 -
.../cassandra/service/StorageService.java | 98 +---
.../org/apache/cassandra/tools/NodeCmd.java | 3 +
3 files changed, 70 insertions(+), 34 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/434b5d68/src/java/org/apache/cassandra/service/ActiveRepairService.java
--
diff --git a/src/java/org/apache/cassandra/service/ActiveRepairService.java
b/src/java/org/apache/cassandra/service/ActiveRepairService.java
index 00e43ea..aac9f9a 100644
--- a/src/java/org/apache/cassandra/service/ActiveRepairService.java
+++ b/src/java/org/apache/cassandra/service/ActiveRepairService.java
@@ -146,9 +146,6 @@ public class ActiveRepairService
*/
public static SetInetAddress getNeighbors(String keyspaceName,
RangeToken toRepair, CollectionString dataCenters, CollectionString hosts)
{
-if (dataCenters != null
!dataCenters.contains(DatabaseDescriptor.getLocalDataCenter()))
-throw new IllegalArgumentException(The local data center must be
part of the repair);
-
StorageService ss = StorageService.instance;
MapRangeToken, ListInetAddress replicaSets =
ss.getRangeToAddressMap(keyspaceName);
RangeToken rangeSuperSet = null;
http://git-wip-us.apache.org/repos/asf/cassandra/blob/434b5d68/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 05cc8d7..13dd3b7 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -2488,6 +2488,11 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
public int forceRepairAsync(final String keyspace, final boolean
isSequential, final CollectionString dataCenters, final CollectionString
hosts, final boolean primaryRange, final String... columnFamilies)
{
+// when repairing only primary range, dataCenter nor hosts can be set
+if (primaryRange (dataCenters != null || hosts != null))
+{
+throw new IllegalArgumentException(You need to run primary range
repair on all nodes in the cluster.);
+}
final CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
return forceRepairAsync(keyspace, isSequential, dataCenters, hosts,
ranges, columnFamilies);
}
@@ -2507,6 +2512,11 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
public int forceRepairAsync(final String keyspace, final boolean
isSequential, final boolean isLocal, final boolean primaryRange, final
String... columnFamilies)
{
+// when repairing only primary range, you cannot repair only on local
DC
+if (primaryRange isLocal)
+{
+throw new IllegalArgumentException(You need to run primary range
repair on all nodes in the cluster.);
+}
final CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
return forceRepairAsync(keyspace, isSequential, isLocal, ranges,
columnFamilies);
}
@@ -2528,30 +2538,25 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
public int forceRepairRangeAsync(String beginToken, String endToken, final
String keyspaceName, boolean isSequential, CollectionString dataCenters,
final CollectionString hosts, final String... columnFamilies)
{
-Token parsedBeginToken =
getPartitioner().getTokenFactory().fromString(beginToken);
-Token parsedEndToken =
getPartitioner().getTokenFactory().fromString(endToken);
+CollectionRangeToken repairingRange =
createRepairRangeFrom(beginToken, endToken);
-logger.info(starting user-requested repair of range ({}, {}] for
keyspace {} and column families {},
-
[6/9] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1
Conflicts:
src/java/org/apache/cassandra/service/StorageService.java
src/java/org/apache/cassandra/tools/NodeCmd.java
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/40f8ebae
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/40f8ebae
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/40f8ebae
Branch: refs/heads/trunk
Commit: 40f8ebae6c7cf3024e9212582b5b7caa7825c37f
Parents: 4f381a2 434b5d6
Author: Yuki Morishita yu...@apache.org
Authored: Thu Jun 19 11:33:18 2014 -0500
Committer: Yuki Morishita yu...@apache.org
Committed: Thu Jun 19 11:33:18 2014 -0500
--
.../cassandra/service/ActiveRepairService.java | 3 -
.../cassandra/service/StorageService.java | 64 +++-
.../org/apache/cassandra/tools/NodeTool.java| 3 +
3 files changed, 52 insertions(+), 18 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/40f8ebae/src/java/org/apache/cassandra/service/ActiveRepairService.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/40f8ebae/src/java/org/apache/cassandra/service/StorageService.java
--
diff --cc src/java/org/apache/cassandra/service/StorageService.java
index 7dc2a6c,13dd3b7..06d28c3
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@@ -2551,14 -2486,18 +2551,19 @@@ public class StorageService extends Not
sendNotification(jmxNotification);
}
-public int forceRepairAsync(final String keyspace, final boolean
isSequential, final CollectionString dataCenters, final CollectionString
hosts, final boolean primaryRange, final String... columnFamilies)
+public int forceRepairAsync(String keyspace, boolean isSequential,
CollectionString dataCenters, CollectionString hosts, boolean primaryRange,
boolean fullRepair, String... columnFamilies) throws IOException
{
+ // when repairing only primary range, dataCenter nor hosts can be set
+ if (primaryRange (dataCenters != null || hosts != null))
+ {
+ throw new IllegalArgumentException(You need to run primary range
repair on all nodes in the cluster.);
+ }
-final CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
-return forceRepairAsync(keyspace, isSequential, dataCenters, hosts,
ranges, columnFamilies);
+CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
+
+return forceRepairAsync(keyspace, isSequential, dataCenters, hosts,
ranges, fullRepair, columnFamilies);
}
-public int forceRepairAsync(final String keyspace, final boolean
isSequential, final CollectionString dataCenters, final CollectionString
hosts, final CollectionRangeToken ranges, final String... columnFamilies)
+public int forceRepairAsync(String keyspace, boolean isSequential,
CollectionString dataCenters, CollectionString hosts,
CollectionRangeToken ranges, boolean fullRepair, String... columnFamilies)
{
if (Keyspace.SYSTEM_KS.equals(keyspace) || ranges.isEmpty())
return 0;
@@@ -2571,13 -2510,18 +2576,18 @@@
return cmd;
}
-public int forceRepairAsync(final String keyspace, final boolean
isSequential, final boolean isLocal, final boolean primaryRange, final
String... columnFamilies)
+public int forceRepairAsync(String keyspace, boolean isSequential,
boolean isLocal, boolean primaryRange, boolean fullRepair, String...
columnFamilies)
{
+ // when repairing only primary range, you cannot repair only on local
DC
+ if (primaryRange isLocal)
+ {
+ throw new IllegalArgumentException(You need to run primary range
repair on all nodes in the cluster.);
+ }
-final CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
-return forceRepairAsync(keyspace, isSequential, isLocal, ranges,
columnFamilies);
+CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
+return forceRepairAsync(keyspace, isSequential, isLocal, ranges,
fullRepair, columnFamilies);
}
-public int forceRepairAsync(String keyspace, boolean isSequential,
boolean isLocal, CollectionRangeToken ranges, String... columnFamilies)
+public int forceRepairAsync(String keyspace, boolean isSequential,
boolean isLocal, CollectionRangeToken ranges, boolean fullRepair, String...
[8/9] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1
Conflicts:
src/java/org/apache/cassandra/service/StorageService.java
src/java/org/apache/cassandra/tools/NodeCmd.java
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/40f8ebae
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/40f8ebae
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/40f8ebae
Branch: refs/heads/cassandra-2.1
Commit: 40f8ebae6c7cf3024e9212582b5b7caa7825c37f
Parents: 4f381a2 434b5d6
Author: Yuki Morishita yu...@apache.org
Authored: Thu Jun 19 11:33:18 2014 -0500
Committer: Yuki Morishita yu...@apache.org
Committed: Thu Jun 19 11:33:18 2014 -0500
--
.../cassandra/service/ActiveRepairService.java | 3 -
.../cassandra/service/StorageService.java | 64 +++-
.../org/apache/cassandra/tools/NodeTool.java| 3 +
3 files changed, 52 insertions(+), 18 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/40f8ebae/src/java/org/apache/cassandra/service/ActiveRepairService.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/40f8ebae/src/java/org/apache/cassandra/service/StorageService.java
--
diff --cc src/java/org/apache/cassandra/service/StorageService.java
index 7dc2a6c,13dd3b7..06d28c3
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@@ -2551,14 -2486,18 +2551,19 @@@ public class StorageService extends Not
sendNotification(jmxNotification);
}
-public int forceRepairAsync(final String keyspace, final boolean
isSequential, final CollectionString dataCenters, final CollectionString
hosts, final boolean primaryRange, final String... columnFamilies)
+public int forceRepairAsync(String keyspace, boolean isSequential,
CollectionString dataCenters, CollectionString hosts, boolean primaryRange,
boolean fullRepair, String... columnFamilies) throws IOException
{
+ // when repairing only primary range, dataCenter nor hosts can be set
+ if (primaryRange (dataCenters != null || hosts != null))
+ {
+ throw new IllegalArgumentException(You need to run primary range
repair on all nodes in the cluster.);
+ }
-final CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
-return forceRepairAsync(keyspace, isSequential, dataCenters, hosts,
ranges, columnFamilies);
+CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
+
+return forceRepairAsync(keyspace, isSequential, dataCenters, hosts,
ranges, fullRepair, columnFamilies);
}
-public int forceRepairAsync(final String keyspace, final boolean
isSequential, final CollectionString dataCenters, final CollectionString
hosts, final CollectionRangeToken ranges, final String... columnFamilies)
+public int forceRepairAsync(String keyspace, boolean isSequential,
CollectionString dataCenters, CollectionString hosts,
CollectionRangeToken ranges, boolean fullRepair, String... columnFamilies)
{
if (Keyspace.SYSTEM_KS.equals(keyspace) || ranges.isEmpty())
return 0;
@@@ -2571,13 -2510,18 +2576,18 @@@
return cmd;
}
-public int forceRepairAsync(final String keyspace, final boolean
isSequential, final boolean isLocal, final boolean primaryRange, final
String... columnFamilies)
+public int forceRepairAsync(String keyspace, boolean isSequential,
boolean isLocal, boolean primaryRange, boolean fullRepair, String...
columnFamilies)
{
+ // when repairing only primary range, you cannot repair only on local
DC
+ if (primaryRange isLocal)
+ {
+ throw new IllegalArgumentException(You need to run primary range
repair on all nodes in the cluster.);
+ }
-final CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
-return forceRepairAsync(keyspace, isSequential, isLocal, ranges,
columnFamilies);
+CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
+return forceRepairAsync(keyspace, isSequential, isLocal, ranges,
fullRepair, columnFamilies);
}
-public int forceRepairAsync(String keyspace, boolean isSequential,
boolean isLocal, CollectionRangeToken ranges, String... columnFamilies)
+public int forceRepairAsync(String keyspace, boolean isSequential,
boolean isLocal, CollectionRangeToken ranges, boolean fullRepair,
[2/9] git commit: Improve validation of sub range repair
Improve validation of sub range repair
also prevent -pr repair not to work with -dc/-hosts/-local.
patch by yukim; reviewed by krummas for CASSANDRA-7317
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/434b5d68
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/434b5d68
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/434b5d68
Branch: refs/heads/cassandra-2.1
Commit: 434b5d683ec7520acf1a5a2d421ee5aba2ede0e8
Parents: 303ff22
Author: Yuki Morishita yu...@apache.org
Authored: Thu Jun 19 10:47:14 2014 -0500
Committer: Yuki Morishita yu...@apache.org
Committed: Thu Jun 19 10:47:14 2014 -0500
--
.../cassandra/service/ActiveRepairService.java | 3 -
.../cassandra/service/StorageService.java | 98 +---
.../org/apache/cassandra/tools/NodeCmd.java | 3 +
3 files changed, 70 insertions(+), 34 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/434b5d68/src/java/org/apache/cassandra/service/ActiveRepairService.java
--
diff --git a/src/java/org/apache/cassandra/service/ActiveRepairService.java
b/src/java/org/apache/cassandra/service/ActiveRepairService.java
index 00e43ea..aac9f9a 100644
--- a/src/java/org/apache/cassandra/service/ActiveRepairService.java
+++ b/src/java/org/apache/cassandra/service/ActiveRepairService.java
@@ -146,9 +146,6 @@ public class ActiveRepairService
*/
public static SetInetAddress getNeighbors(String keyspaceName,
RangeToken toRepair, CollectionString dataCenters, CollectionString hosts)
{
-if (dataCenters != null
!dataCenters.contains(DatabaseDescriptor.getLocalDataCenter()))
-throw new IllegalArgumentException(The local data center must be
part of the repair);
-
StorageService ss = StorageService.instance;
MapRangeToken, ListInetAddress replicaSets =
ss.getRangeToAddressMap(keyspaceName);
RangeToken rangeSuperSet = null;
http://git-wip-us.apache.org/repos/asf/cassandra/blob/434b5d68/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 05cc8d7..13dd3b7 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -2488,6 +2488,11 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
public int forceRepairAsync(final String keyspace, final boolean
isSequential, final CollectionString dataCenters, final CollectionString
hosts, final boolean primaryRange, final String... columnFamilies)
{
+// when repairing only primary range, dataCenter nor hosts can be set
+if (primaryRange (dataCenters != null || hosts != null))
+{
+throw new IllegalArgumentException(You need to run primary range
repair on all nodes in the cluster.);
+}
final CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
return forceRepairAsync(keyspace, isSequential, dataCenters, hosts,
ranges, columnFamilies);
}
@@ -2507,6 +2512,11 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
public int forceRepairAsync(final String keyspace, final boolean
isSequential, final boolean isLocal, final boolean primaryRange, final
String... columnFamilies)
{
+// when repairing only primary range, you cannot repair only on local
DC
+if (primaryRange isLocal)
+{
+throw new IllegalArgumentException(You need to run primary range
repair on all nodes in the cluster.);
+}
final CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
return forceRepairAsync(keyspace, isSequential, isLocal, ranges,
columnFamilies);
}
@@ -2528,30 +2538,25 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
public int forceRepairRangeAsync(String beginToken, String endToken, final
String keyspaceName, boolean isSequential, CollectionString dataCenters,
final CollectionString hosts, final String... columnFamilies)
{
-Token parsedBeginToken =
getPartitioner().getTokenFactory().fromString(beginToken);
-Token parsedEndToken =
getPartitioner().getTokenFactory().fromString(endToken);
+CollectionRangeToken repairingRange =
createRepairRangeFrom(beginToken, endToken);
-logger.info(starting user-requested repair of range ({}, {}] for
keyspace {} and column families
[1/9] git commit: Improve validation of sub range repair
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 303ff22dd - 434b5d683
refs/heads/cassandra-2.1 4f381a2a6 - 40f8ebae6
refs/heads/trunk 7d8ba3be5 - 65b19cae3
Improve validation of sub range repair
also prevent -pr repair not to work with -dc/-hosts/-local.
patch by yukim; reviewed by krummas for CASSANDRA-7317
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/434b5d68
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/434b5d68
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/434b5d68
Branch: refs/heads/cassandra-2.0
Commit: 434b5d683ec7520acf1a5a2d421ee5aba2ede0e8
Parents: 303ff22
Author: Yuki Morishita yu...@apache.org
Authored: Thu Jun 19 10:47:14 2014 -0500
Committer: Yuki Morishita yu...@apache.org
Committed: Thu Jun 19 10:47:14 2014 -0500
--
.../cassandra/service/ActiveRepairService.java | 3 -
.../cassandra/service/StorageService.java | 98 +---
.../org/apache/cassandra/tools/NodeCmd.java | 3 +
3 files changed, 70 insertions(+), 34 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/434b5d68/src/java/org/apache/cassandra/service/ActiveRepairService.java
--
diff --git a/src/java/org/apache/cassandra/service/ActiveRepairService.java
b/src/java/org/apache/cassandra/service/ActiveRepairService.java
index 00e43ea..aac9f9a 100644
--- a/src/java/org/apache/cassandra/service/ActiveRepairService.java
+++ b/src/java/org/apache/cassandra/service/ActiveRepairService.java
@@ -146,9 +146,6 @@ public class ActiveRepairService
*/
public static SetInetAddress getNeighbors(String keyspaceName,
RangeToken toRepair, CollectionString dataCenters, CollectionString hosts)
{
-if (dataCenters != null
!dataCenters.contains(DatabaseDescriptor.getLocalDataCenter()))
-throw new IllegalArgumentException(The local data center must be
part of the repair);
-
StorageService ss = StorageService.instance;
MapRangeToken, ListInetAddress replicaSets =
ss.getRangeToAddressMap(keyspaceName);
RangeToken rangeSuperSet = null;
http://git-wip-us.apache.org/repos/asf/cassandra/blob/434b5d68/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 05cc8d7..13dd3b7 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -2488,6 +2488,11 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
public int forceRepairAsync(final String keyspace, final boolean
isSequential, final CollectionString dataCenters, final CollectionString
hosts, final boolean primaryRange, final String... columnFamilies)
{
+// when repairing only primary range, dataCenter nor hosts can be set
+if (primaryRange (dataCenters != null || hosts != null))
+{
+throw new IllegalArgumentException(You need to run primary range
repair on all nodes in the cluster.);
+}
final CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
return forceRepairAsync(keyspace, isSequential, dataCenters, hosts,
ranges, columnFamilies);
}
@@ -2507,6 +2512,11 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
public int forceRepairAsync(final String keyspace, final boolean
isSequential, final boolean isLocal, final boolean primaryRange, final
String... columnFamilies)
{
+// when repairing only primary range, you cannot repair only on local
DC
+if (primaryRange isLocal)
+{
+throw new IllegalArgumentException(You need to run primary range
repair on all nodes in the cluster.);
+}
final CollectionRangeToken ranges = primaryRange ?
getLocalPrimaryRanges(keyspace) : getLocalRanges(keyspace);
return forceRepairAsync(keyspace, isSequential, isLocal, ranges,
columnFamilies);
}
@@ -2528,30 +2538,25 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
public int forceRepairRangeAsync(String beginToken, String endToken, final
String keyspaceName, boolean isSequential, CollectionString dataCenters,
final CollectionString hosts, final String... columnFamilies)
{
-Token parsedBeginToken =
getPartitioner().getTokenFactory().fromString(beginToken);
-Token parsedEndToken =
getPartitioner().getTokenFactory().fromString(endToken);
+
[9/9] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/65b19cae Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/65b19cae Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/65b19cae Branch: refs/heads/trunk Commit: 65b19cae328d61b73fd7b0a12d7b107acd29e704 Parents: 7d8ba3b 40f8eba Author: Yuki Morishita yu...@apache.org Authored: Thu Jun 19 11:33:34 2014 -0500 Committer: Yuki Morishita yu...@apache.org Committed: Thu Jun 19 11:33:34 2014 -0500 -- .../apache/cassandra/db/RangeTombstoneList.java | 2 + .../cassandra/service/ActiveRepairService.java | 3 - .../cassandra/service/StorageService.java | 64 +++- .../org/apache/cassandra/tools/NodeTool.java| 3 + 4 files changed, 54 insertions(+), 18 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/65b19cae/src/java/org/apache/cassandra/service/StorageService.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/65b19cae/src/java/org/apache/cassandra/tools/NodeTool.java --
[3/6] git commit: forgot to add CASSANDRA-7317 to CHANGES
forgot to add CASSANDRA-7317 to CHANGES Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f0ebdeb2 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f0ebdeb2 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f0ebdeb2 Branch: refs/heads/trunk Commit: f0ebdeb2999b99dac23c5576d2093557424820cd Parents: 434b5d6 Author: Yuki Morishita yu...@apache.org Authored: Thu Jun 19 11:37:29 2014 -0500 Committer: Yuki Morishita yu...@apache.org Committed: Thu Jun 19 11:37:29 2014 -0500 -- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0ebdeb2/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 65e3161..f4f5d83 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -18,6 +18,7 @@ * Fix infinite loop on exception while streaming (CASSANDRA-7330) * Reference sstables before populating key cache (CASSANDRA-7234) * Account for range tombstones in min/max column names (CASSANDRA-7235) + * Improve sub range repair validation (CASSANDRA-7317) Merged from 1.2: * cqlsh: ignore .cassandra permission errors (CASSANDRA-7266) * Errors in FlushRunnable may leave threads hung (CASSANDRA-7275)
[1/6] git commit: forgot to add CASSANDRA-7317 to CHANGES
Repository: cassandra Updated Branches: refs/heads/cassandra-2.0 434b5d683 - f0ebdeb29 refs/heads/cassandra-2.1 40f8ebae6 - 43ffb6baf refs/heads/trunk 65b19cae3 - 295fe5dd0 forgot to add CASSANDRA-7317 to CHANGES Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f0ebdeb2 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f0ebdeb2 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f0ebdeb2 Branch: refs/heads/cassandra-2.0 Commit: f0ebdeb2999b99dac23c5576d2093557424820cd Parents: 434b5d6 Author: Yuki Morishita yu...@apache.org Authored: Thu Jun 19 11:37:29 2014 -0500 Committer: Yuki Morishita yu...@apache.org Committed: Thu Jun 19 11:37:29 2014 -0500 -- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0ebdeb2/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 65e3161..f4f5d83 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -18,6 +18,7 @@ * Fix infinite loop on exception while streaming (CASSANDRA-7330) * Reference sstables before populating key cache (CASSANDRA-7234) * Account for range tombstones in min/max column names (CASSANDRA-7235) + * Improve sub range repair validation (CASSANDRA-7317) Merged from 1.2: * cqlsh: ignore .cassandra permission errors (CASSANDRA-7266) * Errors in FlushRunnable may leave threads hung (CASSANDRA-7275)
[6/6] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/295fe5dd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/295fe5dd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/295fe5dd Branch: refs/heads/trunk Commit: 295fe5dd02d1626a21c7b7595aa996319dc7815e Parents: 65b19cae 43ffb6b Author: Yuki Morishita yu...@apache.org Authored: Thu Jun 19 11:37:42 2014 -0500 Committer: Yuki Morishita yu...@apache.org Committed: Thu Jun 19 11:37:42 2014 -0500 -- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/295fe5dd/CHANGES.txt --
[4/6] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/43ffb6ba Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/43ffb6ba Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/43ffb6ba Branch: refs/heads/trunk Commit: 43ffb6baf9a1674739f7d892c050f5fe306d2817 Parents: 40f8eba f0ebdeb Author: Yuki Morishita yu...@apache.org Authored: Thu Jun 19 11:37:35 2014 -0500 Committer: Yuki Morishita yu...@apache.org Committed: Thu Jun 19 11:37:35 2014 -0500 -- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/43ffb6ba/CHANGES.txt -- diff --cc CHANGES.txt index ad5fb1c,f4f5d83..783bfda --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,26 -1,24 +1,27 @@@ -2.0.9 - * Fix assertion error in CL.ANY timeout handling (CASSANDRA-7364) - * Handle empty CFs in Memtable#maybeUpdateLiveRatio() (CASSANDRA-7401) +2.1.0 + * Avoid incremental compaction on Windows (CASSANDRA-7365) + * Fix exception when querying a composite-keyed table with a collection index + (CASSANDRA-7372) + * Use node's host id in place of counter ids (CASSANDRA-7366) * Fix native protocol CAS batches (CASSANDRA-7337) + * Reduce likelihood of contention on local paxos locking (CASSANDRA-7359) + * Upgrade to Pig 0.12.1 (CASSANDRA-6556) + * Make sure we clear out repair sessions from netstats (CASSANDRA-7329) + * Don't fail streams on failure detector downs (CASSANDRA-3569) + * Add optional keyspace to DROP INDEX statement (CASSANDRA-7314) + * Reduce run time for CQL tests (CASSANDRA-7327) + * Fix heap size calculation on Windows (CASSANDRA-7352, 7353) + * RefCount native frames from netty (CASSANDRA-7245) + * Use tarball dir instead of /var for default paths (CASSANDRA-7136) + * Remove rows_per_partition_to_cache keyword (CASSANDRA-7193) +Merged from 2.0: + * Fix assertion error in CL.ANY timeout handling (CASSANDRA-7364) * Add per-CF range read request latency metrics (CASSANDRA-7338) * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323) - * Add conditional CREATE/DROP USER support (CASSANDRA-7264) - * Swap local and global default read repair chances (CASSANDRA-7320) - * Add missing iso8601 patterns for date strings (CASSANDRA-6973) - * Support selecting multiple rows in a partition using IN (CASSANDRA-6875) - * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274) - * Copy compaction options to make sure they are reloaded (CASSANDRA-7290) - * Add option to do more aggressive tombstone compactions (CASSANDRA-6563) - * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288) - * Add authentication support to shuffle (CASSANDRA-6484) - * Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325) * Make StreamSession#closeSession() idempotent (CASSANDRA-7262) * Fix infinite loop on exception while streaming (CASSANDRA-7330) - * Reference sstables before populating key cache (CASSANDRA-7234) * Account for range tombstones in min/max column names (CASSANDRA-7235) + * Improve sub range repair validation (CASSANDRA-7317) Merged from 1.2: * cqlsh: ignore .cassandra permission errors (CASSANDRA-7266) * Errors in FlushRunnable may leave threads hung (CASSANDRA-7275)
[5/6] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/43ffb6ba Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/43ffb6ba Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/43ffb6ba Branch: refs/heads/cassandra-2.1 Commit: 43ffb6baf9a1674739f7d892c050f5fe306d2817 Parents: 40f8eba f0ebdeb Author: Yuki Morishita yu...@apache.org Authored: Thu Jun 19 11:37:35 2014 -0500 Committer: Yuki Morishita yu...@apache.org Committed: Thu Jun 19 11:37:35 2014 -0500 -- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/43ffb6ba/CHANGES.txt -- diff --cc CHANGES.txt index ad5fb1c,f4f5d83..783bfda --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,26 -1,24 +1,27 @@@ -2.0.9 - * Fix assertion error in CL.ANY timeout handling (CASSANDRA-7364) - * Handle empty CFs in Memtable#maybeUpdateLiveRatio() (CASSANDRA-7401) +2.1.0 + * Avoid incremental compaction on Windows (CASSANDRA-7365) + * Fix exception when querying a composite-keyed table with a collection index + (CASSANDRA-7372) + * Use node's host id in place of counter ids (CASSANDRA-7366) * Fix native protocol CAS batches (CASSANDRA-7337) + * Reduce likelihood of contention on local paxos locking (CASSANDRA-7359) + * Upgrade to Pig 0.12.1 (CASSANDRA-6556) + * Make sure we clear out repair sessions from netstats (CASSANDRA-7329) + * Don't fail streams on failure detector downs (CASSANDRA-3569) + * Add optional keyspace to DROP INDEX statement (CASSANDRA-7314) + * Reduce run time for CQL tests (CASSANDRA-7327) + * Fix heap size calculation on Windows (CASSANDRA-7352, 7353) + * RefCount native frames from netty (CASSANDRA-7245) + * Use tarball dir instead of /var for default paths (CASSANDRA-7136) + * Remove rows_per_partition_to_cache keyword (CASSANDRA-7193) +Merged from 2.0: + * Fix assertion error in CL.ANY timeout handling (CASSANDRA-7364) * Add per-CF range read request latency metrics (CASSANDRA-7338) * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323) - * Add conditional CREATE/DROP USER support (CASSANDRA-7264) - * Swap local and global default read repair chances (CASSANDRA-7320) - * Add missing iso8601 patterns for date strings (CASSANDRA-6973) - * Support selecting multiple rows in a partition using IN (CASSANDRA-6875) - * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274) - * Copy compaction options to make sure they are reloaded (CASSANDRA-7290) - * Add option to do more aggressive tombstone compactions (CASSANDRA-6563) - * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288) - * Add authentication support to shuffle (CASSANDRA-6484) - * Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325) * Make StreamSession#closeSession() idempotent (CASSANDRA-7262) * Fix infinite loop on exception while streaming (CASSANDRA-7330) - * Reference sstables before populating key cache (CASSANDRA-7234) * Account for range tombstones in min/max column names (CASSANDRA-7235) + * Improve sub range repair validation (CASSANDRA-7317) Merged from 1.2: * cqlsh: ignore .cassandra permission errors (CASSANDRA-7266) * Errors in FlushRunnable may leave threads hung (CASSANDRA-7275)
[2/6] git commit: forgot to add CASSANDRA-7317 to CHANGES
forgot to add CASSANDRA-7317 to CHANGES Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f0ebdeb2 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f0ebdeb2 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f0ebdeb2 Branch: refs/heads/cassandra-2.1 Commit: f0ebdeb2999b99dac23c5576d2093557424820cd Parents: 434b5d6 Author: Yuki Morishita yu...@apache.org Authored: Thu Jun 19 11:37:29 2014 -0500 Committer: Yuki Morishita yu...@apache.org Committed: Thu Jun 19 11:37:29 2014 -0500 -- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0ebdeb2/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 65e3161..f4f5d83 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -18,6 +18,7 @@ * Fix infinite loop on exception while streaming (CASSANDRA-7330) * Reference sstables before populating key cache (CASSANDRA-7234) * Account for range tombstones in min/max column names (CASSANDRA-7235) + * Improve sub range repair validation (CASSANDRA-7317) Merged from 1.2: * cqlsh: ignore .cassandra permission errors (CASSANDRA-7266) * Errors in FlushRunnable may leave threads hung (CASSANDRA-7275)
[jira] [Commented] (CASSANDRA-7254) NPE on startup if another Cassandra instance is already running
[
https://issues.apache.org/jira/browse/CASSANDRA-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037496#comment-14037496
]
Chris Lohfink commented on CASSANDRA-7254:
--
Seems like it, two instances of:
{code:title=Test.java|java}
public class Test {
public static void main(String[] args) throws Exception {
Thread.sleep(10); }
}
{code}
and jvm args
{code}-Dcom.sun.management.jmxremote.port=
-Dcom.sun.management.jmxremote.rmi.port=
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false{code}
will cause that error. Ill open issue and see if theres something to do about
it for a better error
NPE on startup if another Cassandra instance is already running
---
Key: CASSANDRA-7254
URL: https://issues.apache.org/jira/browse/CASSANDRA-7254
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Chris Lohfink
Priority: Minor
Fix For: 2.1.0
After CASSANDRA-7087, if you try to start cassandra while another instance is
already running, you'll see something like this:
{noformat}
$ bin/cassandra -f
Error: Exception thrown by the agent : java.lang.NullPointerException
{noformat}
This is probably a JVM bug, but we should confirm that, open a JVM ticket,
and see if we can give a more useful error message on the C* side.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6766) allow now() - uuid compatibility
[ https://issues.apache.org/jira/browse/CASSANDRA-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037505#comment-14037505 ] Tyler Hobbs commented on CASSANDRA-6766: Seems reasonable to me. allow now() - uuid compatibility - Key: CASSANDRA-6766 URL: https://issues.apache.org/jira/browse/CASSANDRA-6766 Project: Cassandra Issue Type: Bug Components: API Reporter: Jonathan Ellis Assignee: Tyler Hobbs Priority: Minor Labels: cql Fix For: 2.0.9 Attachments: 6766.txt Bad Request: Type error: cannot assign result of function now (type timeuuid) to id (type uuid) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CASSANDRA-7275) Errors in FlushRunnable may leave threads hung
[
https://issues.apache.org/jira/browse/CASSANDRA-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita reopened CASSANDRA-7275:
---
I reopen this and will attach alternative solution to remove latch.
Errors in FlushRunnable may leave threads hung
--
Key: CASSANDRA-7275
URL: https://issues.apache.org/jira/browse/CASSANDRA-7275
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Mikhail Stepura
Priority: Minor
Fix For: 1.2.17, 2.0.9
Attachments: 0001-Move-latch.countDown-into-finally-block.patch
In Memtable.FlushRunnable, the CountDownLatch will never be counted down if
there are errors, which results in hanging any threads that are waiting for
the flush to complete. For example, an error like this causes the problem:
{noformat}
ERROR [FlushWriter:474] 2014-05-20 12:10:31,137 CassandraDaemon.java (line
198) Exception in thread Thread[FlushWriter:474,5,main]
java.lang.IllegalArgumentException
at java.nio.Buffer.position(Unknown Source)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:64)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:72)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:138)
at
org.apache.cassandra.io.sstable.ColumnNameHelper.minComponents(ColumnNameHelper.java:103)
at
org.apache.cassandra.db.ColumnFamily.getColumnStats(ColumnFamily.java:439)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:194)
at
org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:397)
at
org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:350)
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7275) Errors in FlushRunnable may leave threads hung
[
https://issues.apache.org/jira/browse/CASSANDRA-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037516#comment-14037516
]
Yuki Morishita edited comment on CASSANDRA-7275 at 6/19/14 4:57 PM:
Patch removes latch completely and use ListenableFuture instead. This way we
can submit post flush process only if related flushes succeed.
(patch is against 2.0 branch, but maybe 2.1 is suitable for the change)
was (Author: yukim):
Patch removes latch completely and use ListenableFuture instead. This way we
can submit post flush process only if related flushes succeed.
Errors in FlushRunnable may leave threads hung
--
Key: CASSANDRA-7275
URL: https://issues.apache.org/jira/browse/CASSANDRA-7275
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Mikhail Stepura
Priority: Minor
Fix For: 1.2.17, 2.0.9
Attachments: 0001-Move-latch.countDown-into-finally-block.patch,
7252-2.0-v2.txt
In Memtable.FlushRunnable, the CountDownLatch will never be counted down if
there are errors, which results in hanging any threads that are waiting for
the flush to complete. For example, an error like this causes the problem:
{noformat}
ERROR [FlushWriter:474] 2014-05-20 12:10:31,137 CassandraDaemon.java (line
198) Exception in thread Thread[FlushWriter:474,5,main]
java.lang.IllegalArgumentException
at java.nio.Buffer.position(Unknown Source)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:64)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:72)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:138)
at
org.apache.cassandra.io.sstable.ColumnNameHelper.minComponents(ColumnNameHelper.java:103)
at
org.apache.cassandra.db.ColumnFamily.getColumnStats(ColumnFamily.java:439)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:194)
at
org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:397)
at
org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:350)
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7275) Errors in FlushRunnable may leave threads hung
[
https://issues.apache.org/jira/browse/CASSANDRA-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-7275:
--
Attachment: 7252-2.0-v2.txt
Path removes latch completely and use ListenableFuture instead. This way we can
submit post flush process only if related flushes succeed.
Errors in FlushRunnable may leave threads hung
--
Key: CASSANDRA-7275
URL: https://issues.apache.org/jira/browse/CASSANDRA-7275
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Mikhail Stepura
Priority: Minor
Fix For: 1.2.17, 2.0.9
Attachments: 0001-Move-latch.countDown-into-finally-block.patch,
7252-2.0-v2.txt
In Memtable.FlushRunnable, the CountDownLatch will never be counted down if
there are errors, which results in hanging any threads that are waiting for
the flush to complete. For example, an error like this causes the problem:
{noformat}
ERROR [FlushWriter:474] 2014-05-20 12:10:31,137 CassandraDaemon.java (line
198) Exception in thread Thread[FlushWriter:474,5,main]
java.lang.IllegalArgumentException
at java.nio.Buffer.position(Unknown Source)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:64)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:72)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:138)
at
org.apache.cassandra.io.sstable.ColumnNameHelper.minComponents(ColumnNameHelper.java:103)
at
org.apache.cassandra.db.ColumnFamily.getColumnStats(ColumnFamily.java:439)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:194)
at
org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:397)
at
org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:350)
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7275) Errors in FlushRunnable may leave threads hung
[
https://issues.apache.org/jira/browse/CASSANDRA-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037516#comment-14037516
]
Yuki Morishita edited comment on CASSANDRA-7275 at 6/19/14 4:56 PM:
Patch removes latch completely and use ListenableFuture instead. This way we
can submit post flush process only if related flushes succeed.
was (Author: yukim):
Path removes latch completely and use ListenableFuture instead. This way we can
submit post flush process only if related flushes succeed.
Errors in FlushRunnable may leave threads hung
--
Key: CASSANDRA-7275
URL: https://issues.apache.org/jira/browse/CASSANDRA-7275
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Mikhail Stepura
Priority: Minor
Fix For: 1.2.17, 2.0.9
Attachments: 0001-Move-latch.countDown-into-finally-block.patch,
7252-2.0-v2.txt
In Memtable.FlushRunnable, the CountDownLatch will never be counted down if
there are errors, which results in hanging any threads that are waiting for
the flush to complete. For example, an error like this causes the problem:
{noformat}
ERROR [FlushWriter:474] 2014-05-20 12:10:31,137 CassandraDaemon.java (line
198) Exception in thread Thread[FlushWriter:474,5,main]
java.lang.IllegalArgumentException
at java.nio.Buffer.position(Unknown Source)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:64)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:72)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:138)
at
org.apache.cassandra.io.sstable.ColumnNameHelper.minComponents(ColumnNameHelper.java:103)
at
org.apache.cassandra.db.ColumnFamily.getColumnStats(ColumnFamily.java:439)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:194)
at
org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:397)
at
org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:350)
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7305) CQL3, Static columns not returning rows if values are not set
[
https://issues.apache.org/jira/browse/CASSANDRA-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-7305:
Attachment: 7305.txt
Attaching patch that implements what I discuss above: we don't special case
queries that only select static columns anymore (as that's arguably
inconsistent and unexpected), but we allow static columns with {{DISTINCT}}
(and in that case only the very beginning of the partition is queried).
There is also some dtests for this
[here|https://github.com/pcmanus/cassandra-dtest/commit/d56f319dea7dedd791faecd1dcc2c64840f30e9c].
CQL3, Static columns not returning rows if values are not set
-
Key: CASSANDRA-7305
URL: https://issues.apache.org/jira/browse/CASSANDRA-7305
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Patrick Callaghan
Assignee: Sylvain Lebresne
Fix For: 2.0.9
Attachments: 7305.txt
Just a quick note on static columns, if you create some cql rows using
clustered columns and don't provide a value for a static column, then
selecting the row key with the (null) static column won't return any rows.
create table statictest( a int, b text static, c text, PRIMARY KEY (a, c));
insert into statictest (a, c) values (1, 'test');
select a,b from statictest;
(0 rows)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CASSANDRA-7277) CQL support for select distinct part_key,static_field from table
[ https://issues.apache.org/jira/browse/CASSANDRA-7277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-7277. - Resolution: Duplicate This is basically what we're adding in CASSANDRA-7305 so closing as duplicate. CQL support for select distinct part_key,static_field from table - Key: CASSANDRA-7277 URL: https://issues.apache.org/jira/browse/CASSANDRA-7277 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Shook Currently, a query which selects only static fields will return values with the cardinality of the primary key, including clustering columns. In some cases, this yields unintuitive results, even if it is correct according to primary key cardinality. For static fields which have useful semantics at the partition level, it should be easy to ask for them across partitions only. One way to achieve this would be to allow for distinct results at the partition level. select distinct part_key,static_field1,static_field2 from table1; In theory, this query could be optimized to avoid cell-level processing since nothing addressable by a clustering column is requested. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7419) Compactions not utilizing full compactionthroughput
Matt Robenolt created CASSANDRA-7419:
Summary: Compactions not utilizing full compactionthroughput
Key: CASSANDRA-7419
URL: https://issues.apache.org/jira/browse/CASSANDRA-7419
Project: Cassandra
Issue Type: Improvement
Environment: Ubuntu 12.04, kernel 3.13
Reporter: Matt Robenolt
Priority: Minor
Fix For: 2.0.8
compactionthroughput has been set to 128MB/s, but we never see utilization that
high during compactions. Also while compacting does not seem to utilize a
single core of CPU either. So not sure what the limitation actually is, but
would expect to get all 128MB/s (or close to it).
Here is a sample of mpstat during a series of compactions after a nodetool
cleanup:
{code}
$ sudo mpstat -P ALL 1
Linux 3.13.0-24-generic (cass-activity-4.disqus.net)06/19/2014
_x86_64_(24 CPU)
04:55:10 PM CPU%usr %nice%sys %iowait%irq %soft %steal
%guest %idle
04:55:11 PM all1.427.363.430.040.330.000.00
0.00 87.41
04:55:11 PM03.06 13.276.120.003.060.000.00
0.00 74.49
04:55:11 PM12.00 23.006.000.000.000.000.00
0.00 69.00
04:55:11 PM22.02 18.188.080.000.000.000.00
0.00 71.72
04:55:11 PM31.98 15.844.950.000.990.000.00
0.00 76.24
04:55:11 PM42.009.003.000.000.000.000.00
0.00 86.00
04:55:11 PM51.02 22.45 10.200.000.000.000.00
0.00 66.33
04:55:11 PM61.988.915.940.000.000.000.00
0.00 83.17
04:55:11 PM71.008.003.000.001.000.000.00
0.00 87.00
04:55:11 PM83.96 12.877.920.000.000.000.00
0.00 75.25
04:55:11 PM92.025.052.020.000.000.000.00
0.00 90.91
04:55:11 PM 101.01 14.146.060.000.000.000.00
0.00 78.79
04:55:11 PM 112.002.002.001.000.000.000.00
0.00 93.00
04:55:11 PM 120.003.001.000.000.000.000.00
0.00 96.00
04:55:11 PM 132.000.002.000.001.000.000.00
0.00 95.00
04:55:11 PM 141.011.011.010.000.000.000.00
0.00 96.97
04:55:11 PM 153.034.042.020.001.010.000.00
0.00 89.90
04:55:11 PM 162.002.003.000.001.000.000.00
0.00 92.00
04:55:11 PM 171.002.000.000.000.000.000.00
0.00 97.00
04:55:11 PM 181.000.000.000.000.000.000.00
0.00 99.00
04:55:11 PM 191.006.005.000.001.000.000.00
0.00 87.00
04:55:11 PM 200.001.010.000.000.000.000.00
0.00 98.99
04:55:11 PM 210.001.011.010.000.000.000.00
0.00 97.98
04:55:11 PM 220.002.001.000.000.000.000.00
0.00 97.00
04:55:11 PM 230.001.001.000.000.000.000.00
0.00 98.00
04:55:11 PM CPU%usr %nice%sys %iowait%irq %soft %steal
%guest %idle
04:55:12 PM all0.887.443.010.000.170.000.00
0.00 88.50
04:55:12 PM04.045.053.030.002.020.000.00
0.00 85.86
04:55:12 PM10.99 12.875.940.000.990.000.00
0.00 79.21
04:55:12 PM20.00 15.154.040.000.000.000.00
0.00 80.81
04:55:12 PM30.00 17.178.080.000.000.000.00
0.00 74.75
04:55:12 PM41.018.082.020.000.000.000.00
0.00 88.89
04:55:12 PM51.00 20.003.000.000.000.000.00
0.00 76.00
04:55:12 PM61.006.001.000.000.000.000.00
0.00 92.00
04:55:12 PM71.01 10.102.020.000.000.000.00
0.00 86.87
04:55:12 PM82.00 28.00 17.000.000.000.000.00
0.00 53.00
04:55:12 PM91.00 18.009.001.000.000.000.00
0.00 71.00
04:55:12 PM 101.00 12.005.000.000.000.000.00
0.00 82.00
04:55:12 PM 111.003.001.000.000.000.000.00
0.00 95.00
04:55:12 PM 120.001.020.000.000.000.000.00
0.00 98.98
04:55:12 PM 131.001.002.000.001.000.000.00
0.00 95.00
04:55:12 PM 141.005.002.000.001.000.000.00
0.00 91.00
04:55:12 PM 150.992.970.990.000.990.000.00
0.00 94.06
04:55:12 PM 160.001.011.010.000.000.00
[jira] [Updated] (CASSANDRA-7341) Emit metrics related to CAS/Paxos
[ https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-7341: - Attachment: trunk-7341.diff Emit metrics related to CAS/Paxos - Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor Attachments: CASClientRequestMetrics.java, trunk-7341.diff We can emit metrics based on Paxos. One of them is when there is contention. I will add more metric in this JIRA if it is helpful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7341) Emit metrics related to CAS/Paxos
[ https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-7341: - Attachment: CASClientRequestMetrics.java Emit metrics related to CAS/Paxos - Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor Attachments: CASClientRequestMetrics.java, trunk-7341.diff We can emit metrics based on Paxos. One of them is when there is contention. I will add more metric in this JIRA if it is helpful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037546#comment-14037546 ] Drew Kutcharian commented on CASSANDRA-7304: I agree with [~slebresne] here. Having it on the query is much clearer and easier to read. Also, I don't see a problem with having multiple statements that do the same thing, since: bq. UPDATE table SET column = 3 WHERE key = 2; This means use the default behavior bq. UPDATE table USING IGNORE_NULLS true SET column = 3 WHERE key = 2; This explicitly sets USING IGNORE_NULLS to true. bq. UPDATE table USING IGNORE_NULLS false SET column = 3 WHERE key = 2; This explicitly sets USING IGNORE_NULLS to false. Say if the default ever changes and you just don't want to be at the mercy of the default. So I wouldn't say these 3 statements have the same meaning. Ability to distinguish between NULL and UNSET values in Prepared Statements --- Key: CASSANDRA-7304 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304 Project: Cassandra Issue Type: Improvement Reporter: Drew Kutcharian Currently Cassandra inserts tombstones when a value of a column is bound to NULL in a prepared statement. At higher insert rates managing all these tombstones becomes an unnecessary overhead. This limits the usefulness of the prepared statements since developers have to either create multiple prepared statements (each with a different combination of column names, which at times is just unfeasible because of the sheer number of possible combinations) or fall back to using regular (non-prepared) statements. This JIRA is here to explore the possibility of either: A. Have a flag on prepared statements that once set, tells Cassandra to ignore null columns or B. Have an UNSET value which makes Cassandra skip the null columns and not tombstone them Basically, in the context of a prepared statement, a null value means delete, but we don’t have anything that means ignore (besides creating a new prepared statement without the ignored column). Please refer to the original conversation on DataStax Java Driver mailing list for more background: https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7341) Emit metrics related to CAS/Paxos
[ https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037548#comment-14037548 ] sankalp kohli commented on CASSANDRA-7341: -- I will upload the patch for 2.0 once this is reviewed. Emit metrics related to CAS/Paxos - Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor Attachments: CASClientRequestMetrics.java, trunk-7341.diff We can emit metrics based on Paxos. One of them is when there is contention. I will add more metric in this JIRA if it is helpful. -- This message was sent by Atlassian JIRA (v6.2#6252)
buildbot success in ASF Buildbot on cassandra-2.0
The Buildbot has detected a restored build on builder cassandra-2.0 while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-2.0/builds/87 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch cassandra-2.0] 434b5d683ec7520acf1a5a2d421ee5aba2ede0e8 Blamelist: Yuki Morishita yu...@apache.org Build succeeded! sincerely, -The Buildbot
[jira] [Commented] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037553#comment-14037553
]
Sylvain Lebresne commented on CASSANDRA-7304:
-
As an aside, syntax wise, I'm -1 on having a boolean for IGNORE_NULLS. It
should be {{UPDATE table USING IGNORE_NULLS SET ...}}, not {{UPDATE table USING
IGNORE_NULLS true SET ...}}. There is no default to worry about: {{null}} has
a semantic in CQL and we won't change it, it's not a default that may or may
not change.
In fact, while we're on syntax, I'm not a huge fan of {{USING IGNORE_NULLS}} as
it doesn't read well imo. I'd rather just have {{IGNORE NULLS}} at the end of
the statement the same way we have a {{ALLOW FILTERING}} for selects.
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Improvement
Reporter: Drew Kutcharian
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new
prepared statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing
list for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-6766) allow now() - uuid compatibility
[
https://issues.apache.org/jira/browse/CASSANDRA-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-6766:
---
Attachment: 6766-v2.txt
v2 patch unwraps ReversedType arguments and subclasses now implement
{{isValueCompatibleWithInternal()}}. The branch is also updated.
allow now() - uuid compatibility
-
Key: CASSANDRA-6766
URL: https://issues.apache.org/jira/browse/CASSANDRA-6766
Project: Cassandra
Issue Type: Bug
Components: API
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
Priority: Minor
Labels: cql
Fix For: 2.0.9
Attachments: 6766-v2.txt, 6766.txt
Bad Request: Type error: cannot assign result of function now (type timeuuid)
to id (type uuid)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7413) Native Protocol V3 CREATE Response
[
https://issues.apache.org/jira/browse/CASSANDRA-7413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037608#comment-14037608
]
Tyler Hobbs commented on CASSANDRA-7413:
I actually just noticed this yesterday as well.
With this patch, the type name in the type-related events is now
ksname.typename. It should just be typename.
And a couple of minor comments on the patch:
* In the protocol docs, is the same than for a SCHEMA CHANGE event should
be is the same as the body for a SCHEMA CHANGE event
* In {{CreateKeyspaceStatement.changeEvent()}}, you accidentally copied a
comment from {{CreateIndexStatement}}
Native Protocol V3 CREATE Response
--
Key: CASSANDRA-7413
URL: https://issues.apache.org/jira/browse/CASSANDRA-7413
Project: Cassandra
Issue Type: Task
Reporter: Robert Stupp
Assignee: Sylvain Lebresne
Labels: protocol
Fix For: 2.1 rc2
Attachments: 7413.txt
Native protocol v3 changes the EVENT (opcode 12) SCHEMA_CHANGE to include the
target type that changed : changetargetkeyspacename.
The RESULT (opcode 8) SCHEMA_CHANGE has the old layout
(changekeyspacetable.
Is this difference intentional or does the protocol spec needs change for
RESULT/SCHEMA_CHANGE?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
buildbot failure in ASF Buildbot on cassandra-2.1
The Buildbot has detected a new failure on builder cassandra-2.1 while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-2.1/builds/161 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch cassandra-2.1] 43ffb6baf9a1674739f7d892c050f5fe306d2817 Blamelist: Yuki Morishita yu...@apache.org BUILD FAILED: failed shell sincerely, -The Buildbot
[jira] [Commented] (CASSANDRA-7341) Emit metrics related to CAS/Paxos
[ https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037650#comment-14037650 ] Jonathan Ellis commented on CASSANDRA-7341: --- IMO this should be a part of ColumnFamilyMetrics rather than lumping all paxos ops together. Emit metrics related to CAS/Paxos - Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor Attachments: CASClientRequestMetrics.java, trunk-7341.diff We can emit metrics based on Paxos. One of them is when there is contention. I will add more metric in this JIRA if it is helpful. -- This message was sent by Atlassian JIRA (v6.2#6252)
git commit: Modify reconcile logic to always pick a tombstone over a counter cell
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 43ffb6baf - 6858dd3e3
Modify reconcile logic to always pick a tombstone over a counter cell
patch by Aleksey Yeschenko; reviewed by Sylvain Lebresne for
CASSANDRA-7346
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6858dd3e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6858dd3e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6858dd3e
Branch: refs/heads/cassandra-2.1
Commit: 6858dd3e3ab354c517503d310e50319be93cf6a2
Parents: 43ffb6b
Author: Aleksey Yeschenko alek...@apache.org
Authored: Thu Jun 19 11:54:33 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Thu Jun 19 11:54:33 2014 -0700
--
CHANGES.txt | 2 +
.../org/apache/cassandra/db/AbstractCell.java | 69 +---
.../cassandra/db/ArrayBackedSortedColumns.java | 2 +-
.../apache/cassandra/db/BufferCounterCell.java | 4 +-
.../cassandra/db/BufferCounterUpdateCell.java | 15 ++---
.../org/apache/cassandra/db/ColumnFamily.java | 2 +-
.../org/apache/cassandra/db/ColumnIndex.java| 2 +-
.../org/apache/cassandra/db/DeletionInfo.java | 35 --
.../org/apache/cassandra/db/DeletionTime.java | 10 +++
.../apache/cassandra/db/NativeCounterCell.java | 6 +-
.../apache/cassandra/db/RangeTombstoneList.java | 31 ++---
.../cassandra/db/filter/ColumnCounter.java | 2 +-
test/unit/org/apache/cassandra/Util.java| 5 --
.../apache/cassandra/db/ColumnFamilyTest.java | 39 ++-
.../apache/cassandra/db/CounterCellTest.java| 20 ++
.../cassandra/utils/EncodedStreamsTest.java | 10 +--
16 files changed, 139 insertions(+), 115 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6858dd3e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 783bfda..a2205ff 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
2.1.0
+ * Modify reconcile logic to always pick a tombstone over a counter cell
+ (CASSANDRA-7346)
* Avoid incremental compaction on Windows (CASSANDRA-7365)
* Fix exception when querying a composite-keyed table with a collection index
(CASSANDRA-7372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6858dd3e/src/java/org/apache/cassandra/db/AbstractCell.java
--
diff --git a/src/java/org/apache/cassandra/db/AbstractCell.java
b/src/java/org/apache/cassandra/db/AbstractCell.java
index 238b8c0..9dad6db 100644
--- a/src/java/org/apache/cassandra/db/AbstractCell.java
+++ b/src/java/org/apache/cassandra/db/AbstractCell.java
@@ -181,66 +181,59 @@ public abstract class AbstractCell implements Cell
: new BufferCell(name, value, timestamp);
}
-public static Cell diff(CounterCell a, Cell b)
+public Cell diffCounter(Cell cell)
{
-if (a.timestamp() b.timestamp())
-return b;
+assert this instanceof CounterCell : Wrong class type: + getClass();
+
+if (timestamp() cell.timestamp())
+return cell;
// Note that if at that point, cell can't be a tombstone. Indeed,
// cell is the result of merging us with other nodes results, and
// merging a CounterCell with a tombstone never return a tombstone
// unless that tombstone timestamp is greater that the CounterCell
// one.
-assert b instanceof CounterCell : Wrong class type: + b.getClass();
+assert cell instanceof CounterCell : Wrong class type: +
cell.getClass();
-if (a.timestampOfLastDelete() ((CounterCell)
b).timestampOfLastDelete())
-return b;
+if (((CounterCell) this).timestampOfLastDelete() ((CounterCell)
cell).timestampOfLastDelete())
+return cell;
-CounterContext.Relationship rel =
CounterCell.contextManager.diff(b.value(), a.value());
-return (rel == CounterContext.Relationship.GREATER_THAN || rel ==
CounterContext.Relationship.DISJOINT) ? b : null;
+CounterContext.Relationship rel =
CounterCell.contextManager.diff(cell.value(), value());
+return (rel == CounterContext.Relationship.GREATER_THAN || rel ==
CounterContext.Relationship.DISJOINT) ? cell : null;
}
/** This is temporary until we start creating Cells of the different type
(buffer vs. native) */
-public static Cell reconcile(CounterCell a, Cell b)
+public Cell reconcileCounter(Cell cell)
{
-assert (b instanceof CounterCell) || (b instanceof DeletedCell) :
Wrong class type: + b.getClass();
-
-// live + tombstone: track last tombstone
-if (!b.isLive()) // cannot be an
[1/2] git commit: Modify reconcile logic to always pick a tombstone over a counter cell
Repository: cassandra
Updated Branches:
refs/heads/trunk 295fe5dd0 - 23c2fa8c8
Modify reconcile logic to always pick a tombstone over a counter cell
patch by Aleksey Yeschenko; reviewed by Sylvain Lebresne for
CASSANDRA-7346
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6858dd3e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6858dd3e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6858dd3e
Branch: refs/heads/trunk
Commit: 6858dd3e3ab354c517503d310e50319be93cf6a2
Parents: 43ffb6b
Author: Aleksey Yeschenko alek...@apache.org
Authored: Thu Jun 19 11:54:33 2014 -0700
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Thu Jun 19 11:54:33 2014 -0700
--
CHANGES.txt | 2 +
.../org/apache/cassandra/db/AbstractCell.java | 69 +---
.../cassandra/db/ArrayBackedSortedColumns.java | 2 +-
.../apache/cassandra/db/BufferCounterCell.java | 4 +-
.../cassandra/db/BufferCounterUpdateCell.java | 15 ++---
.../org/apache/cassandra/db/ColumnFamily.java | 2 +-
.../org/apache/cassandra/db/ColumnIndex.java| 2 +-
.../org/apache/cassandra/db/DeletionInfo.java | 35 --
.../org/apache/cassandra/db/DeletionTime.java | 10 +++
.../apache/cassandra/db/NativeCounterCell.java | 6 +-
.../apache/cassandra/db/RangeTombstoneList.java | 31 ++---
.../cassandra/db/filter/ColumnCounter.java | 2 +-
test/unit/org/apache/cassandra/Util.java| 5 --
.../apache/cassandra/db/ColumnFamilyTest.java | 39 ++-
.../apache/cassandra/db/CounterCellTest.java| 20 ++
.../cassandra/utils/EncodedStreamsTest.java | 10 +--
16 files changed, 139 insertions(+), 115 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6858dd3e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 783bfda..a2205ff 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
2.1.0
+ * Modify reconcile logic to always pick a tombstone over a counter cell
+ (CASSANDRA-7346)
* Avoid incremental compaction on Windows (CASSANDRA-7365)
* Fix exception when querying a composite-keyed table with a collection index
(CASSANDRA-7372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6858dd3e/src/java/org/apache/cassandra/db/AbstractCell.java
--
diff --git a/src/java/org/apache/cassandra/db/AbstractCell.java
b/src/java/org/apache/cassandra/db/AbstractCell.java
index 238b8c0..9dad6db 100644
--- a/src/java/org/apache/cassandra/db/AbstractCell.java
+++ b/src/java/org/apache/cassandra/db/AbstractCell.java
@@ -181,66 +181,59 @@ public abstract class AbstractCell implements Cell
: new BufferCell(name, value, timestamp);
}
-public static Cell diff(CounterCell a, Cell b)
+public Cell diffCounter(Cell cell)
{
-if (a.timestamp() b.timestamp())
-return b;
+assert this instanceof CounterCell : Wrong class type: + getClass();
+
+if (timestamp() cell.timestamp())
+return cell;
// Note that if at that point, cell can't be a tombstone. Indeed,
// cell is the result of merging us with other nodes results, and
// merging a CounterCell with a tombstone never return a tombstone
// unless that tombstone timestamp is greater that the CounterCell
// one.
-assert b instanceof CounterCell : Wrong class type: + b.getClass();
+assert cell instanceof CounterCell : Wrong class type: +
cell.getClass();
-if (a.timestampOfLastDelete() ((CounterCell)
b).timestampOfLastDelete())
-return b;
+if (((CounterCell) this).timestampOfLastDelete() ((CounterCell)
cell).timestampOfLastDelete())
+return cell;
-CounterContext.Relationship rel =
CounterCell.contextManager.diff(b.value(), a.value());
-return (rel == CounterContext.Relationship.GREATER_THAN || rel ==
CounterContext.Relationship.DISJOINT) ? b : null;
+CounterContext.Relationship rel =
CounterCell.contextManager.diff(cell.value(), value());
+return (rel == CounterContext.Relationship.GREATER_THAN || rel ==
CounterContext.Relationship.DISJOINT) ? cell : null;
}
/** This is temporary until we start creating Cells of the different type
(buffer vs. native) */
-public static Cell reconcile(CounterCell a, Cell b)
+public Cell reconcileCounter(Cell cell)
{
-assert (b instanceof CounterCell) || (b instanceof DeletedCell) :
Wrong class type: + b.getClass();
-
-// live + tombstone: track last tombstone
-if (!b.isLive()) // cannot be an expired cell, so
[2/2] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/23c2fa8c Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/23c2fa8c Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/23c2fa8c Branch: refs/heads/trunk Commit: 23c2fa8c89ce67ebdb8f211a4c1dd8e2148bc785 Parents: 295fe5d 6858dd3 Author: Aleksey Yeschenko alek...@apache.org Authored: Thu Jun 19 11:59:19 2014 -0700 Committer: Aleksey Yeschenko alek...@apache.org Committed: Thu Jun 19 11:59:19 2014 -0700 -- CHANGES.txt | 2 + .../org/apache/cassandra/db/AbstractCell.java | 69 +--- .../cassandra/db/ArrayBackedSortedColumns.java | 2 +- .../apache/cassandra/db/BufferCounterCell.java | 4 +- .../cassandra/db/BufferCounterUpdateCell.java | 15 ++--- .../org/apache/cassandra/db/ColumnFamily.java | 2 +- .../org/apache/cassandra/db/ColumnIndex.java| 2 +- .../org/apache/cassandra/db/DeletionInfo.java | 35 -- .../org/apache/cassandra/db/DeletionTime.java | 10 +++ .../apache/cassandra/db/NativeCounterCell.java | 4 +- .../apache/cassandra/db/RangeTombstoneList.java | 31 ++--- .../cassandra/db/filter/ColumnCounter.java | 2 +- test/unit/org/apache/cassandra/Util.java| 5 -- .../apache/cassandra/db/ColumnFamilyTest.java | 39 ++- .../apache/cassandra/db/CounterCellTest.java| 20 ++ .../cassandra/utils/EncodedStreamsTest.java | 10 +-- 16 files changed, 139 insertions(+), 113 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/23c2fa8c/CHANGES.txt -- diff --cc CHANGES.txt index a837d28,a2205ff..ec1dc9d --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,17 -1,6 +1,19 @@@ +3.0 + * Move sstable RandomAccessReader to nio2, which allows using the + FILE_SHARE_DELETE flag on Windows (CASSANDRA-4050) + * Remove CQL2 (CASSANDRA-5918) + * Add Thrift get_multi_slice call (CASSANDRA-6757) + * Optimize fetching multiple cells by name (CASSANDRA-6933) + * Allow compilation in java 8 (CASSANDRA-7208) + * Make incremental repair default (CASSANDRA-7250) + * Enable code coverage thru JaCoCo (CASSANDRA-7226) + * Switch external naming of 'column families' to 'tables' (CASSANDRA-4369) + + + 2.1.0 + * Modify reconcile logic to always pick a tombstone over a counter cell +(CASSANDRA-7346) * Avoid incremental compaction on Windows (CASSANDRA-7365) * Fix exception when querying a composite-keyed table with a collection index (CASSANDRA-7372) http://git-wip-us.apache.org/repos/asf/cassandra/blob/23c2fa8c/src/java/org/apache/cassandra/db/ArrayBackedSortedColumns.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/23c2fa8c/src/java/org/apache/cassandra/db/ColumnFamily.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/23c2fa8c/test/unit/org/apache/cassandra/Util.java --
[jira] [Commented] (CASSANDRA-7062) Extension of static columns for compound cluster keys
[
https://issues.apache.org/jira/browse/CASSANDRA-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037688#comment-14037688
]
Constance Eustace commented on CASSANDRA-7062:
--
And the static local column would allow paxos optimistic locking for
individual values and properties on the entity's row...
Extension of static columns for compound cluster keys
-
Key: CASSANDRA-7062
URL: https://issues.apache.org/jira/browse/CASSANDRA-7062
Project: Cassandra
Issue Type: New Feature
Reporter: Constance Eustace
CASSANDRA-6561 implemented static columns for a given partition key.
What this is proposing for a compound cluster key is a static column that is
static at intermediate parts of a compound cluster key. This example shows a
table modelling a moderately complex EAV pattern :
{code}
CREATE TABLE t (
entityID text,
propertyName text,
valueIndex text,
entityName text static (entityID),
propertyType text static (entityID, propertyName),
propertyRelations Listtext static (entityID, propertyName),
data text,
PRIMARY KEY (entityID, (propertyName,valueIndex))
)
{code}
So in this example has the following static columns:
- the entityName column behaves exactly as CASSANDRA-6561 details, so all
cluster rows have the same value
- the propertyType and propertyRelations columns are static with respect to
the remaining parts of the cluster key (that is, across all valueIndex values
for a given propertyName), so an update to those values for an entityID and a
propertyName will be shared/constant by all the value rows...
Is this a relatively simple extension of the same mechanism in -6561, or is
this a whoa, you have no idea what you are proposing?
Sample data:
Mary and Jane aren't married...
{code}
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0001','MARY MATALIN','married','SingleValue','0','false');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0002','JANE JOHNSON','married','SingleValue','0','false');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex)
VALUES ('0001','MARY MATALIN','kids','NOVALUE','');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex)
VALUES ('0002','JANE JOHNSON','kids','NOVALUE','');
{code}
{code}
SELECT * FROM t:
0001 MARY MATALIN married SingleValue 0 false
0001 MARY MATALIN kids NOVALUE null
0002 JANE JOHNSON married SingleValue 0 false
0002 JANE JOHNSON kids NOVALUE null
{code}
Then mary and jane get married (so the entityName column that is static on
the partition key is updated just like CASSANDRA-6561 )
{code}
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0001','MARY SMITH','married','SingleValue','0','TRUE');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0002','JANE JONES','married','SingleValue','0','TRUE');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids NOVALUE null
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids NOVALUE null
{code}
Then mary and jane have a kid, so we add another value to the kids attribute:
{code}
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0001','kids','SingleValue','0','JIM-BOB');
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0002','kids','SingleValue','0','JENNY');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids SingleValuenull
0001 MARY SMITH kids SingleValue 0 JIM-BOB
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids SingleValuenull
0002 JANE JONES kids SingleValue 0 JENNY
{code}
Then Mary has ANOTHER kid, which demonstrates the partially static column
relative to the cluster key, as ALL value rows for the property 'kids' get
updated to the new value:
{code}
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0001','kids','MultiValue','1','HARRY');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids MultiValue null
0001 MARY SMITH kids MultiValue 0 JIM-BOB
0001 MARY SMITH kids MultiValue 1 HARRY
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids SingleValuenull
0002 JANE JONES kids SingleValue 0 JENNY
{code}
... ok, hopefully that example isn't TOO complicated.
[jira] [Commented] (CASSANDRA-7062) Extension of static columns for compound cluster keys
[
https://issues.apache.org/jira/browse/CASSANDRA-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037683#comment-14037683
]
Constance Eustace commented on CASSANDRA-7062:
--
My particular use case is an Entity-Attribute-Value model implementation. For
efficiency, the ability to have static-local columns for the values across the
data elements in the value, and static-local columns for all the values in a
property are the desired endpoint of this.
Combine that with better extension of the IN clause for compound column keys,
and my connection overhead drops quite a lot when pulling an entity and
property subsets.
In RDBMS, you'd obviously have separate Entity, Property, Value, and Data
tables for the complex use cases of E-A-V, but since cassandra doesn't join
well, denormalizing those three or four tables into a single row and using
static to avoid duplication of the data as you denormalize those nested
tables would be convenient...
Extension of static columns for compound cluster keys
-
Key: CASSANDRA-7062
URL: https://issues.apache.org/jira/browse/CASSANDRA-7062
Project: Cassandra
Issue Type: New Feature
Reporter: Constance Eustace
CASSANDRA-6561 implemented static columns for a given partition key.
What this is proposing for a compound cluster key is a static column that is
static at intermediate parts of a compound cluster key. This example shows a
table modelling a moderately complex EAV pattern :
{code}
CREATE TABLE t (
entityID text,
propertyName text,
valueIndex text,
entityName text static (entityID),
propertyType text static (entityID, propertyName),
propertyRelations Listtext static (entityID, propertyName),
data text,
PRIMARY KEY (entityID, (propertyName,valueIndex))
)
{code}
So in this example has the following static columns:
- the entityName column behaves exactly as CASSANDRA-6561 details, so all
cluster rows have the same value
- the propertyType and propertyRelations columns are static with respect to
the remaining parts of the cluster key (that is, across all valueIndex values
for a given propertyName), so an update to those values for an entityID and a
propertyName will be shared/constant by all the value rows...
Is this a relatively simple extension of the same mechanism in -6561, or is
this a whoa, you have no idea what you are proposing?
Sample data:
Mary and Jane aren't married...
{code}
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0001','MARY MATALIN','married','SingleValue','0','false');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0002','JANE JOHNSON','married','SingleValue','0','false');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex)
VALUES ('0001','MARY MATALIN','kids','NOVALUE','');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex)
VALUES ('0002','JANE JOHNSON','kids','NOVALUE','');
{code}
{code}
SELECT * FROM t:
0001 MARY MATALIN married SingleValue 0 false
0001 MARY MATALIN kids NOVALUE null
0002 JANE JOHNSON married SingleValue 0 false
0002 JANE JOHNSON kids NOVALUE null
{code}
Then mary and jane get married (so the entityName column that is static on
the partition key is updated just like CASSANDRA-6561 )
{code}
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0001','MARY SMITH','married','SingleValue','0','TRUE');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0002','JANE JONES','married','SingleValue','0','TRUE');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids NOVALUE null
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids NOVALUE null
{code}
Then mary and jane have a kid, so we add another value to the kids attribute:
{code}
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0001','kids','SingleValue','0','JIM-BOB');
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0002','kids','SingleValue','0','JENNY');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids SingleValuenull
0001 MARY SMITH kids SingleValue 0 JIM-BOB
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids SingleValuenull
0002 JANE JONES kids SingleValue 0 JENNY
{code}
Then Mary has ANOTHER kid, which demonstrates the partially static column
relative to the cluster key, as ALL
[jira] [Commented] (CASSANDRA-7062) Extension of static columns for compound cluster keys
[
https://issues.apache.org/jira/browse/CASSANDRA-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037686#comment-14037686
]
Constance Eustace commented on CASSANDRA-7062:
--
EAV lending itself to many many use cases, such as Content Managment Systems
and others..
Extension of static columns for compound cluster keys
-
Key: CASSANDRA-7062
URL: https://issues.apache.org/jira/browse/CASSANDRA-7062
Project: Cassandra
Issue Type: New Feature
Reporter: Constance Eustace
CASSANDRA-6561 implemented static columns for a given partition key.
What this is proposing for a compound cluster key is a static column that is
static at intermediate parts of a compound cluster key. This example shows a
table modelling a moderately complex EAV pattern :
{code}
CREATE TABLE t (
entityID text,
propertyName text,
valueIndex text,
entityName text static (entityID),
propertyType text static (entityID, propertyName),
propertyRelations Listtext static (entityID, propertyName),
data text,
PRIMARY KEY (entityID, (propertyName,valueIndex))
)
{code}
So in this example has the following static columns:
- the entityName column behaves exactly as CASSANDRA-6561 details, so all
cluster rows have the same value
- the propertyType and propertyRelations columns are static with respect to
the remaining parts of the cluster key (that is, across all valueIndex values
for a given propertyName), so an update to those values for an entityID and a
propertyName will be shared/constant by all the value rows...
Is this a relatively simple extension of the same mechanism in -6561, or is
this a whoa, you have no idea what you are proposing?
Sample data:
Mary and Jane aren't married...
{code}
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0001','MARY MATALIN','married','SingleValue','0','false');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0002','JANE JOHNSON','married','SingleValue','0','false');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex)
VALUES ('0001','MARY MATALIN','kids','NOVALUE','');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex)
VALUES ('0002','JANE JOHNSON','kids','NOVALUE','');
{code}
{code}
SELECT * FROM t:
0001 MARY MATALIN married SingleValue 0 false
0001 MARY MATALIN kids NOVALUE null
0002 JANE JOHNSON married SingleValue 0 false
0002 JANE JOHNSON kids NOVALUE null
{code}
Then mary and jane get married (so the entityName column that is static on
the partition key is updated just like CASSANDRA-6561 )
{code}
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0001','MARY SMITH','married','SingleValue','0','TRUE');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0002','JANE JONES','married','SingleValue','0','TRUE');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids NOVALUE null
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids NOVALUE null
{code}
Then mary and jane have a kid, so we add another value to the kids attribute:
{code}
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0001','kids','SingleValue','0','JIM-BOB');
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0002','kids','SingleValue','0','JENNY');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids SingleValuenull
0001 MARY SMITH kids SingleValue 0 JIM-BOB
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids SingleValuenull
0002 JANE JONES kids SingleValue 0 JENNY
{code}
Then Mary has ANOTHER kid, which demonstrates the partially static column
relative to the cluster key, as ALL value rows for the property 'kids' get
updated to the new value:
{code}
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0001','kids','MultiValue','1','HARRY');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids MultiValue null
0001 MARY SMITH kids MultiValue 0 JIM-BOB
0001 MARY SMITH kids MultiValue 1 HARRY
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids SingleValuenull
0002 JANE JONES kids SingleValue 0 JENNY
{code}
... ok, hopefully that example isn't TOO complicated. Yes, there's a stupid
hack bug in
[jira] [Commented] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037705#comment-14037705
]
Drew Kutcharian commented on CASSANDRA-7304:
+1 with {{IGNORE NULLS}} it's much more consistent with {{ALLOW FILTERING}}
Ability to distinguish between NULL and UNSET values in Prepared Statements
---
Key: CASSANDRA-7304
URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
Project: Cassandra
Issue Type: Improvement
Reporter: Drew Kutcharian
Currently Cassandra inserts tombstones when a value of a column is bound to
NULL in a prepared statement. At higher insert rates managing all these
tombstones becomes an unnecessary overhead. This limits the usefulness of the
prepared statements since developers have to either create multiple prepared
statements (each with a different combination of column names, which at times
is just unfeasible because of the sheer number of possible combinations) or
fall back to using regular (non-prepared) statements.
This JIRA is here to explore the possibility of either:
A. Have a flag on prepared statements that once set, tells Cassandra to
ignore null columns
or
B. Have an UNSET value which makes Cassandra skip the null columns and not
tombstone them
Basically, in the context of a prepared statement, a null value means delete,
but we don’t have anything that means ignore (besides creating a new
prepared statement without the ignored column).
Please refer to the original conversation on DataStax Java Driver mailing
list for more background:
https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7062) Extension of static columns for compound cluster keys
[
https://issues.apache.org/jira/browse/CASSANDRA-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037688#comment-14037688
]
Constance Eustace edited comment on CASSANDRA-7062 at 6/19/14 7:17 PM:
---
And the static local column would allow paxos optimistic locking for
individual values and properties on the entity's row...
was (Author: cowardlydragon):
And the static local column would allow paxos optimistic locking for
individual values and properties on the entity's row...
Extension of static columns for compound cluster keys
-
Key: CASSANDRA-7062
URL: https://issues.apache.org/jira/browse/CASSANDRA-7062
Project: Cassandra
Issue Type: New Feature
Reporter: Constance Eustace
CASSANDRA-6561 implemented static columns for a given partition key.
What this is proposing for a compound cluster key is a static column that is
static at intermediate parts of a compound cluster key. This example shows a
table modelling a moderately complex EAV pattern :
{code}
CREATE TABLE t (
entityID text,
propertyName text,
valueIndex text,
entityName text static (entityID),
propertyType text static (entityID, propertyName),
propertyRelations Listtext static (entityID, propertyName),
data text,
PRIMARY KEY (entityID, (propertyName,valueIndex))
)
{code}
So in this example has the following static columns:
- the entityName column behaves exactly as CASSANDRA-6561 details, so all
cluster rows have the same value
- the propertyType and propertyRelations columns are static with respect to
the remaining parts of the cluster key (that is, across all valueIndex values
for a given propertyName), so an update to those values for an entityID and a
propertyName will be shared/constant by all the value rows...
Is this a relatively simple extension of the same mechanism in -6561, or is
this a whoa, you have no idea what you are proposing?
Sample data:
Mary and Jane aren't married...
{code}
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0001','MARY MATALIN','married','SingleValue','0','false');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0002','JANE JOHNSON','married','SingleValue','0','false');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex)
VALUES ('0001','MARY MATALIN','kids','NOVALUE','');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex)
VALUES ('0002','JANE JOHNSON','kids','NOVALUE','');
{code}
{code}
SELECT * FROM t:
0001 MARY MATALIN married SingleValue 0 false
0001 MARY MATALIN kids NOVALUE null
0002 JANE JOHNSON married SingleValue 0 false
0002 JANE JOHNSON kids NOVALUE null
{code}
Then mary and jane get married (so the entityName column that is static on
the partition key is updated just like CASSANDRA-6561 )
{code}
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0001','MARY SMITH','married','SingleValue','0','TRUE');
INSERT INTO t (entityID, entityName, propertyName, propertyType, valueIndex,
data) VALUES ('0002','JANE JONES','married','SingleValue','0','TRUE');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids NOVALUE null
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids NOVALUE null
{code}
Then mary and jane have a kid, so we add another value to the kids attribute:
{code}
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0001','kids','SingleValue','0','JIM-BOB');
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0002','kids','SingleValue','0','JENNY');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids SingleValuenull
0001 MARY SMITH kids SingleValue 0 JIM-BOB
0002 JANE JONES married SingleValue 0 TRUE
0002 JANE JONES kids SingleValuenull
0002 JANE JONES kids SingleValue 0 JENNY
{code}
Then Mary has ANOTHER kid, which demonstrates the partially static column
relative to the cluster key, as ALL value rows for the property 'kids' get
updated to the new value:
{code}
INSERT INTO t (entityID, propertyName, propertyType, valueIndex,data) VALUES
('0001','kids','MultiValue','1','HARRY');
{code}
{code}
SELECT * FROM t:
0001 MARY SMITH married SingleValue 0 TRUE
0001 MARY SMITH kids MultiValue null
0001 MARY SMITH kids MultiValue 0 JIM-BOB
0001 MARY SMITH kids MultiValue 1 HARRY
0002 JANE
buildbot success in ASF Buildbot on cassandra-2.1
The Buildbot has detected a restored build on builder cassandra-2.1 while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-2.1/builds/162 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch cassandra-2.1] 6858dd3e3ab354c517503d310e50319be93cf6a2 Blamelist: Aleksey Yeschenko alek...@apache.org Build succeeded! sincerely, -The Buildbot
[jira] [Commented] (CASSANDRA-7418) Cannot upgrade: Tried to create duplicate hard link
[ https://issues.apache.org/jira/browse/CASSANDRA-7418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037783#comment-14037783 ] Tom van den Berge commented on CASSANDRA-7418: -- You are right! Removing all pre-sstablemetamigration snapshots solved it. Thanks a lot! Cannot upgrade: Tried to create duplicate hard link --- Key: CASSANDRA-7418 URL: https://issues.apache.org/jira/browse/CASSANDRA-7418 Project: Cassandra Issue Type: Bug Environment: OSX Reporter: Tom van den Berge Priority: Critical I'm trying to migrate a cluster from 1.2.14 to 2.0.8. When starting up 2.0.8, I'm seeing the following error in the logs: INFO 17:40:25,405 Snapshotting drillster, Account to pre-sstablemetamigration ERROR 17:40:25,407 Exception encountered during startup java.lang.RuntimeException: Tried to create duplicate hard link to /Users/tom/cassandra-data/data/drillster/Account/snapshots/pre-sstablemetamigration/drillster-Account-ic-65-Filter.db at org.apache.cassandra.io.util.FileUtils.createHardLink(FileUtils.java:75) at org.apache.cassandra.db.compaction.LegacyLeveledManifest.snapshotWithoutCFS(LegacyLeveledManifest.java:129) at org.apache.cassandra.db.compaction.LegacyLeveledManifest.migrateManifests(LegacyLeveledManifest.java:91) at org.apache.cassandra.db.compaction.LeveledManifest.maybeMigrateManifests(LeveledManifest.java:617) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:274) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585) As a result, I can't start up 2.0.8, and switching back to 1.2.14 also doesn't work. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CASSANDRA-7418) Cannot upgrade: Tried to create duplicate hard link
[ https://issues.apache.org/jira/browse/CASSANDRA-7418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom van den Berge resolved CASSANDRA-7418. -- Resolution: Not a Problem Cannot upgrade: Tried to create duplicate hard link --- Key: CASSANDRA-7418 URL: https://issues.apache.org/jira/browse/CASSANDRA-7418 Project: Cassandra Issue Type: Bug Environment: OSX Reporter: Tom van den Berge Priority: Critical I'm trying to migrate a cluster from 1.2.14 to 2.0.8. When starting up 2.0.8, I'm seeing the following error in the logs: INFO 17:40:25,405 Snapshotting drillster, Account to pre-sstablemetamigration ERROR 17:40:25,407 Exception encountered during startup java.lang.RuntimeException: Tried to create duplicate hard link to /Users/tom/cassandra-data/data/drillster/Account/snapshots/pre-sstablemetamigration/drillster-Account-ic-65-Filter.db at org.apache.cassandra.io.util.FileUtils.createHardLink(FileUtils.java:75) at org.apache.cassandra.db.compaction.LegacyLeveledManifest.snapshotWithoutCFS(LegacyLeveledManifest.java:129) at org.apache.cassandra.db.compaction.LegacyLeveledManifest.migrateManifests(LegacyLeveledManifest.java:91) at org.apache.cassandra.db.compaction.LeveledManifest.maybeMigrateManifests(LeveledManifest.java:617) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:274) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585) As a result, I can't start up 2.0.8, and switching back to 1.2.14 also doesn't work. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7398) Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL
[ https://issues.apache.org/jira/browse/CASSANDRA-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037890#comment-14037890 ] Ala' Alkhaldi commented on CASSANDRA-7398: -- A prefix with a single slash (i.e. file:/) or double slash (i.e. file:// ) also works using windows CMD. However, applying this update will replace those prefixes by file:///file:/ and file:///file:// respectively which do not work. Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL Key: CASSANDRA-7398 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398 Project: Cassandra Issue Type: Bug Components: Core Environment: Cassandra 2.1.0-rc1-SNAPSHOT, Win 7 Reporter: Marco Tulio Avila Cerón Assignee: Marco Tulio Avila Cerón Priority: Minor Labels: lhf, patch Fix For: 2.1 rc2 Attachments: CASSANDRA-7398_prefix_v2.patch, CASSANDRA-7398_prefix_v3.patch, CASSANDRA-7398_prefix_v4.patch, trunk-7398_v5.txt Original Estimate: 2h Remaining Estimate: 2h The parameter in the VM options -Dcassandra.config= needs file:/// Allow the user to have optional file:/// when loading the config file from the filesystem -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CASSANDRA-7398) Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL
[ https://issues.apache.org/jira/browse/CASSANDRA-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reopened CASSANDRA-7398: - Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL Key: CASSANDRA-7398 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398 Project: Cassandra Issue Type: Bug Components: Core Environment: Cassandra 2.1.0-rc1-SNAPSHOT, Win 7 Reporter: Marco Tulio Avila Cerón Assignee: Marco Tulio Avila Cerón Priority: Minor Labels: lhf, patch Fix For: 2.1 rc2 Attachments: CASSANDRA-7398_prefix_v2.patch, CASSANDRA-7398_prefix_v3.patch, CASSANDRA-7398_prefix_v4.patch, trunk-7398_v5.txt Original Estimate: 2h Remaining Estimate: 2h The parameter in the VM options -Dcassandra.config= needs file:/// Allow the user to have optional file:/// when loading the config file from the filesystem -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7341) Emit metrics related to CAS/Paxos
[ https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037922#comment-14037922 ] sankalp kohli commented on CASSANDRA-7341: -- Sure. Let me do that. I am thinking about adding top k for contenting row. We need to know more about contention. Adding number of contentions in the writetimout will help a lot because it will tell us whether the failure is due to contention. Emit metrics related to CAS/Paxos - Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor Attachments: CASClientRequestMetrics.java, trunk-7341.diff We can emit metrics based on Paxos. One of them is when there is contention. I will add more metric in this JIRA if it is helpful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6702) Upgrading node uses the wrong port in gossiping
[ https://issues.apache.org/jira/browse/CASSANDRA-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037934#comment-14037934 ] Jason Brown commented on CASSANDRA-6702: [~timiblossom] Do you remember if the nodes being connected to were already upgraded to 1.2? Were they seeds? Upgrading node uses the wrong port in gossiping --- Key: CASSANDRA-6702 URL: https://issues.apache.org/jira/browse/CASSANDRA-6702 Project: Cassandra Issue Type: Bug Components: Core Environment: 1.1.7, AWS, Ec2MultiRegionSnitch Reporter: Minh Do Priority: Minor Fix For: 1.2.17 When upgrading a node in 1.1.7 (or 1.1.11) cluster to 1.2.15 and inspecting the gossip information on port/Ip, I could see that the upgrading node (1.2 version) communicates to one other node in the same region using Public IP and non-encrypted port. For the rest, the upgrading node uses the correct ports and IPs to communicate in this manner: Same region: private IP and non-encrypted port and Different region: public IP and encrypted port Because there is one node like this (or 2 out of 12 nodes cluster in which nodes are split equally on 2 AWS regions), we have to modify Security Group to allow the new traffics. Without modifying the SG, the 95th and 99th latencies for both reads and writes in the cluster are very bad (due to RPC timeout). Inspecting closer, that upgraded node (1.2 node) is contributing to all of the high latencies whenever it acts as a coordinator node. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-6702) Upgrading node uses the wrong port in gossiping
[ https://issues.apache.org/jira/browse/CASSANDRA-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037934#comment-14037934 ] Jason Brown edited comment on CASSANDRA-6702 at 6/19/14 9:38 PM: - [~timiblossom] Do you remember if the nodes being connected to (over the publicIP/non-secure port) were already upgraded to 1.2? Were they seeds? was (Author: jasobrown): [~timiblossom] Do you remember if the nodes being connected to were already upgraded to 1.2? Were they seeds? Upgrading node uses the wrong port in gossiping --- Key: CASSANDRA-6702 URL: https://issues.apache.org/jira/browse/CASSANDRA-6702 Project: Cassandra Issue Type: Bug Components: Core Environment: 1.1.7, AWS, Ec2MultiRegionSnitch Reporter: Minh Do Priority: Minor Fix For: 1.2.17 When upgrading a node in 1.1.7 (or 1.1.11) cluster to 1.2.15 and inspecting the gossip information on port/Ip, I could see that the upgrading node (1.2 version) communicates to one other node in the same region using Public IP and non-encrypted port. For the rest, the upgrading node uses the correct ports and IPs to communicate in this manner: Same region: private IP and non-encrypted port and Different region: public IP and encrypted port Because there is one node like this (or 2 out of 12 nodes cluster in which nodes are split equally on 2 AWS regions), we have to modify Security Group to allow the new traffics. Without modifying the SG, the 95th and 99th latencies for both reads and writes in the cluster are very bad (due to RPC timeout). Inspecting closer, that upgraded node (1.2 node) is contributing to all of the high latencies whenever it acts as a coordinator node. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7390) MoveTest fails intermittently
[
https://issues.apache.org/jira/browse/CASSANDRA-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-7390:
---
Attachment: 7390_lockpendingcalc.txt
7390_conservative_v1.txt
Looks like I opened Pandora's Box on this one. A couple patches:
7390_conservative_v1.txt: cleans up a few underlying issues causing failures in
MoveTest. The logic on PendingRangeCalculatorService.blockUntilFinished()
relied on ThreadPoolExecutor.getActiveCount() to determine the # of running
threads - checking the documentation shows:
{code:title=getActiveCount}
/**
* Returns the approximate number of threads that are actively
* executing tasks.
*
* @return the number of threads
*/
public int getActiveCount() {...}
{code}
Changing that to an AtomicBoolean sentinel and getting rid of the now
unnecessary DiscardPolicy for extra threads took care of one race.
Also cleaned up the inter-test StorageService / TokenMetadata reset logic in
MoveTest.java, added some missing fields to TokenMetadata.resetUnsafe(), and
added another blockUntilFinished between a couple of back-to-back onChange
calls in testSimultaneousMove() that would infrequently race on
PendingRangeCalculatorService.update() calls.
With the above changes, unit test failure rate drops from 1 out of 5 runs to 1
out of 100 on average.
I'm a little wary of what that back-to-back onChange call seems to imply about
the design of the PendingRangeCalculatorService's queue'ing model - it looks
like we can have a race where we hit the PendingRangeCalculatorService for an
update while another one is already running, drop the new update() request with
the expectation that it'll be caught by the PendingRangeTask that's in-flight,
and have our logical update missed until the next update() call. This may just
be an artifact of unit-tests hitting onChange back-to-back being
non-representative of real use-cases timing.
7390_lockpendingcalc.txt: As to the final 1% failure - from my initial
inspection of TokenMetadata code and flow, it looks like we're pulling out
values from internal data structures in multiple discrete atomic steps in
calculatePendingRanges. This leaves scheduling holes where other threads
(variety of onChange paths, some nodetool commands, and brute-force unit-tests)
can hop in, grab the write lock, and make changes to TokenMetadata while our
pending calc is active:
{code:title=2 discrete read locks example}
BiMultiValMapToken, InetAddress bootstrapTokens = tm.getBootstrapTokens();
// No lock held here
SetInetAddress leavingEndpoints = tm.getLeavingEndpoints();
{code}
This patch migrates the pending range calculation inside TokenMetadata while
holding a readlock for its entirety and addresses the potential race that
occurs there (0 failures in 1200 runs) - it also holds the readlock on
TokenMetadata for a pretty long chunk of time (8-9000 usec on a trivial
unit-test case on a laptop). That being said, reads will still operate during
these time windows and the infrequency of writes blocking / showing this race
indicates to me that we shouldn't have serious contention with this change.
Attaching a separate patch for moving pending range calc to TokenMetadata as
that's more invasive and might just be a race we're comfortable accepting to
keep contention down in the structure.
MoveTest fails intermittently
-
Key: CASSANDRA-7390
URL: https://issues.apache.org/jira/browse/CASSANDRA-7390
Project: Cassandra
Issue Type: Bug
Reporter: Joshua McKenzie
Assignee: Joshua McKenzie
Priority: Minor
Fix For: 3.0
Attachments: 7390_conservative_v1.txt, 7390_lockpendingcalc.txt
Reproduce with:
for i in `seq 1 50`; do runTest MoveTest moveTestFailures.txt;done
Looks to fail roughly once out of every 5 runs or so
{code:title=failure}
[junit] Testcase:
newTestWriteEndpointsDuringMove(org.apache.cassandra.service.MoveTest):
FAILED
[junit] mismatched number of moved token expected:0 but was:1
[junit] junit.framework.AssertionFailedError: mismatched number of moved
token expected:0 but was:1
[junit] at
org.apache.cassandra.service.MoveTest.newTestWriteEndpointsDuringMove(MoveTest.java:140)
{code}
Edit: had this as Windows-only - turns out it's failing on on *nix as well
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7398) Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL
[ https://issues.apache.org/jira/browse/CASSANDRA-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037995#comment-14037995 ] Marco Tulio Avila Cerón commented on CASSANDRA-7398: true needs to be checked if the string startsWith file:/, I will write the junit test as well. Using the -Dcassandra.config VM param needs a file:/// prefix for the supplied URL Key: CASSANDRA-7398 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398 Project: Cassandra Issue Type: Bug Components: Core Environment: Cassandra 2.1.0-rc1-SNAPSHOT, Win 7 Reporter: Marco Tulio Avila Cerón Assignee: Marco Tulio Avila Cerón Priority: Minor Labels: lhf, patch Fix For: 2.1 rc2 Attachments: CASSANDRA-7398_prefix_v2.patch, CASSANDRA-7398_prefix_v3.patch, CASSANDRA-7398_prefix_v4.patch, trunk-7398_v5.txt Original Estimate: 2h Remaining Estimate: 2h The parameter in the VM options -Dcassandra.config= needs file:/// Allow the user to have optional file:/// when loading the config file from the filesystem -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7350) Decommissioning nodes borks the seed node - can't add additional nodes
[ https://issues.apache.org/jira/browse/CASSANDRA-7350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038001#comment-14038001 ] Shawn Kumar commented on CASSANDRA-7350: Was unable to reproduce this, looks like it's been fixed. Decommissioning nodes borks the seed node - can't add additional nodes -- Key: CASSANDRA-7350 URL: https://issues.apache.org/jira/browse/CASSANDRA-7350 Project: Cassandra Issue Type: Bug Components: Core Environment: Ubuntu using the auto-clustering AMI Reporter: Steven Lowenthal Assignee: Shawn Kumar Priority: Minor Fix For: 2.0.9 1) Launch a 4 node cluster - I used the auto-clustering AMI (you get nodes 0-3) 2) decommission that last 2 nodes (nodes , leaving a 2 node cluster) 3) wipe the data directories from node 2 4) bootstrap node2 - it won't join unable to gossip with any seeds. If you bootstrap the node a second time, it will join. However if you try to bootstrap node 3, it will also fail. I discovered that bouncing the seed node fixes the problem. I think it cropped up in 2.0.7. Error: ERROR [main] 2014-06-03 21:52:46,649 CassandraDaemon.java (line 497) Exception encountered during startup java.lang.RuntimeException: Unable to gossip with any seeds at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1193) at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:447) at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:656) at org.apache.cassandra.service.StorageService.initServer(StorageService.java:612) at org.apache.cassandra.service.StorageService.initServer(StorageService.java:505) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:362) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:480) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:569) ERROR [StorageServiceShutdownHook] 2014-06-03 21:52:46,741 CassandraDaemon.java (line 198) Exception in thread Thread[StorageServi -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7350) Decommissioning nodes borks the seed node - can't add additional nodes
[ https://issues.apache.org/jira/browse/CASSANDRA-7350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Kumar updated CASSANDRA-7350: --- Labels: qa-resolved (was: ) Decommissioning nodes borks the seed node - can't add additional nodes -- Key: CASSANDRA-7350 URL: https://issues.apache.org/jira/browse/CASSANDRA-7350 Project: Cassandra Issue Type: Bug Components: Core Environment: Ubuntu using the auto-clustering AMI Reporter: Steven Lowenthal Assignee: Shawn Kumar Priority: Minor Labels: qa-resolved Fix For: 2.0.9 1) Launch a 4 node cluster - I used the auto-clustering AMI (you get nodes 0-3) 2) decommission that last 2 nodes (nodes , leaving a 2 node cluster) 3) wipe the data directories from node 2 4) bootstrap node2 - it won't join unable to gossip with any seeds. If you bootstrap the node a second time, it will join. However if you try to bootstrap node 3, it will also fail. I discovered that bouncing the seed node fixes the problem. I think it cropped up in 2.0.7. Error: ERROR [main] 2014-06-03 21:52:46,649 CassandraDaemon.java (line 497) Exception encountered during startup java.lang.RuntimeException: Unable to gossip with any seeds at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1193) at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:447) at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:656) at org.apache.cassandra.service.StorageService.initServer(StorageService.java:612) at org.apache.cassandra.service.StorageService.initServer(StorageService.java:505) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:362) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:480) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:569) ERROR [StorageServiceShutdownHook] 2014-06-03 21:52:46,741 CassandraDaemon.java (line 198) Exception in thread Thread[StorageServi -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7344) Read at SERIAL can lead to unnecessary contention
[ https://issues.apache.org/jira/browse/CASSANDRA-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038008#comment-14038008 ] sankalp kohli commented on CASSANDRA-7344: -- Besides, the last accepted commit will generally not be empty unless no update have ever been committed on the partition, so in practice we'd always have to do the prepare and thus have 2 round-trips in general instead of one. I was not clear before. What I am proposing is that we gather last accepted ballot from all eligible replicas based on CL and if there is anything pending, then do a full prepare propose or call the beginAndRepairPaxos method. // If we have an in-progress ballot greater than the MRC we know, then it's an in-progress round that // needs to be completed, so do it. if (!inProgress.update.isEmpty() inProgress.isAfter(mostRecent)) Here in the code, we do a prepare phase to find out about any pending operation and try to finish it. So we'd need one round-trip to get the last accepted commit, which is not better that doing the prepare. It is better since there won't be any contention if more than one read is issued for the same row. Here is an example Say for a row A, all previous CAS operations have finished. There is nothing pending. Now 2 reads come for the same row at SERIAL, they can potentially contend with each other in the prepare phase. This contention can be avoided by asking eligible replicas for unfinished operation for the given row and not doing a prepare. Read at SERIAL can lead to unnecessary contention -- Key: CASSANDRA-7344 URL: https://issues.apache.org/jira/browse/CASSANDRA-7344 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor If two clients are doing a read at serial on the same row, it does a full prepare step to figure out whether there is any updates or cas in flight or uncompleted. This can cause contention between then leading to waste of time in retrying. One of the request will not get a promise and will need to sleep. Instead they can check whether there is anything to finish and if not continue. If there is something to be done, then they can do the full prepare. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CASSANDRA-7350) Decommissioning nodes borks the seed node - can't add additional nodes
[ https://issues.apache.org/jira/browse/CASSANDRA-7350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-7350. - Resolution: Cannot Reproduce Decommissioning nodes borks the seed node - can't add additional nodes -- Key: CASSANDRA-7350 URL: https://issues.apache.org/jira/browse/CASSANDRA-7350 Project: Cassandra Issue Type: Bug Components: Core Environment: Ubuntu using the auto-clustering AMI Reporter: Steven Lowenthal Assignee: Shawn Kumar Priority: Minor Labels: qa-resolved Fix For: 2.0.9 1) Launch a 4 node cluster - I used the auto-clustering AMI (you get nodes 0-3) 2) decommission that last 2 nodes (nodes , leaving a 2 node cluster) 3) wipe the data directories from node 2 4) bootstrap node2 - it won't join unable to gossip with any seeds. If you bootstrap the node a second time, it will join. However if you try to bootstrap node 3, it will also fail. I discovered that bouncing the seed node fixes the problem. I think it cropped up in 2.0.7. Error: ERROR [main] 2014-06-03 21:52:46,649 CassandraDaemon.java (line 497) Exception encountered during startup java.lang.RuntimeException: Unable to gossip with any seeds at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1193) at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:447) at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:656) at org.apache.cassandra.service.StorageService.initServer(StorageService.java:612) at org.apache.cassandra.service.StorageService.initServer(StorageService.java:505) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:362) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:480) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:569) ERROR [StorageServiceShutdownHook] 2014-06-03 21:52:46,741 CassandraDaemon.java (line 198) Exception in thread Thread[StorageServi -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7341) Emit metrics related to CAS/Paxos
[ https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038039#comment-14038039 ] sankalp kohli commented on CASSANDRA-7341: -- [~jbellis] You mean I move the metrics in PaxosState to CF Metrics? This make sense to move these to individual CFs metrics. The metrics in StorageProxy is on lines of other ClientRequestMetrics we have there. I am not sure whether these belong to CF Metrics. Emit metrics related to CAS/Paxos - Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor Attachments: CASClientRequestMetrics.java, trunk-7341.diff We can emit metrics based on Paxos. One of them is when there is contention. I will add more metric in this JIRA if it is helpful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7341) Emit metrics related to CAS/Paxos
[ https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038039#comment-14038039 ] sankalp kohli edited comment on CASSANDRA-7341 at 6/19/14 10:48 PM: [~jbellis] You mean I move the metrics in PaxosState to CF Metrics? This make sense to move these to individual CFs metrics. The metrics in StorageProxy is on lines of other ClientRequestMetrics we have there. I am not sure whether these belong to CF Metrics. Also regarding my last comment, should I do it here or in a different JIRA I am thinking about adding top k for contenting row. We need to know more about contention. Adding number of contentions in the writetimout will help a lot because it will tell us whether the failure is due to contention. was (Author: kohlisankalp): [~jbellis] You mean I move the metrics in PaxosState to CF Metrics? This make sense to move these to individual CFs metrics. The metrics in StorageProxy is on lines of other ClientRequestMetrics we have there. I am not sure whether these belong to CF Metrics. Emit metrics related to CAS/Paxos - Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor Attachments: CASClientRequestMetrics.java, trunk-7341.diff We can emit metrics based on Paxos. One of them is when there is contention. I will add more metric in this JIRA if it is helpful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7420) BATCH with multiple CAS operations should return add information which DML failed
Robert Stupp created CASSANDRA-7420:
---
Summary: BATCH with multiple CAS operations should return add
information which DML failed
Key: CASSANDRA-7420
URL: https://issues.apache.org/jira/browse/CASSANDRA-7420
Project: Cassandra
Issue Type: Improvement
Reporter: Robert Stupp
A {{BATCH}} like this
{noformat}
BEGIN BATCH
INSERT INTO foo (id, num) VALUES (42, 11);
INSERT INTO bar (id, num) VALUES (42, 11);
APPLY BATCH;
{noformat}
Should not only return {{[applied]=false, id=42, num=11}} but also for example
the index of the failed statement in the batch. This allows better error
handling on the client.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6487) Log WARN on large batch sizes
[
https://issues.apache.org/jira/browse/CASSANDRA-6487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038082#comment-14038082
]
Jon Travis commented on CASSANDRA-6487:
---
Does this make sense to log even in the case where the batch is Type.UNLOGGED?
When writing as fast as I can, it sounds like a BatchStatement with a single
execution is the fastest thing to do. However, I'm now getting these warnings.
My options are to jack up the batch size threshold, or stop using batch
statements..
Log WARN on large batch sizes
-
Key: CASSANDRA-6487
URL: https://issues.apache.org/jira/browse/CASSANDRA-6487
Project: Cassandra
Issue Type: Improvement
Reporter: Patrick McFadin
Assignee: Lyuben Todorov
Priority: Minor
Fix For: 2.0.8
Attachments: 6487-cassandra-2.0.patch, 6487-cassandra-2.0_v2.patch
Large batches on a coordinator can cause a lot of node stress. I propose
adding a WARN log entry if batch sizes go beyond a configurable size. This
will give more visibility to operators on something that can happen on the
developer side.
New yaml setting with 5k default.
{{# Log WARN on any batch size exceeding this value. 5k by default.}}
{{# Caution should be taken on increasing the size of this threshold as it
can lead to node instability.}}
{{batch_size_warn_threshold: 5k}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7275) Errors in FlushRunnable may leave threads hung
[
https://issues.apache.org/jira/browse/CASSANDRA-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-7275:
---
Assignee: Yuki Morishita (was: Mikhail Stepura)
Errors in FlushRunnable may leave threads hung
--
Key: CASSANDRA-7275
URL: https://issues.apache.org/jira/browse/CASSANDRA-7275
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Yuki Morishita
Priority: Minor
Fix For: 1.2.17, 2.0.9
Attachments: 0001-Move-latch.countDown-into-finally-block.patch,
7252-2.0-v2.txt
In Memtable.FlushRunnable, the CountDownLatch will never be counted down if
there are errors, which results in hanging any threads that are waiting for
the flush to complete. For example, an error like this causes the problem:
{noformat}
ERROR [FlushWriter:474] 2014-05-20 12:10:31,137 CassandraDaemon.java (line
198) Exception in thread Thread[FlushWriter:474,5,main]
java.lang.IllegalArgumentException
at java.nio.Buffer.position(Unknown Source)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:64)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:72)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.split(AbstractCompositeType.java:138)
at
org.apache.cassandra.io.sstable.ColumnNameHelper.minComponents(ColumnNameHelper.java:103)
at
org.apache.cassandra.db.ColumnFamily.getColumnStats(ColumnFamily.java:439)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:194)
at
org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:397)
at
org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:350)
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7311) Enable incremental backup on a per-keyspace level
[ https://issues.apache.org/jira/browse/CASSANDRA-7311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038197#comment-14038197 ] Dave Brosius commented on CASSANDRA-7311: - I think that if the incremental_backup option isn't specified at the time the keyspace is created, no value should be written of it into the definition, so that you get the flexibility of the setting (later) from the yaml. Enable incremental backup on a per-keyspace level - Key: CASSANDRA-7311 URL: https://issues.apache.org/jira/browse/CASSANDRA-7311 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: lhf Attachments: CASSANDRA-7311-formated.patch, cassandra.patch, cassandra_incremental.patch, cassandra_incremental_latest.patch Currently incremental backups are globally defined, however this is not always appropriate or required for all keyspaces in a cluster. As this is quite expensive, it would be preferred to either specify the keyspaces that need this (or exclude the ones that don't). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7311) Enable incremental backup on a per-keyspace level
[ https://issues.apache.org/jira/browse/CASSANDRA-7311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038197#comment-14038197 ] Dave Brosius edited comment on CASSANDRA-7311 at 6/20/14 1:04 AM: -- I think that if the incremental_backup option isn't specified at the time the keyspace is created, no value should be written into the definition, so that you get the flexibility of the setting (later) from the yaml. was (Author: dbrosius): I think that if the incremental_backup option isn't specified at the time the keyspace is created, no value should be written of it into the definition, so that you get the flexibility of the setting (later) from the yaml. Enable incremental backup on a per-keyspace level - Key: CASSANDRA-7311 URL: https://issues.apache.org/jira/browse/CASSANDRA-7311 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: lhf Attachments: CASSANDRA-7311-formated.patch, cassandra.patch, cassandra_incremental.patch, cassandra_incremental_latest.patch Currently incremental backups are globally defined, however this is not always appropriate or required for all keyspaces in a cluster. As this is quite expensive, it would be preferred to either specify the keyspaces that need this (or exclude the ones that don't). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6487) Log WARN on large batch sizes
[
https://issues.apache.org/jira/browse/CASSANDRA-6487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038245#comment-14038245
]
Jonathan Ellis commented on CASSANDRA-6487:
---
There's essentially no performance gain from batching across multiple
partitions.
Log WARN on large batch sizes
-
Key: CASSANDRA-6487
URL: https://issues.apache.org/jira/browse/CASSANDRA-6487
Project: Cassandra
Issue Type: Improvement
Reporter: Patrick McFadin
Assignee: Lyuben Todorov
Priority: Minor
Fix For: 2.0.8
Attachments: 6487-cassandra-2.0.patch, 6487-cassandra-2.0_v2.patch
Large batches on a coordinator can cause a lot of node stress. I propose
adding a WARN log entry if batch sizes go beyond a configurable size. This
will give more visibility to operators on something that can happen on the
developer side.
New yaml setting with 5k default.
{{# Log WARN on any batch size exceeding this value. 5k by default.}}
{{# Caution should be taken on increasing the size of this threshold as it
can lead to node instability.}}
{{batch_size_warn_threshold: 5k}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6702) Upgrading node uses the wrong port in gossiping
[ https://issues.apache.org/jira/browse/CASSANDRA-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038266#comment-14038266 ] Minh Do commented on CASSANDRA-6702: If I recalled correctly, this happened on C* 1.2 nodes while the cluster was still in a mixed mode and the target nodes were seed nodes (C* 1.1.x). After a while, gossips seemed to settle down correctly on the right IPs and Ports. However, this took some significant time depending on the size of the cluster. Upgrading node uses the wrong port in gossiping --- Key: CASSANDRA-6702 URL: https://issues.apache.org/jira/browse/CASSANDRA-6702 Project: Cassandra Issue Type: Bug Components: Core Environment: 1.1.7, AWS, Ec2MultiRegionSnitch Reporter: Minh Do Priority: Minor Fix For: 1.2.17 When upgrading a node in 1.1.7 (or 1.1.11) cluster to 1.2.15 and inspecting the gossip information on port/Ip, I could see that the upgrading node (1.2 version) communicates to one other node in the same region using Public IP and non-encrypted port. For the rest, the upgrading node uses the correct ports and IPs to communicate in this manner: Same region: private IP and non-encrypted port and Different region: public IP and encrypted port Because there is one node like this (or 2 out of 12 nodes cluster in which nodes are split equally on 2 AWS regions), we have to modify Security Group to allow the new traffics. Without modifying the SG, the 95th and 99th latencies for both reads and writes in the cluster are very bad (due to RPC timeout). Inspecting closer, that upgraded node (1.2 node) is contributing to all of the high latencies whenever it acts as a coordinator node. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7414) After cleanup we can end up with non-compacting high level sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-7414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038274#comment-14038274 ] sankalp kohli commented on CASSANDRA-7414: -- This time based feature can be used for CASSANDRA-6621. After cleanup we can end up with non-compacting high level sstables --- Key: CASSANDRA-7414 URL: https://issues.apache.org/jira/browse/CASSANDRA-7414 Project: Cassandra Issue Type: Bug Reporter: Marcus Eriksson Assignee: Marcus Eriksson Priority: Minor Attachments: 0001-Include-high-level-sstables-in-lower-level-compactio.patch If we run cleanup (or increase sstable size) on a node with LCS, we could end up with a bunch of sstables in higher levels that are never compacted. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7311) Enable incremental backup on a per-keyspace level
[ https://issues.apache.org/jira/browse/CASSANDRA-7311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038304#comment-14038304 ] pankaj mishra commented on CASSANDRA-7311: -- Please kindly tell me why would anyone want to set incremental backup from yaml if he can set it via keyspace by altering keyspace definition. Moreover, please tell me why we should keep both incremental backup option from yaml and keyspace def option while we can achieve all flexibility from def option only. Or is there could be a requirement that on one machine of cluster one would want incremental backup on and for the rest of the machine off. Only then yaml will be helpful. Enable incremental backup on a per-keyspace level - Key: CASSANDRA-7311 URL: https://issues.apache.org/jira/browse/CASSANDRA-7311 Project: Cassandra Issue Type: Improvement Reporter: Johnny Miller Priority: Minor Labels: lhf Attachments: CASSANDRA-7311-formated.patch, cassandra.patch, cassandra_incremental.patch, cassandra_incremental_latest.patch Currently incremental backups are globally defined, however this is not always appropriate or required for all keyspaces in a cluster. As this is quite expensive, it would be preferred to either specify the keyspaces that need this (or exclude the ones that don't). -- This message was sent by Atlassian JIRA (v6.2#6252)
[05/10] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/37736ab1 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/37736ab1 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/37736ab1 Branch: refs/heads/cassandra-2.1 Commit: 37736ab1b11daf191c74889287c1776598e3cea3 Parents: f0ebdeb ba103eb Author: Mikhail Stepura mish...@apache.org Authored: Fri Jun 20 14:03:56 2014 +1100 Committer: Mikhail Stepura mish...@apache.org Committed: Fri Jun 20 14:03:56 2014 +1100 -- CHANGES.txt | 1 + pylib/cqlshlib/formatting.py | 1 + 2 files changed, 2 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/37736ab1/CHANGES.txt -- diff --cc CHANGES.txt index f4f5d83,49afb06..9bc051f --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,25 -1,5 +1,26 @@@ -1.2.17 +2.0.9 + * Fix assertion error in CL.ANY timeout handling (CASSANDRA-7364) + * Handle empty CFs in Memtable#maybeUpdateLiveRatio() (CASSANDRA-7401) + * Fix native protocol CAS batches (CASSANDRA-7337) + * Add per-CF range read request latency metrics (CASSANDRA-7338) + * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323) + * Add conditional CREATE/DROP USER support (CASSANDRA-7264) + * Swap local and global default read repair chances (CASSANDRA-7320) + * Add missing iso8601 patterns for date strings (CASSANDRA-6973) + * Support selecting multiple rows in a partition using IN (CASSANDRA-6875) + * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274) + * Copy compaction options to make sure they are reloaded (CASSANDRA-7290) + * Add option to do more aggressive tombstone compactions (CASSANDRA-6563) + * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288) + * Add authentication support to shuffle (CASSANDRA-6484) + * Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325) + * Make StreamSession#closeSession() idempotent (CASSANDRA-7262) + * Fix infinite loop on exception while streaming (CASSANDRA-7330) + * Reference sstables before populating key cache (CASSANDRA-7234) + * Account for range tombstones in min/max column names (CASSANDRA-7235) + * Improve sub range repair validation (CASSANDRA-7317) +Merged from 1.2: + * cqlsh: 'ascii' values weren't formatted as text (CASSANDRA-7407) * cqlsh: ignore .cassandra permission errors (CASSANDRA-7266) * Errors in FlushRunnable may leave threads hung (CASSANDRA-7275) * reduce failure detector initial value to 2s (CASSANDRA-7307) http://git-wip-us.apache.org/repos/asf/cassandra/blob/37736ab1/pylib/cqlshlib/formatting.py --
