[jira] [Commented] (CASSANDRA-12802) RecoveryManagerTruncateTest fails in 2.1

[Stefania (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15607516#comment-15607516
 ] 

Stefania commented on CASSANDRA-12802:
--

No. In 2.2+ we already have CASSANDRA-11743. As for the deadlock, it cannot be 
reproduced in later versions and I believe this is because of CASSANDRA-6809, 
which fixed the logic in commit log segments, and CASSANDRA-8308 which changed 
the way the CL is restarted during tests. So we don't need the test hack in 
later versions.

> RecoveryManagerTruncateTest fails in 2.1
> 
>
> Key: CASSANDRA-12802
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12802
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Testing
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.17
>
>
> Example failure:
> http://cassci.datastax.com/view/cassandra-2.1/job/cassandra-2.1_testall/388/testReport/junit/org.apache.cassandra.db/RecoveryManagerTruncateTest/testTruncatePointInTime/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12802) RecoveryManagerTruncateTest fails in 2.1

[Nate McCall (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15607431#comment-15607431
 ] 

Nate McCall edited comment on CASSANDRA-12802 at 10/26/16 5:00 AM:
---

Fair enough. I appreciate ya'll being thorough on it regardless. Thanks!

EDIT: [~Stefania] Do we have other fixes versions past 2.1.17 to which we need 
to apply this one then?


was (Author: zznate):
Fair enough. I appreciate ya'll being thorough on it regardless. Thanks!

> RecoveryManagerTruncateTest fails in 2.1
> 
>
> Key: CASSANDRA-12802
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12802
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Testing
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.17
>
>
> Example failure:
> http://cassci.datastax.com/view/cassandra-2.1/job/cassandra-2.1_testall/388/testReport/junit/org.apache.cassandra.db/RecoveryManagerTruncateTest/testTruncatePointInTime/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12802) RecoveryManagerTruncateTest fails in 2.1

[Nate McCall (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15607431#comment-15607431
 ] 

Nate McCall commented on CASSANDRA-12802:
-

Fair enough. I appreciate ya'll being thorough on it regardless. Thanks!

> RecoveryManagerTruncateTest fails in 2.1
> 
>
> Key: CASSANDRA-12802
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12802
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Testing
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.17
>
>
> Example failure:
> http://cassci.datastax.com/view/cassandra-2.1/job/cassandra-2.1_testall/388/testReport/junit/org.apache.cassandra.db/RecoveryManagerTruncateTest/testTruncatePointInTime/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12837) Add multi-threaded support to nodetool rebuild_index

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15607334#comment-15607334
 ] 

Jeff Jirsa edited comment on CASSANDRA-12837 at 10/26/16 4:17 AM:
--

This is not a review, but a few notes:

- 2.2.x isn't getting new features, and a feature that adds thread pool 
executors probably belongs in 3.X at the newest (3.10, not 2.1/2.2/3.0). 

- We have other ways of doing parallel compaction that's used by 
cleanup/scrub/upgradesstables - 
https://github.com/apache/cassandra/blob/f2a354763877cfeaf1dd017b84a7c8ee9eafd885/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L287
 - would it be reasonable to try to utilize something closer to that, rather 
than adding new thread executor pools?

-  Why does this rely on Murmur3 partitioner? Why wouldn't it be possible with 
{{RandomPartitioner}} ? Or any of the others? 

-  This may be less important with CASSANDRA-11218 



was (Author: jjirsa):
This is not a review, but a few notes:

- 2.2.x isn't getting new features, and a feature that adds thread pool 
executors probably belongs in 3.X at the newest (3.10, not 2.1/2.2/3.0). 

- We have other ways of doing parallel compaction that's used by 
cleanup/scrub/upgradesstables - 
https://github.com/apache/cassandra/blob/f2a354763877cfeaf1dd017b84a7c8ee9eafd885/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L287
 - would it be reasonable to try to utilize that, rather than building your 
multi-threading and adding new executor pools?

-  Why does this rely on Murmur3 partitioner? Why wouldn't it be possible with 
{{RandomPartitioner}} ? Or any of the others? 

-  This may be less important with CASSANDRA-11218 


> Add multi-threaded support to nodetool rebuild_index
> 
>
> Key: CASSANDRA-12837
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12837
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: vincent royer
>Priority: Minor
>  Labels: patch
> Fix For: 2.2.9
>
> Attachments: CASSANDRA-12837-2.2.9.txt
>
>
> Add multi-thread nodetool rebuild_index to improve performances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12837) Add multi-threaded support to nodetool rebuild_index

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15607334#comment-15607334
 ] 

Jeff Jirsa commented on CASSANDRA-12837:


This is not a review, but a few notes:

- 2.2.x isn't getting new features, and a feature that adds thread pool 
executors probably belongs in 3.X at the newest (3.10, not 2.1/2.2/3.0). 

- We have other ways of doing parallel compaction that's used by 
cleanup/scrub/upgradesstables - 
https://github.com/apache/cassandra/blob/f2a354763877cfeaf1dd017b84a7c8ee9eafd885/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L287
 - would it be reasonable to try to utilize that, rather than building your 
multi-threading and adding new executor pools?

-  Why does this rely on Murmur3 partitioner? Why wouldn't it be possible with 
{{RandomPartitioner}} ? Or any of the others? 

-  This may be less important with CASSANDRA-11218 


> Add multi-threaded support to nodetool rebuild_index
> 
>
> Key: CASSANDRA-12837
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12837
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: vincent royer
>Priority: Minor
>  Labels: patch
> Fix For: 2.2.9
>
> Attachments: CASSANDRA-12837-2.2.9.txt
>
>
> Add multi-thread nodetool rebuild_index to improve performances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (CASSANDRA-12836) Set JOINING mode before executing the pre-join index callback

[Caleb Rackliffe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Caleb Rackliffe updated CASSANDRA-12836:

Comment: was deleted

(was: [~sbtourist] Assuming that {{StorageService#operationMode}} hits 
{{NORMAL}} in {{setTokens()}}, can't the async callback implementation just 
verify that it's not still {{STARTING}}? (i.e. {{executePreJoinTasks()}} must 
return before {{setTokens()}} is called.))

> Set JOINING mode before executing the pre-join index callback
> -
>
> Key: CASSANDRA-12836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12836
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sergio Bossa
>Assignee: Sergio Bossa
>
> The pre-join index callback introduced by CASSANDRA-12039 might perform long 
> running tasks, and given it's blocking, it would be good to set the node in 
> JOINING mode, which currently only happens in case of bootstrap, so that:
> 1) The mode can be properly read by tools.
> 2) Async callback implementation can read the mode themselves to verify at 
> which point of the startup process they are executing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12836) Set JOINING mode before executing the pre-join index callback

[Caleb Rackliffe (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606539#comment-15606539
 ] 

Caleb Rackliffe edited comment on CASSANDRA-12836 at 10/26/16 2:15 AM:
---

[~sbtourist] Assuming that {{StorageService#operationMode}} hits {{NORMAL}} in 
{{setTokens()}}, can't the async callback implementation just verify that it's 
not still {{STARTING}}? (i.e. {{executePreJoinTasks()}} must return before 
{{setTokens()}} is called.)


was (Author: maedhroz):
[~sbtourist] Assuming that {{StorageService#operationMode}} hits {{NORMAL}} in 
{{setTokens()}}, can't the async callback implementation just verify that it's 
still {{STARTING}}? (i.e. {{executePreJoinTasks()}} must return before 
{{setTokens()}} is called.)

> Set JOINING mode before executing the pre-join index callback
> -
>
> Key: CASSANDRA-12836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12836
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sergio Bossa
>Assignee: Sergio Bossa
>
> The pre-join index callback introduced by CASSANDRA-12039 might perform long 
> running tasks, and given it's blocking, it would be good to set the node in 
> JOINING mode, which currently only happens in case of bootstrap, so that:
> 1) The mode can be properly read by tools.
> 2) Async callback implementation can read the mode themselves to verify at 
> which point of the startup process they are executing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12835) Tracing payload not passed from QueryMessage to tracing session

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606975#comment-15606975
 ] 

Jeff Jirsa commented on CASSANDRA-12835:


{quote}I've found no suitable way to unit test this.{quote}

dtest without prepared statements similar to what you did for CASSANDRA-10392 ? 


> Tracing payload not passed from QueryMessage to tracing session
> ---
>
> Key: CASSANDRA-12835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12835
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: mck
>Priority: Critical
>  Labels: tracing
>
> Caused by CASSANDRA-10392.
> Related to CASSANDRA-11706.
> When querying using CQL statements (not prepared) the message type is 
> QueryMessage and the code in 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/messages/QueryMessage.java#L101
>  is as follows:
> {code:java}
> if (state.traceNextQuery())
> {
> state.createTracingSession();
> ImmutableMap.Builder builder = 
> ImmutableMap.builder();
> {code}
> {{state.createTracingSession();}} should probably be 
> {{state.createTracingSession(getCustomPayload());}}. At least that fixes the 
> problem for me.
> This also raises the question whether some other parts of the code should 
> pass the custom payload as well (I'm not the right person to analyze this):
> {code}
> $ ag createTracingSession
> src/java/org/apache/cassandra/service/QueryState.java
> 80:public void createTracingSession()
> 82:createTracingSession(Collections.EMPTY_MAP);
> 85:public void createTracingSession(Map customPayload)
> src/java/org/apache/cassandra/thrift/CassandraServer.java
> 2528:state().getQueryState().createTracingSession();
> src/java/org/apache/cassandra/transport/messages/BatchMessage.java
> 163:state.createTracingSession();
> src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
> 114:state.createTracingSession(getCustomPayload());
> src/java/org/apache/cassandra/transport/messages/QueryMessage.java
> 101:state.createTracingSession();
> src/java/org/apache/cassandra/transport/messages/PrepareMessage.java
> 74:state.createTracingSession();
> {code}
> This is not marked as `minor` as the CASSANDRA-11706 was because this cannot 
> be fixed by the tracing plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12802) RecoveryManagerTruncateTest fails in 2.1

[Stefania (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefania updated CASSANDRA-12802:
-
Component/s: Testing
 Local Write-Read Paths

> RecoveryManagerTruncateTest fails in 2.1
> 
>
> Key: CASSANDRA-12802
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12802
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Testing
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.17
>
>
> Example failure:
> http://cassci.datastax.com/view/cassandra-2.1/job/cassandra-2.1_testall/388/testReport/junit/org.apache.cassandra.db/RecoveryManagerTruncateTest/testTruncatePointInTime/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12802) RecoveryManagerTruncateTest fails in 2.1

[Stefania (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefania updated CASSANDRA-12802:
-
   Resolution: Fixed
 Reviewer: Branimir Lambov
Fix Version/s: (was: 2.1.x)
   2.1.17
   Status: Resolved  (was: Patch Available)

> RecoveryManagerTruncateTest fails in 2.1
> 
>
> Key: CASSANDRA-12802
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12802
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.17
>
>
> Example failure:
> http://cassci.datastax.com/view/cassandra-2.1/job/cassandra-2.1_testall/388/testReport/junit/org.apache.cassandra.db/RecoveryManagerTruncateTest/testTruncatePointInTime/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12802) RecoveryManagerTruncateTest fails in 2.1

[Stefania (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606967#comment-15606967
 ] 

Stefania commented on CASSANDRA-12802:
--

Thank you for the review and for the feedback. Committed to 2.1 as 
079029a44290f78121e3577da60cec93a8ca9f10 and merged upwards with {{-s ours}}.

> RecoveryManagerTruncateTest fails in 2.1
> 
>
> Key: CASSANDRA-12802
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12802
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x
>
>
> Example failure:
> http://cassci.datastax.com/view/cassandra-2.1/job/cassandra-2.1_testall/388/testReport/junit/org.apache.cassandra.db/RecoveryManagerTruncateTest/testTruncatePointInTime/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[04/15] cassandra git commit: Fix RecoveryManagerTruncateTest, includes a backport of CASSANDRA-11743

[stefania]

Fix RecoveryManagerTruncateTest, includes a backport of CASSANDRA-11743

patch by Stefania Alborghetti and Benjamin Lerer; reviewed by Branimir Lambov 
for CASSANDRA-12802


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/079029a4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/079029a4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/079029a4

Branch: refs/heads/cassandra-3.0
Commit: 079029a44290f78121e3577da60cec93a8ca9f10
Parents: f7ded1c
Author: Stefania Alborghetti 
Authored: Fri May 27 10:55:23 2016 +0200
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:48:11 2016 +0800

--
 CHANGES.txt |  1 +
 .../apache/cassandra/db/commitlog/CommitLog.java| 15 +--
 .../cassandra/db/commitlog/CommitLogSegment.java| 16 +++-
 3 files changed, 29 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e922635..792d6f8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.17
+ * Fix RecoveryManagerTruncateTest (CASSANDRA-12802)
  * Don't skip sstables based on maxLocalDeletionTime (CASSANDRA-12765)
 
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
index 502e704..2484e9b 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
@@ -35,6 +35,7 @@ import org.apache.cassandra.config.Config;
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.db.*;
 import org.apache.cassandra.io.FSWriteError;
+import org.apache.cassandra.io.sstable.SSTableDeletingTask;
 import org.apache.cassandra.io.util.DataOutputByteBuffer;
 import org.apache.cassandra.metrics.CommitLogMetrics;
 import org.apache.cassandra.net.MessagingService;
@@ -101,7 +102,7 @@ public class CommitLog implements CommitLogMBean
 // we used to try to avoid instantiating commitlog (thus 
creating an empty segment ready for writes)
 // until after recover was finished.  this turns out to be 
fragile; it is less error-prone to go
 // ahead and allow writes before recover(), and just skip 
active segments when we do.
-return CommitLogDescriptor.isValid(name) && 
!instance.allocator.manages(name);
+return CommitLogDescriptor.isValid(name) && 
CommitLogSegment.shouldReplay(name);
 }
 };
 
@@ -367,11 +368,21 @@ public class CommitLog implements CommitLogMBean
 
 /**
  * FOR TESTING PURPOSES. See CommitLogAllocator.
+ *
+ * There is a race at the moment, even if this method
+ * is synchronized we can still create an allocation
+ * on a segment that will be closed in this method,
+ * therefore causing {@link Allocation#awaitDiskSync()} to hang
+ * forever. This typically happens because of the mutations created
+ * by {@link org.apache.cassandra.io.sstable.SSTableReader.GlobalTidy},
+ * that's why we wait for all deletions to complete firtst.
  */
-public void resetUnsafe()
+public synchronized void resetUnsafe()
 {
+SSTableDeletingTask.waitForDeletions();
 sync(true);
 allocator.resetUnsafe();
+CommitLogSegment.resetReplayLimit();
 }
 
 /**

http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
index 2ea8701..1093f87 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
@@ -61,6 +61,7 @@ public class CommitLogSegment
 
 private final static long idBase;
 private final static AtomicInteger nextId = new AtomicInteger(1);
+private static long replayLimitId;
 static
 {
 long maxId = Long.MIN_VALUE;
@@ -69,7 +70,7 @@ public class CommitLogSegment
 if (CommitLogDescriptor.isValid(file.getName()))
 maxId = 
Math.max(CommitLogDescriptor.fromFileName(file.getName()).id, maxId);
 }
-idBase = 

[01/15] cassandra git commit: Fix RecoveryManagerTruncateTest, includes a backport of CASSANDRA-11743

[stefania]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 f7ded1c59 -> 079029a44
  refs/heads/cassandra-2.2 2122ff88f -> eaf46a1c9
  refs/heads/cassandra-3.0 c0886d877 -> e9ff6ae6f
  refs/heads/cassandra-3.X e2a0d75b0 -> 20b085a13
  refs/heads/trunk 6d40809d8 -> 41681e0b5


Fix RecoveryManagerTruncateTest, includes a backport of CASSANDRA-11743

patch by Stefania Alborghetti and Benjamin Lerer; reviewed by Branimir Lambov 
for CASSANDRA-12802


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/079029a4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/079029a4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/079029a4

Branch: refs/heads/cassandra-2.1
Commit: 079029a44290f78121e3577da60cec93a8ca9f10
Parents: f7ded1c
Author: Stefania Alborghetti 
Authored: Fri May 27 10:55:23 2016 +0200
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:48:11 2016 +0800

--
 CHANGES.txt |  1 +
 .../apache/cassandra/db/commitlog/CommitLog.java| 15 +--
 .../cassandra/db/commitlog/CommitLogSegment.java| 16 +++-
 3 files changed, 29 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e922635..792d6f8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.17
+ * Fix RecoveryManagerTruncateTest (CASSANDRA-12802)
  * Don't skip sstables based on maxLocalDeletionTime (CASSANDRA-12765)
 
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
index 502e704..2484e9b 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
@@ -35,6 +35,7 @@ import org.apache.cassandra.config.Config;
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.db.*;
 import org.apache.cassandra.io.FSWriteError;
+import org.apache.cassandra.io.sstable.SSTableDeletingTask;
 import org.apache.cassandra.io.util.DataOutputByteBuffer;
 import org.apache.cassandra.metrics.CommitLogMetrics;
 import org.apache.cassandra.net.MessagingService;
@@ -101,7 +102,7 @@ public class CommitLog implements CommitLogMBean
 // we used to try to avoid instantiating commitlog (thus 
creating an empty segment ready for writes)
 // until after recover was finished.  this turns out to be 
fragile; it is less error-prone to go
 // ahead and allow writes before recover(), and just skip 
active segments when we do.
-return CommitLogDescriptor.isValid(name) && 
!instance.allocator.manages(name);
+return CommitLogDescriptor.isValid(name) && 
CommitLogSegment.shouldReplay(name);
 }
 };
 
@@ -367,11 +368,21 @@ public class CommitLog implements CommitLogMBean
 
 /**
  * FOR TESTING PURPOSES. See CommitLogAllocator.
+ *
+ * There is a race at the moment, even if this method
+ * is synchronized we can still create an allocation
+ * on a segment that will be closed in this method,
+ * therefore causing {@link Allocation#awaitDiskSync()} to hang
+ * forever. This typically happens because of the mutations created
+ * by {@link org.apache.cassandra.io.sstable.SSTableReader.GlobalTidy},
+ * that's why we wait for all deletions to complete firtst.
  */
-public void resetUnsafe()
+public synchronized void resetUnsafe()
 {
+SSTableDeletingTask.waitForDeletions();
 sync(true);
 allocator.resetUnsafe();
+CommitLogSegment.resetReplayLimit();
 }
 
 /**

http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
index 2ea8701..1093f87 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
@@ -61,6 +61,7 @@ public class CommitLogSegment
 
 private final static long idBase;
 private final static AtomicInteger nextId = new AtomicInteger(1);
+private static long replayLimitId;
 static
 {

[13/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.X

[stefania]

Merge branch 'cassandra-3.0' into cassandra-3.X


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/20b085a1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/20b085a1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/20b085a1

Branch: refs/heads/cassandra-3.X
Commit: 20b085a137315811c03c9f14a6a5b489b6ba9df9
Parents: e2a0d75 e9ff6ae
Author: Stefania Alborghetti 
Authored: Wed Oct 26 08:51:17 2016 +0800
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:51:17 2016 +0800

--

--

[10/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[stefania]

Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e9ff6ae6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e9ff6ae6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e9ff6ae6

Branch: refs/heads/trunk
Commit: e9ff6ae6f549b789eb17e4619678dd95ecef790a
Parents: c0886d8 eaf46a1
Author: Stefania Alborghetti 
Authored: Wed Oct 26 08:50:43 2016 +0800
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:50:43 2016 +0800

--

--

[06/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[stefania]

Merge branch 'cassandra-2.1' into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eaf46a1c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eaf46a1c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eaf46a1c

Branch: refs/heads/trunk
Commit: eaf46a1c941468c514b3beb56318d9e82ead7697
Parents: 2122ff8 079029a
Author: Stefania Alborghetti 
Authored: Wed Oct 26 08:50:26 2016 +0800
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:50:26 2016 +0800

--

--

[02/15] cassandra git commit: Fix RecoveryManagerTruncateTest, includes a backport of CASSANDRA-11743

[stefania]

Fix RecoveryManagerTruncateTest, includes a backport of CASSANDRA-11743

patch by Stefania Alborghetti and Benjamin Lerer; reviewed by Branimir Lambov 
for CASSANDRA-12802


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/079029a4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/079029a4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/079029a4

Branch: refs/heads/cassandra-2.2
Commit: 079029a44290f78121e3577da60cec93a8ca9f10
Parents: f7ded1c
Author: Stefania Alborghetti 
Authored: Fri May 27 10:55:23 2016 +0200
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:48:11 2016 +0800

--
 CHANGES.txt |  1 +
 .../apache/cassandra/db/commitlog/CommitLog.java| 15 +--
 .../cassandra/db/commitlog/CommitLogSegment.java| 16 +++-
 3 files changed, 29 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e922635..792d6f8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.17
+ * Fix RecoveryManagerTruncateTest (CASSANDRA-12802)
  * Don't skip sstables based on maxLocalDeletionTime (CASSANDRA-12765)
 
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
index 502e704..2484e9b 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
@@ -35,6 +35,7 @@ import org.apache.cassandra.config.Config;
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.db.*;
 import org.apache.cassandra.io.FSWriteError;
+import org.apache.cassandra.io.sstable.SSTableDeletingTask;
 import org.apache.cassandra.io.util.DataOutputByteBuffer;
 import org.apache.cassandra.metrics.CommitLogMetrics;
 import org.apache.cassandra.net.MessagingService;
@@ -101,7 +102,7 @@ public class CommitLog implements CommitLogMBean
 // we used to try to avoid instantiating commitlog (thus 
creating an empty segment ready for writes)
 // until after recover was finished.  this turns out to be 
fragile; it is less error-prone to go
 // ahead and allow writes before recover(), and just skip 
active segments when we do.
-return CommitLogDescriptor.isValid(name) && 
!instance.allocator.manages(name);
+return CommitLogDescriptor.isValid(name) && 
CommitLogSegment.shouldReplay(name);
 }
 };
 
@@ -367,11 +368,21 @@ public class CommitLog implements CommitLogMBean
 
 /**
  * FOR TESTING PURPOSES. See CommitLogAllocator.
+ *
+ * There is a race at the moment, even if this method
+ * is synchronized we can still create an allocation
+ * on a segment that will be closed in this method,
+ * therefore causing {@link Allocation#awaitDiskSync()} to hang
+ * forever. This typically happens because of the mutations created
+ * by {@link org.apache.cassandra.io.sstable.SSTableReader.GlobalTidy},
+ * that's why we wait for all deletions to complete firtst.
  */
-public void resetUnsafe()
+public synchronized void resetUnsafe()
 {
+SSTableDeletingTask.waitForDeletions();
 sync(true);
 allocator.resetUnsafe();
+CommitLogSegment.resetReplayLimit();
 }
 
 /**

http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
index 2ea8701..1093f87 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
@@ -61,6 +61,7 @@ public class CommitLogSegment
 
 private final static long idBase;
 private final static AtomicInteger nextId = new AtomicInteger(1);
+private static long replayLimitId;
 static
 {
 long maxId = Long.MIN_VALUE;
@@ -69,7 +70,7 @@ public class CommitLogSegment
 if (CommitLogDescriptor.isValid(file.getName()))
 maxId = 
Math.max(CommitLogDescriptor.fromFileName(file.getName()).id, maxId);
 }
-idBase = 

[15/15] cassandra git commit: Merge branch 'cassandra-3.X' into trunk

[stefania]

Merge branch 'cassandra-3.X' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/41681e0b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/41681e0b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/41681e0b

Branch: refs/heads/trunk
Commit: 41681e0b57fd334ca3c18df75bd4c7227a185411
Parents: 6d40809 20b085a
Author: Stefania Alborghetti 
Authored: Wed Oct 26 08:51:46 2016 +0800
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:51:46 2016 +0800

--

--

[03/15] cassandra git commit: Fix RecoveryManagerTruncateTest, includes a backport of CASSANDRA-11743

[stefania]

Fix RecoveryManagerTruncateTest, includes a backport of CASSANDRA-11743

patch by Stefania Alborghetti and Benjamin Lerer; reviewed by Branimir Lambov 
for CASSANDRA-12802


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/079029a4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/079029a4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/079029a4

Branch: refs/heads/trunk
Commit: 079029a44290f78121e3577da60cec93a8ca9f10
Parents: f7ded1c
Author: Stefania Alborghetti 
Authored: Fri May 27 10:55:23 2016 +0200
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:48:11 2016 +0800

--
 CHANGES.txt |  1 +
 .../apache/cassandra/db/commitlog/CommitLog.java| 15 +--
 .../cassandra/db/commitlog/CommitLogSegment.java| 16 +++-
 3 files changed, 29 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e922635..792d6f8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.17
+ * Fix RecoveryManagerTruncateTest (CASSANDRA-12802)
  * Don't skip sstables based on maxLocalDeletionTime (CASSANDRA-12765)
 
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
index 502e704..2484e9b 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
@@ -35,6 +35,7 @@ import org.apache.cassandra.config.Config;
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.db.*;
 import org.apache.cassandra.io.FSWriteError;
+import org.apache.cassandra.io.sstable.SSTableDeletingTask;
 import org.apache.cassandra.io.util.DataOutputByteBuffer;
 import org.apache.cassandra.metrics.CommitLogMetrics;
 import org.apache.cassandra.net.MessagingService;
@@ -101,7 +102,7 @@ public class CommitLog implements CommitLogMBean
 // we used to try to avoid instantiating commitlog (thus 
creating an empty segment ready for writes)
 // until after recover was finished.  this turns out to be 
fragile; it is less error-prone to go
 // ahead and allow writes before recover(), and just skip 
active segments when we do.
-return CommitLogDescriptor.isValid(name) && 
!instance.allocator.manages(name);
+return CommitLogDescriptor.isValid(name) && 
CommitLogSegment.shouldReplay(name);
 }
 };
 
@@ -367,11 +368,21 @@ public class CommitLog implements CommitLogMBean
 
 /**
  * FOR TESTING PURPOSES. See CommitLogAllocator.
+ *
+ * There is a race at the moment, even if this method
+ * is synchronized we can still create an allocation
+ * on a segment that will be closed in this method,
+ * therefore causing {@link Allocation#awaitDiskSync()} to hang
+ * forever. This typically happens because of the mutations created
+ * by {@link org.apache.cassandra.io.sstable.SSTableReader.GlobalTidy},
+ * that's why we wait for all deletions to complete firtst.
  */
-public void resetUnsafe()
+public synchronized void resetUnsafe()
 {
+SSTableDeletingTask.waitForDeletions();
 sync(true);
 allocator.resetUnsafe();
+CommitLogSegment.resetReplayLimit();
 }
 
 /**

http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
index 2ea8701..1093f87 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
@@ -61,6 +61,7 @@ public class CommitLogSegment
 
 private final static long idBase;
 private final static AtomicInteger nextId = new AtomicInteger(1);
+private static long replayLimitId;
 static
 {
 long maxId = Long.MIN_VALUE;
@@ -69,7 +70,7 @@ public class CommitLogSegment
 if (CommitLogDescriptor.isValid(file.getName()))
 maxId = 
Math.max(CommitLogDescriptor.fromFileName(file.getName()).id, maxId);
 }
-idBase = 

[14/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.X

[stefania]

Merge branch 'cassandra-3.0' into cassandra-3.X


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/20b085a1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/20b085a1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/20b085a1

Branch: refs/heads/trunk
Commit: 20b085a137315811c03c9f14a6a5b489b6ba9df9
Parents: e2a0d75 e9ff6ae
Author: Stefania Alborghetti 
Authored: Wed Oct 26 08:51:17 2016 +0800
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:51:17 2016 +0800

--

--

[11/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[stefania]

Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e9ff6ae6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e9ff6ae6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e9ff6ae6

Branch: refs/heads/cassandra-3.X
Commit: e9ff6ae6f549b789eb17e4619678dd95ecef790a
Parents: c0886d8 eaf46a1
Author: Stefania Alborghetti 
Authored: Wed Oct 26 08:50:43 2016 +0800
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:50:43 2016 +0800

--

--

[12/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[stefania]

Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e9ff6ae6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e9ff6ae6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e9ff6ae6

Branch: refs/heads/cassandra-3.0
Commit: e9ff6ae6f549b789eb17e4619678dd95ecef790a
Parents: c0886d8 eaf46a1
Author: Stefania Alborghetti 
Authored: Wed Oct 26 08:50:43 2016 +0800
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:50:43 2016 +0800

--

--

[07/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[stefania]

Merge branch 'cassandra-2.1' into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eaf46a1c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eaf46a1c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eaf46a1c

Branch: refs/heads/cassandra-2.2
Commit: eaf46a1c941468c514b3beb56318d9e82ead7697
Parents: 2122ff8 079029a
Author: Stefania Alborghetti 
Authored: Wed Oct 26 08:50:26 2016 +0800
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:50:26 2016 +0800

--

--

[09/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[stefania]

Merge branch 'cassandra-2.1' into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eaf46a1c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eaf46a1c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eaf46a1c

Branch: refs/heads/cassandra-3.X
Commit: eaf46a1c941468c514b3beb56318d9e82ead7697
Parents: 2122ff8 079029a
Author: Stefania Alborghetti 
Authored: Wed Oct 26 08:50:26 2016 +0800
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:50:26 2016 +0800

--

--

[08/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[stefania]

Merge branch 'cassandra-2.1' into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eaf46a1c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eaf46a1c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eaf46a1c

Branch: refs/heads/cassandra-3.0
Commit: eaf46a1c941468c514b3beb56318d9e82ead7697
Parents: 2122ff8 079029a
Author: Stefania Alborghetti 
Authored: Wed Oct 26 08:50:26 2016 +0800
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:50:26 2016 +0800

--

--

[05/15] cassandra git commit: Fix RecoveryManagerTruncateTest, includes a backport of CASSANDRA-11743

[stefania]

Fix RecoveryManagerTruncateTest, includes a backport of CASSANDRA-11743

patch by Stefania Alborghetti and Benjamin Lerer; reviewed by Branimir Lambov 
for CASSANDRA-12802


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/079029a4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/079029a4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/079029a4

Branch: refs/heads/cassandra-3.X
Commit: 079029a44290f78121e3577da60cec93a8ca9f10
Parents: f7ded1c
Author: Stefania Alborghetti 
Authored: Fri May 27 10:55:23 2016 +0200
Committer: Stefania Alborghetti 
Committed: Wed Oct 26 08:48:11 2016 +0800

--
 CHANGES.txt |  1 +
 .../apache/cassandra/db/commitlog/CommitLog.java| 15 +--
 .../cassandra/db/commitlog/CommitLogSegment.java| 16 +++-
 3 files changed, 29 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e922635..792d6f8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.17
+ * Fix RecoveryManagerTruncateTest (CASSANDRA-12802)
  * Don't skip sstables based on maxLocalDeletionTime (CASSANDRA-12765)
 
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
index 502e704..2484e9b 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
@@ -35,6 +35,7 @@ import org.apache.cassandra.config.Config;
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.db.*;
 import org.apache.cassandra.io.FSWriteError;
+import org.apache.cassandra.io.sstable.SSTableDeletingTask;
 import org.apache.cassandra.io.util.DataOutputByteBuffer;
 import org.apache.cassandra.metrics.CommitLogMetrics;
 import org.apache.cassandra.net.MessagingService;
@@ -101,7 +102,7 @@ public class CommitLog implements CommitLogMBean
 // we used to try to avoid instantiating commitlog (thus 
creating an empty segment ready for writes)
 // until after recover was finished.  this turns out to be 
fragile; it is less error-prone to go
 // ahead and allow writes before recover(), and just skip 
active segments when we do.
-return CommitLogDescriptor.isValid(name) && 
!instance.allocator.manages(name);
+return CommitLogDescriptor.isValid(name) && 
CommitLogSegment.shouldReplay(name);
 }
 };
 
@@ -367,11 +368,21 @@ public class CommitLog implements CommitLogMBean
 
 /**
  * FOR TESTING PURPOSES. See CommitLogAllocator.
+ *
+ * There is a race at the moment, even if this method
+ * is synchronized we can still create an allocation
+ * on a segment that will be closed in this method,
+ * therefore causing {@link Allocation#awaitDiskSync()} to hang
+ * forever. This typically happens because of the mutations created
+ * by {@link org.apache.cassandra.io.sstable.SSTableReader.GlobalTidy},
+ * that's why we wait for all deletions to complete firtst.
  */
-public void resetUnsafe()
+public synchronized void resetUnsafe()
 {
+SSTableDeletingTask.waitForDeletions();
 sync(true);
 allocator.resetUnsafe();
+CommitLogSegment.resetReplayLimit();
 }
 
 /**

http://git-wip-us.apache.org/repos/asf/cassandra/blob/079029a4/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
index 2ea8701..1093f87 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java
@@ -61,6 +61,7 @@ public class CommitLogSegment
 
 private final static long idBase;
 private final static AtomicInteger nextId = new AtomicInteger(1);
+private static long replayLimitId;
 static
 {
 long maxId = Long.MIN_VALUE;
@@ -69,7 +70,7 @@ public class CommitLogSegment
 if (CommitLogDescriptor.isValid(file.getName()))
 maxId = 
Math.max(CommitLogDescriptor.fromFileName(file.getName()).id, maxId);
 }
-idBase = 

[jira] [Updated] (CASSANDRA-9754) Make index info heap friendly for large CQL partitions

[Jeff Jirsa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-9754:
--
Attachment: 0f8e28c220fd5af6c7b5dd2d3dab6936c4aa4b6b.patch

For tables with many non-indexed rows, this patch 
(0f8e28c220fd5af6c7b5dd2d3dab6936c4aa4b6b.patch) will pack non-indexed row 
entries behind the 4k aligned birch segments rather than aligning to the 
boundary for each (nearly empty) entry. That is - rather than aligning AFTER 
each time we write a new segment/subsegment, we align before we write a new 
birch tree/segment, and for non-aligned segments/subsegments, we skip the align 
entirely to save space. 

I've not tested the performance impact of this patch, but in terms of size on 
disk, it creates an -Index component approximately 98% smaller than the  
birch/9754 patch for an example table where the mean partition size is ~5k .  

Thoughts on this, [~mkjellman] ? 

> Make index info heap friendly for large CQL partitions
> --
>
> Key: CASSANDRA-9754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9754
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: Michael Kjellman
>Priority: Minor
> Fix For: 4.x
>
> Attachments: 0f8e28c220fd5af6c7b5dd2d3dab6936c4aa4b6b.patch, 
> gc_collection_times_with_birch.png, gc_collection_times_without_birch.png, 
> gc_counts_with_birch.png, gc_counts_without_birch.png, 
> perf_cluster_1_with_birch_read_latency_and_counts.png, 
> perf_cluster_1_with_birch_write_latency_and_counts.png, 
> perf_cluster_2_with_birch_read_latency_and_counts.png, 
> perf_cluster_2_with_birch_write_latency_and_counts.png, 
> perf_cluster_3_without_birch_read_latency_and_counts.png, 
> perf_cluster_3_without_birch_write_latency_and_counts.png
>
>
>  Looking at a heap dump of 2.0 cluster, I found that majority of the objects 
> are IndexInfo and its ByteBuffers. This is specially bad in endpoints with 
> large CQL partitions. If a CQL partition is say 6,4GB, it will have 100K 
> IndexInfo objects and 200K ByteBuffers. This will create a lot of churn for 
> GC. Can this be improved by not creating so many objects?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12835) Tracing payload not passed from QueryMessage to tracing session

[mck (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606626#comment-15606626
 ] 

mck edited comment on CASSANDRA-12835 at 10/25/16 11:16 PM:


Patch at 
https://github.com/thelastpickle/cassandra/commit/f98ce3a0141e7254ec555a01b7c9349c121c4567

This covers all the occurrences you mentioned.
To make the api more obvious I've removed the no-parameter method. That is 
passing in the custom payload is the normal coding approach.

I've found no suitable way to unit test this.


was (Author: michaelsembwever):
Patch at 
https://github.com/thelastpickle/cassandra/commit/f98ce3a0141e7254ec555a01b7c9349c121c4567

> Tracing payload not passed from QueryMessage to tracing session
> ---
>
> Key: CASSANDRA-12835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12835
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: mck
>Priority: Critical
>  Labels: tracing
>
> Caused by CASSANDRA-10392.
> Related to CASSANDRA-11706.
> When querying using CQL statements (not prepared) the message type is 
> QueryMessage and the code in 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/messages/QueryMessage.java#L101
>  is as follows:
> {code:java}
> if (state.traceNextQuery())
> {
> state.createTracingSession();
> ImmutableMap.Builder builder = 
> ImmutableMap.builder();
> {code}
> {{state.createTracingSession();}} should probably be 
> {{state.createTracingSession(getCustomPayload());}}. At least that fixes the 
> problem for me.
> This also raises the question whether some other parts of the code should 
> pass the custom payload as well (I'm not the right person to analyze this):
> {code}
> $ ag createTracingSession
> src/java/org/apache/cassandra/service/QueryState.java
> 80:public void createTracingSession()
> 82:createTracingSession(Collections.EMPTY_MAP);
> 85:public void createTracingSession(Map customPayload)
> src/java/org/apache/cassandra/thrift/CassandraServer.java
> 2528:state().getQueryState().createTracingSession();
> src/java/org/apache/cassandra/transport/messages/BatchMessage.java
> 163:state.createTracingSession();
> src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
> 114:state.createTracingSession(getCustomPayload());
> src/java/org/apache/cassandra/transport/messages/QueryMessage.java
> 101:state.createTracingSession();
> src/java/org/apache/cassandra/transport/messages/PrepareMessage.java
> 74:state.createTracingSession();
> {code}
> This is not marked as `minor` as the CASSANDRA-11706 was because this cannot 
> be fixed by the tracing plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12835) Tracing payload not passed from QueryMessage to tracing session

[mck (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606626#comment-15606626
 ] 

mck commented on CASSANDRA-12835:
-

Patch at 
https://github.com/thelastpickle/cassandra/commit/f98ce3a0141e7254ec555a01b7c9349c121c4567

> Tracing payload not passed from QueryMessage to tracing session
> ---
>
> Key: CASSANDRA-12835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12835
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Hannu Kröger
>Assignee: mck
>Priority: Critical
>  Labels: tracing
>
> Caused by CASSANDRA-10392.
> Related to CASSANDRA-11706.
> When querying using CQL statements (not prepared) the message type is 
> QueryMessage and the code in 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/messages/QueryMessage.java#L101
>  is as follows:
> {code:java}
> if (state.traceNextQuery())
> {
> state.createTracingSession();
> ImmutableMap.Builder builder = 
> ImmutableMap.builder();
> {code}
> {{state.createTracingSession();}} should probably be 
> {{state.createTracingSession(getCustomPayload());}}. At least that fixes the 
> problem for me.
> This also raises the question whether some other parts of the code should 
> pass the custom payload as well (I'm not the right person to analyze this):
> {code}
> $ ag createTracingSession
> src/java/org/apache/cassandra/service/QueryState.java
> 80:public void createTracingSession()
> 82:createTracingSession(Collections.EMPTY_MAP);
> 85:public void createTracingSession(Map customPayload)
> src/java/org/apache/cassandra/thrift/CassandraServer.java
> 2528:state().getQueryState().createTracingSession();
> src/java/org/apache/cassandra/transport/messages/BatchMessage.java
> 163:state.createTracingSession();
> src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
> 114:state.createTracingSession(getCustomPayload());
> src/java/org/apache/cassandra/transport/messages/QueryMessage.java
> 101:state.createTracingSession();
> src/java/org/apache/cassandra/transport/messages/PrepareMessage.java
> 74:state.createTracingSession();
> {code}
> This is not marked as `minor` as the CASSANDRA-11706 was because this cannot 
> be fixed by the tracing plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

svn commit: r1766606 - in /cassandra/site: publish/download/index.html src/download.md

[mshuler]

Author: mshuler
Date: Tue Oct 25 21:48:53 2016
New Revision: 1766606

URL: http://svn.apache.org/viewvc?rev=1766606=rev
Log:
Match Cassandra download page more closely to in-tree installation doc

Modified:
cassandra/site/publish/download/index.html
cassandra/site/src/download.md

Modified: cassandra/site/publish/download/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1766606=1766605=1766606=diff
==
--- cassandra/site/publish/download/index.html (original)
+++ cassandra/site/publish/download/index.html Tue Oct 25 21:48:53 2016
@@ -118,71 +118,71 @@ released against the most recent bug fix
 
 Older (unsupported) versions of Cassandra are http://archive.apache.org/dist/cassandra/;>archived here.
 
-Debian™
-
-The Apache Cassandra project also provide official Debian™ packages 
(which are not a product of Debian™). To use those
-packages, you can use:
-
-deb http://www.apache.org/dist/cassandra/debian release 
series main
-deb-src http://www.apache.org/dist/cassandra/debian release series main
-
-
-where release series is the series you want to 
install:
+Installation from Debian 
packages
 
 
   For tick-tock releases, the release series is the 
release number, without dot, and with an appended x, so 
31x,
 32x, …
-  For older pre-tick-tock releases, the release 
series is the major version number, without dot, and with an
-appended x. So currently it can one of 21x, 
22x or 30x.
+  
+For older pre-tick-tock releases, the release 
series is the major version number, without dot, and with an
+appended x. So currently it can one of 21x, 
22x or 30x.
+  
+  Add the Apache repository of Cassandra to 
/etc/apt/sources.list.d/cassandra.sources.list, for example for 
version 3.6:
 
 
-If after running apt-get update, you see an error message like:
-
-GPG error: http://www.apache.org unstable Release: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY 0353B12C
+echo "deb http://www.apache.org/dist/cassandra/debian 36x main" | 
sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
 
 
-you will need to add the public key of the current Cassandra “release 
manager”, here 0353B12C. You can do that with:
+
+  Add the Apache Cassandra repository keys:
+
 
-
-  1gpg --keyserver pgp.mit.edu --recv-keys public key
-2gpg --export 
--armor public key | sudo apt-key add -
-
-
-
+curl https://www.apache.org/dist/cassandra/KEYS | sudo apt-key add -
+
 
-where public key is the key to add 
(0353B12C in the example above). The list of Apache contributors 
public keys is
-available at https://www.apache.org/dist/cassandra/KEYS;>https://www.apache.org/dist/cassandra/KEYS.
+
+  Update the repositories:
+
 
-Once set up, installing is done as usual with:
+sudo apt-get update
+
 
-
-  1sudo apt-get update
-2sudo apt-get 
install cassandra
-
-
-
+
+  If you encounter this error:
+
 
-Some things to be aware of:
+GPG error: http://www.apache.org 36x InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY A278B781FE4B2BDA
+
+Then add the public key A278B781FE4B2BDA as follows:
+
+sudo apt-key adv --keyserver pool.sks-keyservers.net --recv-key 
A278B781FE4B2BDA
+
+and repeat sudo apt-get update. The actual key may be 
different, you get it from the error message itself. For a
+full list of Apache contributors public keys, you can refer to https://www.apache.org/dist/cassandra/KEYS;>https://www.apache.org/dist/cassandra/KEYS.
 
 
-  The configuration files are located in /etc/cassandra.
-  Start-up options (heap size, etc) can be configured in 
/etc/default/cassandra.
+  Install Cassandra:
 
 
-Third party 
distributions (not endorsed by Apache)
+sudo apt-get install cassandra
+
 
-http://www.planetcassandra.org/cassandra/;>DataStax Distribution 
of Apache Cassandra is available in Linux rpm, deb,
-and tar packages, a Windows MSI installer, and a Mac OS X binary.
+
+  You can start Cassandra with sudo service cassandra start 
and stop it with sudo service cassandra stop.
+However, normally the service will start automatically. For this reason be 
sure to stop it if you need to make any
+configuration changes.
+  Verify that Cassandra is running by invoking nodetool 
status from the command line.
+  The default location of configuration files is 
/etc/cassandra.
+  The default location of log and data directories is 
/var/log/cassandra/ and /var/lib/cassandra.
+  Start-up options (heap size, etc) can be configured in 
/etc/default/cassandra.
+
 
 Source
 
 Development is done in the Apache Git repository. To check out a copy:
 
-
-  1git clone 
http://git-wip-us.apache.org/repos/asf/cassandra.git
-
-
-
+git clone http://git-wip-us.apache.org/repos/asf/cassandra.git
+
 
   
 

Modified: cassandra/site/src/download.md
URL: 

[jira] [Commented] (CASSANDRA-12836) Set JOINING mode before executing the pre-join index callback

[Caleb Rackliffe (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606539#comment-15606539
 ] 

Caleb Rackliffe commented on CASSANDRA-12836:
-

[~sbtourist] Assuming that {{StorageService#operationMode}} hits {{NORMAL}} in 
{{setTokens()}}, can't the async callback implementation just verify that it's 
still {{STARTING}}? (i.e. {{executePreJoinTasks()}} must return before 
{{setTokens()}} is called.)

> Set JOINING mode before executing the pre-join index callback
> -
>
> Key: CASSANDRA-12836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12836
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sergio Bossa
>Assignee: Sergio Bossa
>
> The pre-join index callback introduced by CASSANDRA-12039 might perform long 
> running tasks, and given it's blocking, it would be good to set the node in 
> JOINING mode, which currently only happens in case of bootstrap, so that:
> 1) The mode can be properly read by tools.
> 2) Async callback implementation can read the mode themselves to verify at 
> which point of the startup process they are executing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12373) 3.0 breaks CQL compatibility with super columns families

[Alex Petrov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606282#comment-15606282
 ] 

Alex Petrov commented on CASSANDRA-12373:
-

You're right, I've just checked and it is in fact possible to rename it since 
it's not a part of primary key. 
I hope that won't change the implementation a whole lot, we just need to pick 
up the columns during initialisation correctly. I'll run upgrade tests and 
check what could be the best way.

Thanks for catching that.

> 3.0 breaks CQL compatibility with super columns families
> 
>
> Key: CASSANDRA-12373
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12373
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Sylvain Lebresne
>Assignee: Alex Petrov
> Fix For: 3.0.x, 3.x
>
>
> This is a follow-up to CASSANDRA-12335 to fix the CQL side of super column 
> compatibility.
> The details and a proposed solution can be found in the comments of 
> CASSANDRA-12335 but the crux of the issue is that super column famillies show 
> up differently in CQL in 3.0.x/3.x compared to 2.x, hence breaking backward 
> compatibilty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12373) 3.0 breaks CQL compatibility with super columns families

[Aleksey Yeschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606191#comment-15606191
 ] 

Aleksey Yeschenko commented on CASSANDRA-12373:
---

bq. These columns are not persisted together with the rest of schema, they're 
completely virtual and created during CFMetadata construction.

I do believe that in 2.1 we currently allow renaming these columns in CQL 
metadata. For users that have switched from Thrift to CQL for their 
supercolumns and changed from the default names, losing that metadata on 
upgrade might count as a breaking change.

> 3.0 breaks CQL compatibility with super columns families
> 
>
> Key: CASSANDRA-12373
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12373
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Sylvain Lebresne
>Assignee: Alex Petrov
> Fix For: 3.0.x, 3.x
>
>
> This is a follow-up to CASSANDRA-12335 to fix the CQL side of super column 
> compatibility.
> The details and a proposed solution can be found in the comments of 
> CASSANDRA-12335 but the crux of the issue is that super column famillies show 
> up differently in CQL in 3.0.x/3.x compared to 2.x, hence breaking backward 
> compatibilty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12443) Remove alter type support

[Aleksey Yeschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606134#comment-15606134
 ] 

Aleksey Yeschenko commented on CASSANDRA-12443:
---

Shouldn't the same logic apply to {{ALTER TYPE  ALTER  TYPE 
}} statements?

> Remove alter type support
> -
>
> Key: CASSANDRA-12443
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12443
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Carl Yeksigian
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
>
> Currently, we allow altering of types. However, because we no longer store 
> the length for all types anymore, switching from a fixed-width to 
> variable-width type causes issues. commitlog playback breaking startup, 
> queries currently in flight getting back bad results, and special casing 
> required to handle the changes. In addition, this would solve 
> CASSANDRA-10309, as there is no possibility of the types changing while an 
> SSTableReader is open.
> For fixed-length, compatible types, the alter also doesn't add much over a 
> cast, so users could use that in order to retrieve the altered type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12816) Rebuild failing while adding new datacenter

[Jeremiah Jordan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605848#comment-15605848
 ] 

Jeremiah Jordan commented on CASSANDRA-12816:
-

[~jaid] It is expected behavior, you should always switch all non LocalStrategy 
keyspaces to NetworkTopologyStrategy.

> Rebuild failing while adding new datacenter
> ---
>
> Key: CASSANDRA-12816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12816
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jai Bheemsen Rao Dhanwada
>Priority: Critical
>
> Hello All,
> I have single datacenter with 3 C* nodes and we are trying to expand the 
> cluster to another region/DC. I am seeing the below error while doing a 
> "nodetool rebuild -- name_of_existing_data_center" .  
> {code:java}
> [user@machine ~]$ nodetool rebuild DC1
> nodetool: Unable to find sufficient sources for streaming range 
> (-402178150752044282,-396707578307430827] in keyspace system_distributed
> See 'nodetool help' or 'nodetool help '.
> [user@machine ~]$
> {code}
> {code:java}
> user@cqlsh> SELECT * from system_schema.keyspaces where 
> keyspace_name='system_distributed';
>  keyspace_name | durable_writes | replication
> ---++-
>  system_distributed |   True | {'class': 
> 'org.apache.cassandra.locator.SimpleStrategy', 'replication_factor': '3'}
> (1 rows)
> {code}
> To overcome this I have updated system_distributed keyspace to DC1:3 and 
> DC2:3 with NetworkTopologyStrategy
> C* Version - 3.0.8
> Is this a bug that is introduced in 3.0.8 version of cassandra? as I haven't 
> seen this issue with the older versions?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12816) Rebuild failing while adding new datacenter

[Jai Bheemsen Rao Dhanwada (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605806#comment-15605806
 ] 

Jai Bheemsen Rao Dhanwada commented on CASSANDRA-12816:
---

[~jjordan] Agree, the work around is to add 
-Dcassandra.consistent.rangemovement=false, but can you please help me 
understand, is this a bug or expected behavior?
if this is the expected behavior, what is the action needed when expanding the 
cluster to new DC? do I need to always use NetworkTopologyStrategy for all 
non-LocalStrategy keyspaces like (system_distributed, systems_traces)?

> Rebuild failing while adding new datacenter
> ---
>
> Key: CASSANDRA-12816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12816
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jai Bheemsen Rao Dhanwada
>Priority: Critical
>
> Hello All,
> I have single datacenter with 3 C* nodes and we are trying to expand the 
> cluster to another region/DC. I am seeing the below error while doing a 
> "nodetool rebuild -- name_of_existing_data_center" .  
> {code:java}
> [user@machine ~]$ nodetool rebuild DC1
> nodetool: Unable to find sufficient sources for streaming range 
> (-402178150752044282,-396707578307430827] in keyspace system_distributed
> See 'nodetool help' or 'nodetool help '.
> [user@machine ~]$
> {code}
> {code:java}
> user@cqlsh> SELECT * from system_schema.keyspaces where 
> keyspace_name='system_distributed';
>  keyspace_name | durable_writes | replication
> ---++-
>  system_distributed |   True | {'class': 
> 'org.apache.cassandra.locator.SimpleStrategy', 'replication_factor': '3'}
> (1 rows)
> {code}
> To overcome this I have updated system_distributed keyspace to DC1:3 and 
> DC2:3 with NetworkTopologyStrategy
> C* Version - 3.0.8
> Is this a bug that is introduced in 3.0.8 version of cassandra? as I haven't 
> seen this issue with the older versions?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12443) Remove alter type support

[Benjamin Lerer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605779#comment-15605779
 ] 

Benjamin Lerer commented on CASSANDRA-12443:


bq. Also, it seems like we should bump the CQL version on this, but the next 
version for 3.0 is 3.4.1, which is already defined in 3.x, and reusing it would 
cause an inconsistent versioning. Thoughts, Benjamin Lerer? 

I think we should add the change to the {{3.4.3}} version for 3.X and trunk and 
do nothing for the 3.0 branch. [~thobbs] Do you have an other suggestion?

Otherwise, I think that we should also remove the auto completion from 
{{cqlsh}} for the {{ALTER}}. 

> Remove alter type support
> -
>
> Key: CASSANDRA-12443
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12443
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Carl Yeksigian
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
>
> Currently, we allow altering of types. However, because we no longer store 
> the length for all types anymore, switching from a fixed-width to 
> variable-width type causes issues. commitlog playback breaking startup, 
> queries currently in flight getting back bad results, and special casing 
> required to handle the changes. In addition, this would solve 
> CASSANDRA-10309, as there is no possibility of the types changing while an 
> SSTableReader is open.
> For fixed-length, compatible types, the alter also doesn't add much over a 
> cast, so users could use that in order to retrieve the altered type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[1/3] cassandra git commit: Implement the NoReplicationTokenAllocator

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.X b98a40605 -> e2a0d75b0
  refs/heads/trunk 250573302 -> 6d40809d8


Implement the NoReplicationTokenAllocator

Patch by Dikang Gu; reviewed by Branimir Lambov for CASSANDRA-12777


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e2a0d75b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e2a0d75b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e2a0d75b

Branch: refs/heads/cassandra-3.X
Commit: e2a0d75b024463ad481333bdae826928b55ac589
Parents: b98a406
Author: Dikang Gu 
Authored: Thu Oct 13 12:31:39 2016 -0700
Committer: Aleksey Yeschenko 
Committed: Tue Oct 25 16:56:07 2016 +0100

--
 CHANGES.txt |   1 +
 .../cassandra/dht/ByteOrderedPartitioner.java   |   5 +
 .../org/apache/cassandra/dht/IPartitioner.java  |   5 +
 .../apache/cassandra/dht/LocalPartitioner.java  |   5 +
 .../cassandra/dht/Murmur3Partitioner.java   |  36 +++
 .../dht/OrderPreservingPartitioner.java |   5 +
 .../apache/cassandra/dht/RandomPartitioner.java |  37 ++-
 .../NoReplicationTokenAllocator.java| 266 ++
 .../ReplicationAwareTokenAllocator.java | 250 +
 .../dht/tokenallocator/TokenAllocation.java |   2 +-
 .../dht/tokenallocator/TokenAllocator.java  |   2 +-
 .../dht/tokenallocator/TokenAllocatorBase.java  | 279 +++
 .../tokenallocator/TokenAllocatorFactory.java   |  37 +++
 ...tractReplicationAwareTokenAllocatorTest.java | 175 +---
 .../NoReplicationTokenAllocatorTest.java| 249 +
 .../tokenallocator/TokenAllocatorTestBase.java  | 160 +++
 .../apache/cassandra/dht/LengthPartitioner.java |   5 +
 .../cassandra/dht/Murmur3PartitionerTest.java   |  23 ++
 .../cassandra/dht/PartitionerTestCase.java  |  32 +++
 .../cassandra/dht/RandomPartitionerTest.java|  26 ++
 20 files changed, 1177 insertions(+), 423 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2a0d75b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index dea2003..0f16a0e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Optimize the vnode allocation for single replica per DC (CASSANDRA-12777)
  * Use non-token restrictions for bounds when token restrictions are 
overridden (CASSANDRA-12419)
  * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
  * Use different build directories for Eclipse and Ant (CASSANDRA-12466)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2a0d75b/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java
--
diff --git a/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java 
b/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java
index d334604..1271a5a 100644
--- a/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java
+++ b/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java
@@ -158,6 +158,11 @@ public class ByteOrderedPartitioner implements IPartitioner
 return new BytesToken(bytesForBig(midpair.left, sigbytes, 
midpair.right));
 }
 
+public Token split(Token left, Token right, double ratioToLeft)
+{
+throw new UnsupportedOperationException();
+}
+
 /**
  * Convert a byte array containing the most significant of 'sigbytes' bytes
  * representing a big-endian magnitude into a BigInteger.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2a0d75b/src/java/org/apache/cassandra/dht/IPartitioner.java
--
diff --git a/src/java/org/apache/cassandra/dht/IPartitioner.java 
b/src/java/org/apache/cassandra/dht/IPartitioner.java
index eb4aafb..e342bd0 100644
--- a/src/java/org/apache/cassandra/dht/IPartitioner.java
+++ b/src/java/org/apache/cassandra/dht/IPartitioner.java
@@ -45,6 +45,11 @@ public interface IPartitioner
 public Token midpoint(Token left, Token right);
 
 /**
+ * Calculate a Token which take approximate 0 <= ratioToLeft <= 1 
ownership of the given range.
+ */
+public Token split(Token left, Token right, double ratioToLeft);
+
+/**
  * @return A Token smaller than all others in the range that is being 
partitioned.
  * Not legal to assign to a node or key.  (But legal to use in range 
scans.)
  */

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2a0d75b/src/java/org/apache/cassandra/dht/LocalPartitioner.java
--
diff --git a/src/java/org/apache/cassandra/dht/LocalPartitioner.java 

[jira] [Updated] (CASSANDRA-12384) Include info about sstable on "Compacting large row” message

[Aleksey Yeschenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-12384:
--
Fix Version/s: (was: 3.x)
   3.10

> Include info about sstable on "Compacting large row” message
> 
>
> Key: CASSANDRA-12384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12384
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Trivial
> Fix For: 3.0.10, 3.10
>
> Attachments: CASSANDRA-12384_3.0.txt, CASSANDRA-12384_trunk.txt, 
> CASSANDRA_12384_v2.diff
>
>
> On a message like this one, it would be helpful to understand which sstable 
> this large row is going in
> Compacting large row abc/xyz:38956kjhawf (xyz bytes) incrementally



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12777) Optimize the vnode allocation for single replica per DC

[Aleksey Yeschenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605687#comment-15605687
 ] 

Aleksey Yeschenko commented on CASSANDRA-12777:
---

Committed to 3.X as 
[e2a0d75b024463ad481333bdae826928b55ac589|https://github.com/apache/cassandra/commit/e2a0d75b024463ad481333bdae826928b55ac589]
 and merged with trunk, thanks.

> Optimize the vnode allocation for single replica per DC
> ---
>
> Key: CASSANDRA-12777
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12777
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Dikang Gu
>Assignee: Dikang Gu
> Fix For: 3.10
>
>
> The new vnode allocation algorithm introduced in CASSANDRA-7032 is optimized 
> for the situation that there are multiple replicas per DC.
> In our production environment, most cluster only has one replica, in this 
> case, the algorithm does not work perfectly. It always tries to split token 
> ranges by half, so that the ownership of "min" node could go as low as ~60% 
> compared to avg.
> So for single replica case, I'm working on a new algorithm, which is based on 
> Branimir's previous commit, to split token ranges by "some" percentage, 
> instead of always by half. In this way, we can get a very small variation of 
> the ownership among different nodes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[2/3] cassandra git commit: Implement the NoReplicationTokenAllocator

[aleksey]

Implement the NoReplicationTokenAllocator

Patch by Dikang Gu; reviewed by Branimir Lambov for CASSANDRA-12777


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e2a0d75b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e2a0d75b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e2a0d75b

Branch: refs/heads/trunk
Commit: e2a0d75b024463ad481333bdae826928b55ac589
Parents: b98a406
Author: Dikang Gu 
Authored: Thu Oct 13 12:31:39 2016 -0700
Committer: Aleksey Yeschenko 
Committed: Tue Oct 25 16:56:07 2016 +0100

--
 CHANGES.txt |   1 +
 .../cassandra/dht/ByteOrderedPartitioner.java   |   5 +
 .../org/apache/cassandra/dht/IPartitioner.java  |   5 +
 .../apache/cassandra/dht/LocalPartitioner.java  |   5 +
 .../cassandra/dht/Murmur3Partitioner.java   |  36 +++
 .../dht/OrderPreservingPartitioner.java |   5 +
 .../apache/cassandra/dht/RandomPartitioner.java |  37 ++-
 .../NoReplicationTokenAllocator.java| 266 ++
 .../ReplicationAwareTokenAllocator.java | 250 +
 .../dht/tokenallocator/TokenAllocation.java |   2 +-
 .../dht/tokenallocator/TokenAllocator.java  |   2 +-
 .../dht/tokenallocator/TokenAllocatorBase.java  | 279 +++
 .../tokenallocator/TokenAllocatorFactory.java   |  37 +++
 ...tractReplicationAwareTokenAllocatorTest.java | 175 +---
 .../NoReplicationTokenAllocatorTest.java| 249 +
 .../tokenallocator/TokenAllocatorTestBase.java  | 160 +++
 .../apache/cassandra/dht/LengthPartitioner.java |   5 +
 .../cassandra/dht/Murmur3PartitionerTest.java   |  23 ++
 .../cassandra/dht/PartitionerTestCase.java  |  32 +++
 .../cassandra/dht/RandomPartitionerTest.java|  26 ++
 20 files changed, 1177 insertions(+), 423 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2a0d75b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index dea2003..0f16a0e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Optimize the vnode allocation for single replica per DC (CASSANDRA-12777)
  * Use non-token restrictions for bounds when token restrictions are 
overridden (CASSANDRA-12419)
  * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
  * Use different build directories for Eclipse and Ant (CASSANDRA-12466)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2a0d75b/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java
--
diff --git a/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java 
b/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java
index d334604..1271a5a 100644
--- a/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java
+++ b/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java
@@ -158,6 +158,11 @@ public class ByteOrderedPartitioner implements IPartitioner
 return new BytesToken(bytesForBig(midpair.left, sigbytes, 
midpair.right));
 }
 
+public Token split(Token left, Token right, double ratioToLeft)
+{
+throw new UnsupportedOperationException();
+}
+
 /**
  * Convert a byte array containing the most significant of 'sigbytes' bytes
  * representing a big-endian magnitude into a BigInteger.

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2a0d75b/src/java/org/apache/cassandra/dht/IPartitioner.java
--
diff --git a/src/java/org/apache/cassandra/dht/IPartitioner.java 
b/src/java/org/apache/cassandra/dht/IPartitioner.java
index eb4aafb..e342bd0 100644
--- a/src/java/org/apache/cassandra/dht/IPartitioner.java
+++ b/src/java/org/apache/cassandra/dht/IPartitioner.java
@@ -45,6 +45,11 @@ public interface IPartitioner
 public Token midpoint(Token left, Token right);
 
 /**
+ * Calculate a Token which take approximate 0 <= ratioToLeft <= 1 
ownership of the given range.
+ */
+public Token split(Token left, Token right, double ratioToLeft);
+
+/**
  * @return A Token smaller than all others in the range that is being 
partitioned.
  * Not legal to assign to a node or key.  (But legal to use in range 
scans.)
  */

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e2a0d75b/src/java/org/apache/cassandra/dht/LocalPartitioner.java
--
diff --git a/src/java/org/apache/cassandra/dht/LocalPartitioner.java 
b/src/java/org/apache/cassandra/dht/LocalPartitioner.java
index 9922eb0..0a9b7cb 100644
--- 

[3/3] cassandra git commit: Merge branch 'cassandra-3.X' into trunk

[aleksey]

Merge branch 'cassandra-3.X' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6d40809d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6d40809d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6d40809d

Branch: refs/heads/trunk
Commit: 6d40809d809709aefb296230c3ab7c91164640b6
Parents: 2505733 e2a0d75
Author: Aleksey Yeschenko 
Authored: Tue Oct 25 16:57:19 2016 +0100
Committer: Aleksey Yeschenko 
Committed: Tue Oct 25 16:58:41 2016 +0100

--
 CHANGES.txt |   4 +-
 .../cassandra/dht/ByteOrderedPartitioner.java   |   5 +
 .../org/apache/cassandra/dht/IPartitioner.java  |   5 +
 .../apache/cassandra/dht/LocalPartitioner.java  |   5 +
 .../cassandra/dht/Murmur3Partitioner.java   |  36 +++
 .../dht/OrderPreservingPartitioner.java |   5 +
 .../apache/cassandra/dht/RandomPartitioner.java |  37 ++-
 .../NoReplicationTokenAllocator.java| 266 ++
 .../ReplicationAwareTokenAllocator.java | 250 +
 .../dht/tokenallocator/TokenAllocation.java |   2 +-
 .../dht/tokenallocator/TokenAllocator.java  |   2 +-
 .../dht/tokenallocator/TokenAllocatorBase.java  | 279 +++
 .../tokenallocator/TokenAllocatorFactory.java   |  37 +++
 ...tractReplicationAwareTokenAllocatorTest.java | 175 +---
 .../NoReplicationTokenAllocatorTest.java| 249 +
 .../tokenallocator/TokenAllocatorTestBase.java  | 160 +++
 .../apache/cassandra/dht/LengthPartitioner.java |   5 +
 .../cassandra/dht/Murmur3PartitionerTest.java   |  23 ++
 .../cassandra/dht/PartitionerTestCase.java  |  32 +++
 .../cassandra/dht/RandomPartitionerTest.java|  26 ++
 20 files changed, 1178 insertions(+), 425 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d40809d/CHANGES.txt
--
diff --cc CHANGES.txt
index 0c966b8,0f16a0e..fcd57c7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,13 -1,5 +1,13 @@@
 +4.0
 + * Add column definition kind to dropped columns in schema (CASSANDRA-12705)
 + * Add (automate) Nodetool Documentation (CASSANDRA-12672)
 + * Update bundled cqlsh python driver to 3.7.0 (CASSANDRA-12736)
 + * Reject invalid replication settings when creating or altering a keyspace 
(CASSANDRA-12681)
 + * Clean up the SSTableReader#getScanner API wrt removal of RateLimiter 
(CASSANDRA-12422)
- Merged from 3.0:
-  * Include SSTable filename in compacting large row message (CASSANDRA-12384)
++
 +
  3.10
+  * Optimize the vnode allocation for single replica per DC (CASSANDRA-12777)
   * Use non-token restrictions for bounds when token restrictions are 
overridden (CASSANDRA-12419)
   * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
   * Use different build directories for Eclipse and Ant (CASSANDRA-12466)

[jira] [Updated] (CASSANDRA-12777) Optimize the vnode allocation for single replica per DC

[Aleksey Yeschenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-12777:
--
   Resolution: Fixed
Fix Version/s: (was: 3.x)
   3.10
   Status: Resolved  (was: Ready to Commit)

> Optimize the vnode allocation for single replica per DC
> ---
>
> Key: CASSANDRA-12777
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12777
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Dikang Gu
>Assignee: Dikang Gu
> Fix For: 3.10
>
>
> The new vnode allocation algorithm introduced in CASSANDRA-7032 is optimized 
> for the situation that there are multiple replicas per DC.
> In our production environment, most cluster only has one replica, in this 
> case, the algorithm does not work perfectly. It always tries to split token 
> ranges by half, so that the ownership of "min" node could go as low as ~60% 
> compared to avg.
> So for single replica case, I'm working on a new algorithm, which is based on 
> Branimir's previous commit, to split token ranges by "some" percentage, 
> instead of always by half. In this way, we can get a very small variation of 
> the ownership among different nodes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12816) Rebuild failing while adding new datacenter

[Jeremy Hanna (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605631#comment-15605631
 ] 

Jeremy Hanna commented on CASSANDRA-12816:
--

When [~jjordan] says "it will work", it won't fail.  It will work like it did 
before.  That is, in the scenario where you set auto bootstrap to false when 
you add the new datacenter nodes - since SimpleStrategy ignores datacenter 
information, some of the new nodes will take ownership for some of the ranges 
for the SimpleStrategy keyspace data.  So a rebuild from the source datacenter 
won't get the data that the new datacenter nodes own.  So you won't have all of 
the data from the SimpleStrategy keyspaces when everything is done.  You can 
make sure you don't replicate to the new datacenter in your NTS keyspace config 
and do auto bootstrap = true and actually get the data when the new nodes take 
ownership of those ranges.  However, then you're still left with having to 
migrate SimpleStrategy keyspaces to NetworkTopologyStrategy with two 
datacenters anyway because you really don't want SimpleStrategy with more than 
one datacenter.

This is why you always, *always* change to NetworkTopologyStrategy on all 
non-LocalStrategy keyspaces before adding a second datacenter.

> Rebuild failing while adding new datacenter
> ---
>
> Key: CASSANDRA-12816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12816
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jai Bheemsen Rao Dhanwada
>Priority: Critical
>
> Hello All,
> I have single datacenter with 3 C* nodes and we are trying to expand the 
> cluster to another region/DC. I am seeing the below error while doing a 
> "nodetool rebuild -- name_of_existing_data_center" .  
> {code:java}
> [user@machine ~]$ nodetool rebuild DC1
> nodetool: Unable to find sufficient sources for streaming range 
> (-402178150752044282,-396707578307430827] in keyspace system_distributed
> See 'nodetool help' or 'nodetool help '.
> [user@machine ~]$
> {code}
> {code:java}
> user@cqlsh> SELECT * from system_schema.keyspaces where 
> keyspace_name='system_distributed';
>  keyspace_name | durable_writes | replication
> ---++-
>  system_distributed |   True | {'class': 
> 'org.apache.cassandra.locator.SimpleStrategy', 'replication_factor': '3'}
> (1 rows)
> {code}
> To overcome this I have updated system_distributed keyspace to DC1:3 and 
> DC2:3 with NetworkTopologyStrategy
> C* Version - 3.0.8
> Is this a bug that is introduced in 3.0.8 version of cassandra? as I haven't 
> seen this issue with the older versions?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[2/2] cassandra git commit: Merge branch cassandra-3.X into trunk

[blerer]

Merge branch cassandra-3.X into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/25057330
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/25057330
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/25057330

Branch: refs/heads/trunk
Commit: 2505733020759528d1592fd5ee3e3390b7227354
Parents: 4c728d2 b98a406
Author: Benjamin Lerer 
Authored: Tue Oct 25 17:15:49 2016 +0200
Committer: Benjamin Lerer 
Committed: Tue Oct 25 17:16:00 2016 +0200

--
 CHANGES.txt |  1 +
 .../cql3/restrictions/TokenFilter.java  | 21 
 .../SelectOrderedPartitionerTest.java   | 50 
 3 files changed, 63 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/25057330/CHANGES.txt
--
diff --cc CHANGES.txt
index f9e3e34,dea2003..0c966b8
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,13 -1,5 +1,14 @@@
 +4.0
 + * Add column definition kind to dropped columns in schema (CASSANDRA-12705)
 + * Add (automate) Nodetool Documentation (CASSANDRA-12672)
 + * Update bundled cqlsh python driver to 3.7.0 (CASSANDRA-12736)
 + * Reject invalid replication settings when creating or altering a keyspace 
(CASSANDRA-12681)
 + * Clean up the SSTableReader#getScanner API wrt removal of RateLimiter 
(CASSANDRA-12422)
 +Merged from 3.0:
 + * Include SSTable filename in compacting large row message (CASSANDRA-12384)
 +
  3.10
+  * Use non-token restrictions for bounds when token restrictions are 
overridden (CASSANDRA-12419)
   * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
   * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
   * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)

[jira] [Resolved] (CASSANDRA-12816) Rebuild failing while adding new datacenter

[Jeremiah Jordan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremiah Jordan resolved CASSANDRA-12816.
-
Resolution: Not A Problem

> Rebuild failing while adding new datacenter
> ---
>
> Key: CASSANDRA-12816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12816
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jai Bheemsen Rao Dhanwada
>Priority: Critical
>
> Hello All,
> I have single datacenter with 3 C* nodes and we are trying to expand the 
> cluster to another region/DC. I am seeing the below error while doing a 
> "nodetool rebuild -- name_of_existing_data_center" .  
> {code:java}
> [user@machine ~]$ nodetool rebuild DC1
> nodetool: Unable to find sufficient sources for streaming range 
> (-402178150752044282,-396707578307430827] in keyspace system_distributed
> See 'nodetool help' or 'nodetool help '.
> [user@machine ~]$
> {code}
> {code:java}
> user@cqlsh> SELECT * from system_schema.keyspaces where 
> keyspace_name='system_distributed';
>  keyspace_name | durable_writes | replication
> ---++-
>  system_distributed |   True | {'class': 
> 'org.apache.cassandra.locator.SimpleStrategy', 'replication_factor': '3'}
> (1 rows)
> {code}
> To overcome this I have updated system_distributed keyspace to DC1:3 and 
> DC2:3 with NetworkTopologyStrategy
> C* Version - 3.0.8
> Is this a bug that is introduced in 3.0.8 version of cassandra? as I haven't 
> seen this issue with the older versions?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12816) Rebuild failing while adding new datacenter

[Jeremiah Jordan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605596#comment-15605596
 ] 

Jeremiah Jordan commented on CASSANDRA-12816:
-

If you set:
{code}
-Dcassandra.consistent.rangemovement=false
{code}

Then it will work.

> Rebuild failing while adding new datacenter
> ---
>
> Key: CASSANDRA-12816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12816
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jai Bheemsen Rao Dhanwada
>Priority: Critical
>
> Hello All,
> I have single datacenter with 3 C* nodes and we are trying to expand the 
> cluster to another region/DC. I am seeing the below error while doing a 
> "nodetool rebuild -- name_of_existing_data_center" .  
> {code:java}
> [user@machine ~]$ nodetool rebuild DC1
> nodetool: Unable to find sufficient sources for streaming range 
> (-402178150752044282,-396707578307430827] in keyspace system_distributed
> See 'nodetool help' or 'nodetool help '.
> [user@machine ~]$
> {code}
> {code:java}
> user@cqlsh> SELECT * from system_schema.keyspaces where 
> keyspace_name='system_distributed';
>  keyspace_name | durable_writes | replication
> ---++-
>  system_distributed |   True | {'class': 
> 'org.apache.cassandra.locator.SimpleStrategy', 'replication_factor': '3'}
> (1 rows)
> {code}
> To overcome this I have updated system_distributed keyspace to DC1:3 and 
> DC2:3 with NetworkTopologyStrategy
> C* Version - 3.0.8
> Is this a bug that is introduced in 3.0.8 version of cassandra? as I haven't 
> seen this issue with the older versions?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12837) Add multi-threaded support to nodetool rebuild_index

[vincent royer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

vincent royer updated CASSANDRA-12837:
--
   Labels: patch  (was: )
Reproduced In: 2.2.x
   Status: Patch Available  (was: Open)

For cluster using the Murmur3Partitioner, add multi-threaded secondary index 
rebuild (default remains 1 thread) to JMX and nodetool utility. 

> Add multi-threaded support to nodetool rebuild_index
> 
>
> Key: CASSANDRA-12837
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12837
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: vincent royer
>Priority: Minor
>  Labels: patch
> Fix For: 2.2.9
>
>
> Add multi-thread nodetool rebuild_index to improve performances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12837) Add multi-threaded support to nodetool rebuild_index

[vincent royer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

vincent royer updated CASSANDRA-12837:
--
Attachment: CASSANDRA-12837-2.2.9.txt

> Add multi-threaded support to nodetool rebuild_index
> 
>
> Key: CASSANDRA-12837
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12837
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: vincent royer
>Priority: Minor
>  Labels: patch
> Fix For: 2.2.9
>
> Attachments: CASSANDRA-12837-2.2.9.txt
>
>
> Add multi-thread nodetool rebuild_index to improve performances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12149) NullPointerException on SELECT using index with token restrictions fully overriden by other PK restrictions

[Benjamin Lerer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer updated CASSANDRA-12149:
---
   Resolution: Fixed
Fix Version/s: 3.10
   Status: Resolved  (was: Patch Available)

Committed into 3.X at b98a40605a4eeaf9347401b8f9ed9f0fe297c745 and merged into 
trunk

> NullPointerException on SELECT using index with token restrictions fully 
> overriden by other PK restrictions 
> 
>
> Key: CASSANDRA-12149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12149
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Andrey Konstantinov
>Assignee: Alex Petrov
> Fix For: 3.10
>
> Attachments: CASSANDRA-12149.txt
>
>
> If I execute the sequence of queries (see the attached file), Cassandra 
> aborts a connection reporting NPE on server side. SELECT query without token 
> range filter works, but does not work when token range filter is specified. 
> My intent was to issue multiple SELECT queries targeting the same single 
> partition, filtered by a column indexed by SASI, partitioning results by 
> different token ranges.
> Output from cqlsh on SELECT is the following:
> {code}
> cqlsh> SELECT namespace, entity, timestamp, feature1, feature2 FROM 
> mykeyspace.myrecordtable WHERE namespace = 'ns2' AND entity = 'entity2' AND 
> feature1 > 11 AND feature1 < 31  AND token(namespace, entity) <= 
> 9223372036854775807;
> ServerError:  message="java.lang.NullPointerException">
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[1/2] cassandra git commit: Use non-token restrictions for bounds when token restrictions are overridden

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 4c728d2e4 -> 250573302


Use non-token restrictions for bounds when token restrictions are overridden

patch by Alex Petrov; reviewed by Benjamin Lerer for CASSANDRA-12149


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b98a4060
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b98a4060
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b98a4060

Branch: refs/heads/trunk
Commit: b98a40605a4eeaf9347401b8f9ed9f0fe297c745
Parents: 8644aa9
Author: Alex Petrov 
Authored: Tue Oct 25 17:12:06 2016 +0200
Committer: Benjamin Lerer 
Committed: Tue Oct 25 17:12:06 2016 +0200

--
 CHANGES.txt |  1 +
 .../cql3/restrictions/TokenFilter.java  | 21 
 .../SelectOrderedPartitionerTest.java   | 50 
 3 files changed, 63 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b98a4060/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e6477d7..dea2003 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Use non-token restrictions for bounds when token restrictions are 
overridden (CASSANDRA-12419)
  * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
  * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
  * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b98a4060/src/java/org/apache/cassandra/cql3/restrictions/TokenFilter.java
--
diff --git a/src/java/org/apache/cassandra/cql3/restrictions/TokenFilter.java 
b/src/java/org/apache/cassandra/cql3/restrictions/TokenFilter.java
index 2611d19..400706b 100644
--- a/src/java/org/apache/cassandra/cql3/restrictions/TokenFilter.java
+++ b/src/java/org/apache/cassandra/cql3/restrictions/TokenFilter.java
@@ -41,18 +41,21 @@ import static 
org.apache.cassandra.cql3.statements.Bound.START;
 
 /**
  * Restriction decorator used to merge non-token restriction and 
token restriction on partition keys.
+ *
+ * If all partition key columns have non-token restrictions and do not need 
filtering, they take precedence
+ * when calculating bounds, incusiveness etc (see CASSANDRA-12149).
  */
 final class TokenFilter implements PartitionKeyRestrictions
 {
 /**
  * The decorated restriction
  */
-private PartitionKeyRestrictions restrictions;
+private final PartitionKeyRestrictions restrictions;
 
 /**
  * The restriction on the token
  */
-private TokenRestriction tokenRestriction;
+private final TokenRestriction tokenRestriction;
 
 /**
  * Partitioner to manage tokens, extracted from tokenRestriction metadata.
@@ -81,9 +84,9 @@ final class TokenFilter implements PartitionKeyRestrictions
 @Override
 public boolean isOnToken()
 {
-// if all partition key columns have non-token restrictions, we can 
simply use the token range to filter
-// those restrictions and then ignore the token range
-return restrictions.size() < tokenRestriction.size();
+// if all partition key columns have non-token restrictions and do not 
need filtering,
+// we can simply use the token range to filter those restrictions and 
then ignore the token range
+return needFiltering(tokenRestriction.metadata) || restrictions.size() 
< tokenRestriction.size();
 }
 
 public TokenFilter(PartitionKeyRestrictions restrictions, TokenRestriction 
tokenRestriction)
@@ -111,19 +114,19 @@ final class TokenFilter implements 
PartitionKeyRestrictions
 @Override
 public boolean isInclusive(Bound bound)
 {
-return tokenRestriction.isInclusive(bound);
+return isOnToken() ? tokenRestriction.isInclusive(bound) : 
restrictions.isInclusive(bound);
 }
 
 @Override
-public boolean hasBound(Bound b)
+public boolean hasBound(Bound bound)
 {
-return tokenRestriction.hasBound(b);
+return isOnToken() ? tokenRestriction.hasBound(bound) : 
restrictions.hasBound(bound);
 }
 
 @Override
 public List bounds(Bound bound, QueryOptions options) throws 
InvalidRequestException
 {
-return tokenRestriction.bounds(bound, options);
+return isOnToken() ? tokenRestriction.bounds(bound, options) : 
restrictions.bounds(bound, options);
 }
 
 /**

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b98a4060/test/unit/org/apache/cassandra/cql3/validation/operations/SelectOrderedPartitionerTest.java

cassandra git commit: Use non-token restrictions for bounds when token restrictions are overridden

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.X 8644aa9b8 -> b98a40605


Use non-token restrictions for bounds when token restrictions are overridden

patch by Alex Petrov; reviewed by Benjamin Lerer for CASSANDRA-12149


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b98a4060
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b98a4060
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b98a4060

Branch: refs/heads/cassandra-3.X
Commit: b98a40605a4eeaf9347401b8f9ed9f0fe297c745
Parents: 8644aa9
Author: Alex Petrov 
Authored: Tue Oct 25 17:12:06 2016 +0200
Committer: Benjamin Lerer 
Committed: Tue Oct 25 17:12:06 2016 +0200

--
 CHANGES.txt |  1 +
 .../cql3/restrictions/TokenFilter.java  | 21 
 .../SelectOrderedPartitionerTest.java   | 50 
 3 files changed, 63 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b98a4060/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index e6477d7..dea2003 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Use non-token restrictions for bounds when token restrictions are 
overridden (CASSANDRA-12419)
  * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
  * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
  * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b98a4060/src/java/org/apache/cassandra/cql3/restrictions/TokenFilter.java
--
diff --git a/src/java/org/apache/cassandra/cql3/restrictions/TokenFilter.java 
b/src/java/org/apache/cassandra/cql3/restrictions/TokenFilter.java
index 2611d19..400706b 100644
--- a/src/java/org/apache/cassandra/cql3/restrictions/TokenFilter.java
+++ b/src/java/org/apache/cassandra/cql3/restrictions/TokenFilter.java
@@ -41,18 +41,21 @@ import static 
org.apache.cassandra.cql3.statements.Bound.START;
 
 /**
  * Restriction decorator used to merge non-token restriction and 
token restriction on partition keys.
+ *
+ * If all partition key columns have non-token restrictions and do not need 
filtering, they take precedence
+ * when calculating bounds, incusiveness etc (see CASSANDRA-12149).
  */
 final class TokenFilter implements PartitionKeyRestrictions
 {
 /**
  * The decorated restriction
  */
-private PartitionKeyRestrictions restrictions;
+private final PartitionKeyRestrictions restrictions;
 
 /**
  * The restriction on the token
  */
-private TokenRestriction tokenRestriction;
+private final TokenRestriction tokenRestriction;
 
 /**
  * Partitioner to manage tokens, extracted from tokenRestriction metadata.
@@ -81,9 +84,9 @@ final class TokenFilter implements PartitionKeyRestrictions
 @Override
 public boolean isOnToken()
 {
-// if all partition key columns have non-token restrictions, we can 
simply use the token range to filter
-// those restrictions and then ignore the token range
-return restrictions.size() < tokenRestriction.size();
+// if all partition key columns have non-token restrictions and do not 
need filtering,
+// we can simply use the token range to filter those restrictions and 
then ignore the token range
+return needFiltering(tokenRestriction.metadata) || restrictions.size() 
< tokenRestriction.size();
 }
 
 public TokenFilter(PartitionKeyRestrictions restrictions, TokenRestriction 
tokenRestriction)
@@ -111,19 +114,19 @@ final class TokenFilter implements 
PartitionKeyRestrictions
 @Override
 public boolean isInclusive(Bound bound)
 {
-return tokenRestriction.isInclusive(bound);
+return isOnToken() ? tokenRestriction.isInclusive(bound) : 
restrictions.isInclusive(bound);
 }
 
 @Override
-public boolean hasBound(Bound b)
+public boolean hasBound(Bound bound)
 {
-return tokenRestriction.hasBound(b);
+return isOnToken() ? tokenRestriction.hasBound(bound) : 
restrictions.hasBound(bound);
 }
 
 @Override
 public List bounds(Bound bound, QueryOptions options) throws 
InvalidRequestException
 {
-return tokenRestriction.bounds(bound, options);
+return isOnToken() ? tokenRestriction.bounds(bound, options) : 
restrictions.bounds(bound, options);
 }
 
 /**

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b98a4060/test/unit/org/apache/cassandra/cql3/validation/operations/SelectOrderedPartitionerTest.java

[jira] [Commented] (CASSANDRA-12149) NullPointerException on SELECT using index with token restrictions fully overriden by other PK restrictions

[Benjamin Lerer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605572#comment-15605572
 ] 

Benjamin Lerer commented on CASSANDRA-12149:


Thanks for the new patch.

+1

> NullPointerException on SELECT using index with token restrictions fully 
> overriden by other PK restrictions 
> 
>
> Key: CASSANDRA-12149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12149
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Andrey Konstantinov
>Assignee: Alex Petrov
> Attachments: CASSANDRA-12149.txt
>
>
> If I execute the sequence of queries (see the attached file), Cassandra 
> aborts a connection reporting NPE on server side. SELECT query without token 
> range filter works, but does not work when token range filter is specified. 
> My intent was to issue multiple SELECT queries targeting the same single 
> partition, filtered by a column indexed by SASI, partitioning results by 
> different token ranges.
> Output from cqlsh on SELECT is the following:
> {code}
> cqlsh> SELECT namespace, entity, timestamp, feature1, feature2 FROM 
> mykeyspace.myrecordtable WHERE namespace = 'ns2' AND entity = 'entity2' AND 
> feature1 > 11 AND feature1 < 31  AND token(namespace, entity) <= 
> 9223372036854775807;
> ServerError:  message="java.lang.NullPointerException">
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12836) Set JOINING mode before executing the pre-join index callback

[Sergio Bossa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergio Bossa updated CASSANDRA-12836:
-
Issue Type: Improvement  (was: Bug)

> Set JOINING mode before executing the pre-join index callback
> -
>
> Key: CASSANDRA-12836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12836
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sergio Bossa
>Assignee: Sergio Bossa
>
> The pre-join index callback introduced by CASSANDRA-12039 might perform long 
> running tasks, and given it's blocking, it would be good to set the node in 
> JOINING mode, which currently only happens in case of bootstrap, so that:
> 1) The mode can be properly read by tools.
> 2) Async callback implementation can read the mode themselves to verify at 
> which point of the startup process they are executing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12836) Set JOINING mode before executing the pre-join index callback

[Sergio Bossa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergio Bossa updated CASSANDRA-12836:
-
Status: Patch Available  (was: Open)

> Set JOINING mode before executing the pre-join index callback
> -
>
> Key: CASSANDRA-12836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12836
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sergio Bossa
>Assignee: Sergio Bossa
>
> The pre-join index callback introduced by CASSANDRA-12039 might perform long 
> running tasks, and given it's blocking, it would be good to set the node in 
> JOINING mode, which currently only happens in case of bootstrap, so that:
> 1) The mode can be properly read by tools.
> 2) Async callback implementation can read the mode themselves to verify at 
> which point of the startup process they are executing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12836) Set JOINING mode before executing the pre-join index callback

[Sergio Bossa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605549#comment-15605549
 ] 

Sergio Bossa commented on CASSANDRA-12836:
--

||[Trunk 
patch|https://github.com/apache/cassandra/compare/trunk...sbtourist:CASSANDRA-12836?expand=1]||[DTests
 
patch|https://github.com/riptano/cassandra-dtest/compare/master...sbtourist:CASSANDRA-12836?expand=1]||[TestAll|https://cassci.datastax.com/view/Dev/view/sbtourist/job/sbtourist-CASSANDRA-12836-testall/1/
 run]||[DTests 
run|https://cassci.datastax.com/view/Dev/view/sbtourist/job/sbtourist-CASSANDRA-12836-dtest/2/]||

[~beobal], any thoughts?

> Set JOINING mode before executing the pre-join index callback
> -
>
> Key: CASSANDRA-12836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12836
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sergio Bossa
>Assignee: Sergio Bossa
>
> The pre-join index callback introduced by CASSANDRA-12039 might perform long 
> running tasks, and given it's blocking, it would be good to set the node in 
> JOINING mode, which currently only happens in case of bootstrap, so that:
> 1) The mode can be properly read by tools.
> 2) Async callback implementation can read the mode themselves to verify at 
> which point of the startup process they are executing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12816) Rebuild failing while adding new datacenter

[sai k potturi (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605525#comment-15605525
 ] 

sai k potturi commented on CASSANDRA-12816:
---

[~jeromatron] : we did'nt happen to see the issue in any of our previous 
versions of Cassandra. We for the first time observed it in 2.1.15. It was not 
an issue in 2.1.12 nor 2.1.14. Just wanted to make sure it was not a bug.

> Rebuild failing while adding new datacenter
> ---
>
> Key: CASSANDRA-12816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12816
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jai Bheemsen Rao Dhanwada
>Priority: Critical
>
> Hello All,
> I have single datacenter with 3 C* nodes and we are trying to expand the 
> cluster to another region/DC. I am seeing the below error while doing a 
> "nodetool rebuild -- name_of_existing_data_center" .  
> {code:java}
> [user@machine ~]$ nodetool rebuild DC1
> nodetool: Unable to find sufficient sources for streaming range 
> (-402178150752044282,-396707578307430827] in keyspace system_distributed
> See 'nodetool help' or 'nodetool help '.
> [user@machine ~]$
> {code}
> {code:java}
> user@cqlsh> SELECT * from system_schema.keyspaces where 
> keyspace_name='system_distributed';
>  keyspace_name | durable_writes | replication
> ---++-
>  system_distributed |   True | {'class': 
> 'org.apache.cassandra.locator.SimpleStrategy', 'replication_factor': '3'}
> (1 rows)
> {code}
> To overcome this I have updated system_distributed keyspace to DC1:3 and 
> DC2:3 with NetworkTopologyStrategy
> C* Version - 3.0.8
> Is this a bug that is introduced in 3.0.8 version of cassandra? as I haven't 
> seen this issue with the older versions?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12739) Nodetool uses cassandra-env.sh MAX_HEAP_SIZE if set

[Jeremiah Jordan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremiah Jordan updated CASSANDRA-12739:

Reproduced In: 3.0.5, 2.2.6  (was: 2.2.6, 3.0.5)
 Reviewer: Eduard Tudenhoefner

> Nodetool uses cassandra-env.sh MAX_HEAP_SIZE if set
> ---
>
> Key: CASSANDRA-12739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12739
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Brad Vernon
> Attachments: nodetool_xmx.patch
>
>
> Nodetool and other bash startup scripts load cassandra-env.sh variables 
> including MAX_HEAP_SIZE as part of CASSANDRA-10679.  If cassandra-env.sh has 
> MAX_HEAP_SIZE set to any value the default heap size needed for the cassandra 
> tool to run is overridden.  
> This is a problem if the using a large heap in C* i.e. 16-32G due to each 
> instance of nodetool or other tool will allocate large heap regardless of 
> need and could exceed the total RAM available on the system.
> Patch removes the check for MAX_HEAP_SIZE being set and uses the default heap 
> size needed for each tool.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12739) Nodetool uses cassandra-env.sh MAX_HEAP_SIZE if set

[Jeremiah Jordan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremiah Jordan updated CASSANDRA-12739:

Status: Ready to Commit  (was: Patch Available)

> Nodetool uses cassandra-env.sh MAX_HEAP_SIZE if set
> ---
>
> Key: CASSANDRA-12739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12739
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Brad Vernon
> Attachments: nodetool_xmx.patch
>
>
> Nodetool and other bash startup scripts load cassandra-env.sh variables 
> including MAX_HEAP_SIZE as part of CASSANDRA-10679.  If cassandra-env.sh has 
> MAX_HEAP_SIZE set to any value the default heap size needed for the cassandra 
> tool to run is overridden.  
> This is a problem if the using a large heap in C* i.e. 16-32G due to each 
> instance of nodetool or other tool will allocate large heap regardless of 
> need and could exceed the total RAM available on the system.
> Patch removes the check for MAX_HEAP_SIZE being set and uses the default heap 
> size needed for each tool.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12739) Nodetool uses cassandra-env.sh MAX_HEAP_SIZE if set

[Eduard Tudenhoefner (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605502#comment-15605502
 ] 

Eduard Tudenhoefner commented on CASSANDRA-12739:
-

Patch looks good IMO and it does what it's supposed to be doing.

> Nodetool uses cassandra-env.sh MAX_HEAP_SIZE if set
> ---
>
> Key: CASSANDRA-12739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12739
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Brad Vernon
> Attachments: nodetool_xmx.patch
>
>
> Nodetool and other bash startup scripts load cassandra-env.sh variables 
> including MAX_HEAP_SIZE as part of CASSANDRA-10679.  If cassandra-env.sh has 
> MAX_HEAP_SIZE set to any value the default heap size needed for the cassandra 
> tool to run is overridden.  
> This is a problem if the using a large heap in C* i.e. 16-32G due to each 
> instance of nodetool or other tool will allocate large heap regardless of 
> need and could exceed the total RAM available on the system.
> Patch removes the check for MAX_HEAP_SIZE being set and uses the default heap 
> size needed for each tool.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12725) dtest failure in repair_tests.incremental_repair_test.TestIncRepair.sstable_marking_test_not_intersecting_all_ranges

[Philip Thompson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Philip Thompson updated CASSANDRA-12725:

Resolution: Fixed
  Reviewer: Sean McCarthy
Status: Resolved  (was: Patch Available)

> dtest failure in 
> repair_tests.incremental_repair_test.TestIncRepair.sstable_marking_test_not_intersecting_all_ranges
> 
>
> Key: CASSANDRA-12725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12725
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Philip Thompson
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/406/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_marking_test_not_intersecting_all_ranges
> {code}
> Error Message
> Subprocess sstablemetadata on keyspace: keyspace1, column_family: None exited 
> with non-zero status; exit status: 1; 
> stdout: 
> usage: Usage: sstablemetadata [--gc_grace_seconds n] 
> Dump contents of given SSTable to standard output in JSON format.
> --gc_grace_secondsThe gc_grace_seconds to use when
>calculating droppable tombstones
> {code}
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File 
> "/home/automaton/cassandra-dtest/repair_tests/incremental_repair_test.py", 
> line 366, in sstable_marking_test_not_intersecting_all_ranges
> for out in (node.run_sstablemetadata(keyspace='keyspace1').stdout for 
> node in cluster.nodelist()):
>   File 
> "/home/automaton/cassandra-dtest/repair_tests/incremental_repair_test.py", 
> line 366, in 
> for out in (node.run_sstablemetadata(keyspace='keyspace1').stdout for 
> node in cluster.nodelist()):
>   File "/usr/local/lib/python2.7/dist-packages/ccmlib/node.py", line 1021, in 
> run_sstablemetadata
> return handle_external_tool_process(p, "sstablemetadata on keyspace: {}, 
> column_family: {}".format(keyspace, column_families))
>   File "/usr/local/lib/python2.7/dist-packages/ccmlib/node.py", line 1983, in 
> handle_external_tool_process
> raise ToolError(cmd_args, rc, out, err)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12837) Add multi-threaded support to nodetool rebuild_index

[vincent royer (JIRA)]

vincent royer created CASSANDRA-12837:
-

 Summary: Add multi-threaded support to nodetool rebuild_index
 Key: CASSANDRA-12837
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12837
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: vincent royer
Priority: Minor
 Fix For: 2.2.9


Add multi-thread nodetool rebuild_index to improve performances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12829) DELETE query with an empty IN clause can delete more than expected

[Alex Petrov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605257#comment-15605257
 ] 

Alex Petrov edited comment on CASSANDRA-12829 at 10/25/16 1:28 PM:
---

Patch for the 3.x branches follows.

Problem was occurring only when there was one clustering column. If we're using 
empty clustering (taken from restriction) in case of DELETE, we create a 
[partition level 
deletion|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java#L59-L63].
 However, in this case what we had to do was going through each clustering and 
add a tombstone for each row. 

In order to correctly handle this case, we now rely on 
{{hasClusteringColumnsRestriction}}. This way we know we have to take the 
clusterings from restrictions and apply updates/deletes. In case there're no 
clustering restrictions (partition-level deletes, updates of static rows, 
updating collections on tables with no clusterings etc), we use 
{{Clustering.EMPTY}} similar to how it was in this code before 
([this|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/MultiCBuilder.java#L262]
 part of call).

|[3.0|https://github.com/ifesdjeen/cassandra/tree/12829-3.0]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-3.0-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-3.0-testall/]|
|[3.X|https://github.com/ifesdjeen/cassandra/tree/12829-3.X]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-3.X-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-3.X-testall/]|
|[trunk|https://github.com/ifesdjeen/cassandra/tree/12829-trunk]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-trunk-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-trunk-testall/]|




was (Author: ifesdjeen):
Patch for the 3.x branches:

|[3.0|https://github.com/ifesdjeen/cassandra/tree/12829-3.0]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-3.0-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-3.0-testall/]|
|[3.X|https://github.com/ifesdjeen/cassandra/tree/12829-3.X]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-3.X-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-3.X-testall/]|
|[trunk|https://github.com/ifesdjeen/cassandra/tree/12829-trunk]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-trunk-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-trunk-testall/]|



> DELETE query with an empty IN clause can delete more than expected
> --
>
> Key: CASSANDRA-12829
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12829
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Arch Linux x64, kernel 4.7.6, Cassandra 3.9 downloaded 
> from the website
>Reporter: Jason T. Bradshaw
>Assignee: Alex Petrov
>
> When deleting from a table with a certain structure and using an *in* clause 
> with an empty list, the *in* clause with an empty list can be ignored, 
> resulting in deleting more than is expected.
> *Setup:*
> {code}
> cqlsh> create table test (a text, b text, id uuid, primary key ((a, b), id));
> cqlsh> insert into test (a, b, id) values ('a', 'b', 
> ----);
> cqlsh> insert into test (a, b, id) values ('b', 'c', 
> ----);
> cqlsh> insert into test (a, b, id) values ('a', 'c', 
> ----);
> cqlsh> select * from test;
>  a | b | id
> ---+---+--
>  a | c | ----
>  b | c | ----
>  a | b | ----
> (3 rows)
> {code}
> *Expected:*
> {code}
> cqlsh> delete from test where a = 'a' and b in ('a', 'b', 'c') and id in ();
> cqlsh> select * from test;
>  a | b | id
> ---+---+--
>  a | c | ----
>  b | c | ----
>  a | b | ----
> (3 rows)
> {code}
> *Actual:*
> {code}
> cqlsh> delete from test where a = 'a' and b in ('a', 'b', 'c') and id in ();
> cqlsh> select * from test;
>  a | b | id
> ---+---+--
>  b | c | ----
> (1 rows)
> {code}
> Instead of deleting nothing, as the final empty *in* clause would imply, it 
> instead deletes everything that matches the first two clauses, acting as if 
> the following query had been issued instead:
> {code}
> cqlsh> delete from test where a = 'a' and b in ('a', 'b', 'c');
> {code}
> This seems to be related to the presence of a tuple clustering key, as I 
> could not reproduce it without one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12829) DELETE query with an empty IN clause can delete more than expected

[Alex Petrov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Petrov updated CASSANDRA-12829:

Status: Patch Available  (was: Open)

Patch for the 3.x branches:

|[3.0|https://github.com/ifesdjeen/cassandra/tree/12829-3.0]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-3.0-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-3.0-testall/]|
|[3.X|https://github.com/ifesdjeen/cassandra/tree/12829-3.X]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-3.X-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-3.X-testall/]|
|[trunk|https://github.com/ifesdjeen/cassandra/tree/12829-trunk]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-trunk-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-trunk-testall/]|



> DELETE query with an empty IN clause can delete more than expected
> --
>
> Key: CASSANDRA-12829
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12829
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Arch Linux x64, kernel 4.7.6, Cassandra 3.9 downloaded 
> from the website
>Reporter: Jason T. Bradshaw
>Assignee: Alex Petrov
>
> When deleting from a table with a certain structure and using an *in* clause 
> with an empty list, the *in* clause with an empty list can be ignored, 
> resulting in deleting more than is expected.
> *Setup:*
> {code}
> cqlsh> create table test (a text, b text, id uuid, primary key ((a, b), id));
> cqlsh> insert into test (a, b, id) values ('a', 'b', 
> ----);
> cqlsh> insert into test (a, b, id) values ('b', 'c', 
> ----);
> cqlsh> insert into test (a, b, id) values ('a', 'c', 
> ----);
> cqlsh> select * from test;
>  a | b | id
> ---+---+--
>  a | c | ----
>  b | c | ----
>  a | b | ----
> (3 rows)
> {code}
> *Expected:*
> {code}
> cqlsh> delete from test where a = 'a' and b in ('a', 'b', 'c') and id in ();
> cqlsh> select * from test;
>  a | b | id
> ---+---+--
>  a | c | ----
>  b | c | ----
>  a | b | ----
> (3 rows)
> {code}
> *Actual:*
> {code}
> cqlsh> delete from test where a = 'a' and b in ('a', 'b', 'c') and id in ();
> cqlsh> select * from test;
>  a | b | id
> ---+---+--
>  b | c | ----
> (1 rows)
> {code}
> Instead of deleting nothing, as the final empty *in* clause would imply, it 
> instead deletes everything that matches the first two clauses, acting as if 
> the following query had been issued instead:
> {code}
> cqlsh> delete from test where a = 'a' and b in ('a', 'b', 'c');
> {code}
> This seems to be related to the presence of a tuple clustering key, as I 
> could not reproduce it without one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12149) NullPointerException on SELECT using index with token restrictions fully overriden by other PK restrictions

[Alex Petrov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605164#comment-15605164
 ] 

Alex Petrov edited comment on CASSANDRA-12149 at 10/25/16 12:17 PM:


Great find! I've added one more test, which would actually yield the results 
between token and non-token restriction. I've fixed it by not falling back to 
non-token restrictions when filtering, since because of token restriction we 
already know the ring part that should be queried.

|[12149-trunk|https://github.com/ifesdjeen/cassandra/tree/12149-trunk]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12149-trunk-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12149-trunk-testall/]|
|[12149-3.X|https://github.com/ifesdjeen/cassandra/tree/12149-3.X]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12149-3.X-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12149-3.X-testall/]|



was (Author: ifesdjeen):
Thank you for the review. Great find! I've added one more test, which would 
actually yield the results between token and non-token restriction. I've fixed 
it by not falling back to non-token restrictions when filtering, since because 
of token restriction we already know the ring part that should be queried.

|[12149-trunk|https://github.com/ifesdjeen/cassandra/tree/12149-trunk]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12149-trunk-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12149-trunk-testall/]|
|[12149-3.X|https://github.com/ifesdjeen/cassandra/tree/12149-3.X]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12149-3.X-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12149-3.X-testall/]|


> NullPointerException on SELECT using index with token restrictions fully 
> overriden by other PK restrictions 
> 
>
> Key: CASSANDRA-12149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12149
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Andrey Konstantinov
>Assignee: Alex Petrov
> Attachments: CASSANDRA-12149.txt
>
>
> If I execute the sequence of queries (see the attached file), Cassandra 
> aborts a connection reporting NPE on server side. SELECT query without token 
> range filter works, but does not work when token range filter is specified. 
> My intent was to issue multiple SELECT queries targeting the same single 
> partition, filtered by a column indexed by SASI, partitioning results by 
> different token ranges.
> Output from cqlsh on SELECT is the following:
> {code}
> cqlsh> SELECT namespace, entity, timestamp, feature1, feature2 FROM 
> mykeyspace.myrecordtable WHERE namespace = 'ns2' AND entity = 'entity2' AND 
> feature1 > 11 AND feature1 < 31  AND token(namespace, entity) <= 
> 9223372036854775807;
> ServerError:  message="java.lang.NullPointerException">
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12149) NullPointerException on SELECT using index with token restrictions fully overriden by other PK restrictions

[Alex Petrov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605164#comment-15605164
 ] 

Alex Petrov commented on CASSANDRA-12149:
-

Thank you for the review. Great find! I've added one more test, which would 
actually yield the results between token and non-token restriction. I've fixed 
it by not falling back to non-token restrictions when filtering, since because 
of token restriction we already know the ring part that should be queried.

|[12149-trunk|https://github.com/ifesdjeen/cassandra/tree/12149-trunk]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12149-trunk-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12149-trunk-testall/]|
|[12149-3.X|https://github.com/ifesdjeen/cassandra/tree/12149-3.X]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12149-3.X-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12149-3.X-testall/]|


> NullPointerException on SELECT using index with token restrictions fully 
> overriden by other PK restrictions 
> 
>
> Key: CASSANDRA-12149
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12149
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Andrey Konstantinov
>Assignee: Alex Petrov
> Attachments: CASSANDRA-12149.txt
>
>
> If I execute the sequence of queries (see the attached file), Cassandra 
> aborts a connection reporting NPE on server side. SELECT query without token 
> range filter works, but does not work when token range filter is specified. 
> My intent was to issue multiple SELECT queries targeting the same single 
> partition, filtered by a column indexed by SASI, partitioning results by 
> different token ranges.
> Output from cqlsh on SELECT is the following:
> {code}
> cqlsh> SELECT namespace, entity, timestamp, feature1, feature2 FROM 
> mykeyspace.myrecordtable WHERE namespace = 'ns2' AND entity = 'entity2' AND 
> feature1 > 11 AND feature1 < 31  AND token(namespace, entity) <= 
> 9223372036854775807;
> ServerError:  message="java.lang.NullPointerException">
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12803) PER PARTITION LIMIT not recognized by cqlsh auto completion

[Benjamin Lerer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer updated CASSANDRA-12803:
---
   Resolution: Fixed
Fix Version/s: (was: 3.x)
   3.10
   Status: Resolved  (was: Ready to Commit)

Committed into 3.X at 8644aa9b822af5f9f917668e8e707febc4bd9c65 and merged into 
trunk

> PER PARTITION LIMIT not recognized by cqlsh auto completion
> ---
>
> Key: CASSANDRA-12803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12803
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Benjamin Lerer
>Priority: Trivial
> Fix For: 3.10
>
> Attachments: 12803-3.X.txt
>
>
> cqlsh's syntax definition does not know about {{PER PARTITION LIMIT}} and 
> therefore does not propose it for auto-completion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12466) Use different build directories for Eclipse and Ant

[Benjamin Lerer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer updated CASSANDRA-12466:
---
   Resolution: Fixed
Fix Version/s: (was: 3.x)
   3.10
   Status: Resolved  (was: Patch Available)

Committed into 3.X at 6497d3727f932d0b9e95f0ecf2440935f82f4530 and merged into 
trunk

> Use different build directories for Eclipse and Ant
> ---
>
> Key: CASSANDRA-12466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12466
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Trivial
> Fix For: 3.10
>
> Attachments: 12466-trunk.patch
>
>
> Currently {{ant generate-eclipse-files}} will create an Eclipse project that 
> will write compile classes into the {{build/classes/main/}} output directory, 
> just as ant does. This causes some issues in practice:
> * Eclipse doesn't recognize changes to compiled classes when compiling with 
> ant. You'll have to manually refresh the project and Eclipse acts weird if 
> you forget to do so.
> * Cleaning the project from Eclipse will remove the {{hotspot_compile}} file 
> and {{ant jar}} won't work any longer as this file is required with ant. 
> Eclipse will be happy to delete it during clean but won't be able to generate 
> it.
> * Tests run by ant may pick up classes compiled by Eclipse that may use 
> different build settings and produce different results for testing
> My suggestion is to simply configure Eclipse to use {{build/classes/eclipse}} 
> instead and leave the ant classes alone. See trivial patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[1/3] cassandra git commit: Use different build directories for Eclipse and Ant

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 9d4fd903f -> 4c728d2e4


Use different build directories for Eclipse and Ant

patch by Stefan Podkowinski; reviewed by Benjamin Lerer for CASSANDRA-12466


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6497d372
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6497d372
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6497d372

Branch: refs/heads/trunk
Commit: 6497d3727f932d0b9e95f0ecf2440935f82f4530
Parents: 13b7362
Author: Stefan Podkowinski 
Authored: Tue Oct 25 12:01:54 2016 +0200
Committer: Benjamin Lerer 
Committed: Tue Oct 25 12:01:54 2016 +0200

--
 CHANGES.txt | 1 +
 build.xml   | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6497d372/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ef728c7..85ef114 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
  * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)
  * Fix RandomReplicationAwareTokenAllocatorTest.testExistingCluster 
(CASSANDRA-12812)
  * Upgrade commons-codec to 1.9 (CASSANDRA-12790)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6497d372/build.xml
--
diff --git a/build.xml b/build.xml
index 40126b0..c178197 100644
--- a/build.xml
+++ b/build.xml
@@ -1788,7 +1788,7 @@
   
   
   
-  
+  
   
   
   

[3/3] cassandra git commit: Merge branch cassandra-3.X into trunk

[blerer]

Merge branch cassandra-3.X into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4c728d2e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4c728d2e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4c728d2e

Branch: refs/heads/trunk
Commit: 4c728d2e48936ba9721926607f79a462925364c9
Parents: 9d4fd90 8644aa9
Author: Benjamin Lerer 
Authored: Tue Oct 25 12:13:41 2016 +0200
Committer: Benjamin Lerer 
Committed: Tue Oct 25 12:13:53 2016 +0200

--
 CHANGES.txt| 2 ++
 build.xml  | 2 +-
 pylib/cqlshlib/cql3handling.py | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4c728d2e/CHANGES.txt
--
diff --cc CHANGES.txt
index 7b2666d,e6477d7..f9e3e34
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,13 -1,6 +1,15 @@@
 +4.0
 + * Add column definition kind to dropped columns in schema (CASSANDRA-12705)
 + * Add (automate) Nodetool Documentation (CASSANDRA-12672)
 + * Update bundled cqlsh python driver to 3.7.0 (CASSANDRA-12736)
 + * Reject invalid replication settings when creating or altering a keyspace 
(CASSANDRA-12681)
 + * Clean up the SSTableReader#getScanner API wrt removal of RateLimiter 
(CASSANDRA-12422)
 +Merged from 3.0:
 + * Include SSTable filename in compacting large row message (CASSANDRA-12384)
 +
  3.10
+  * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
+  * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
   * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)
   * Fix RandomReplicationAwareTokenAllocatorTest.testExistingCluster 
(CASSANDRA-12812)
   * Upgrade commons-codec to 1.9 (CASSANDRA-12790)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/4c728d2e/build.xml
--

[2/3] cassandra git commit: Fix CQLSH auto completion for PER PARTITION LIMIT

[blerer]

Fix CQLSH auto completion for PER PARTITION LIMIT

patch by Benjamin Lerer; reviewed by Robert Stupp for CASSANDRA-12803


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8644aa9b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8644aa9b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8644aa9b

Branch: refs/heads/trunk
Commit: 8644aa9b822af5f9f917668e8e707febc4bd9c65
Parents: 6497d37
Author: Benjamin Lerer 
Authored: Tue Oct 25 12:11:08 2016 +0200
Committer: Benjamin Lerer 
Committed: Tue Oct 25 12:12:26 2016 +0200

--
 CHANGES.txt| 1 +
 pylib/cqlshlib/cql3handling.py | 1 +
 2 files changed, 2 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8644aa9b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 85ef114..e6477d7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
  * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
  * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)
  * Fix RandomReplicationAwareTokenAllocatorTest.testExistingCluster 
(CASSANDRA-12812)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8644aa9b/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 8bd2b59..c628dcd 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -684,6 +684,7 @@ syntax_rules += r'''
   ( "WHERE"  )?
   ( "GROUP" "BY"  ( ","  
)* )?
   ( "ORDER" "BY"  ( ","  
)* )?
+  ( "PER" "PARTITION" "LIMIT" 
perPartitionLimit= )?
   ( "LIMIT" limit= )?
   ( "ALLOW" "FILTERING" )?
 ;

[2/2] cassandra git commit: Fix CQLSH auto completion for PER PARTITION LIMIT

[blerer]

Fix CQLSH auto completion for PER PARTITION LIMIT

patch by Benjamin Lerer; reviewed by Robert Stupp for CASSANDRA-12803


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8644aa9b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8644aa9b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8644aa9b

Branch: refs/heads/cassandra-3.X
Commit: 8644aa9b822af5f9f917668e8e707febc4bd9c65
Parents: 6497d37
Author: Benjamin Lerer 
Authored: Tue Oct 25 12:11:08 2016 +0200
Committer: Benjamin Lerer 
Committed: Tue Oct 25 12:12:26 2016 +0200

--
 CHANGES.txt| 1 +
 pylib/cqlshlib/cql3handling.py | 1 +
 2 files changed, 2 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8644aa9b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 85ef114..e6477d7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
  * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
  * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)
  * Fix RandomReplicationAwareTokenAllocatorTest.testExistingCluster 
(CASSANDRA-12812)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/8644aa9b/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 8bd2b59..c628dcd 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -684,6 +684,7 @@ syntax_rules += r'''
   ( "WHERE"  )?
   ( "GROUP" "BY"  ( ","  
)* )?
   ( "ORDER" "BY"  ( ","  
)* )?
+  ( "PER" "PARTITION" "LIMIT" 
perPartitionLimit= )?
   ( "LIMIT" limit= )?
   ( "ALLOW" "FILTERING" )?
 ;

[1/2] cassandra git commit: Use different build directories for Eclipse and Ant

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.X 13b736249 -> 8644aa9b8


Use different build directories for Eclipse and Ant

patch by Stefan Podkowinski; reviewed by Benjamin Lerer for CASSANDRA-12466


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6497d372
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6497d372
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6497d372

Branch: refs/heads/cassandra-3.X
Commit: 6497d3727f932d0b9e95f0ecf2440935f82f4530
Parents: 13b7362
Author: Stefan Podkowinski 
Authored: Tue Oct 25 12:01:54 2016 +0200
Committer: Benjamin Lerer 
Committed: Tue Oct 25 12:01:54 2016 +0200

--
 CHANGES.txt | 1 +
 build.xml   | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6497d372/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ef728c7..85ef114 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
  * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)
  * Fix RandomReplicationAwareTokenAllocatorTest.testExistingCluster 
(CASSANDRA-12812)
  * Upgrade commons-codec to 1.9 (CASSANDRA-12790)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6497d372/build.xml
--
diff --git a/build.xml b/build.xml
index 40126b0..c178197 100644
--- a/build.xml
+++ b/build.xml
@@ -1788,7 +1788,7 @@
   
   
   
-  
+  
   
   
   

[jira] [Commented] (CASSANDRA-12466) Use different build directories for Eclipse and Ant

[Benjamin Lerer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604852#comment-15604852
 ] 

Benjamin Lerer commented on CASSANDRA-12466:


+1

Sorry for the delay.

> Use different build directories for Eclipse and Ant
> ---
>
> Key: CASSANDRA-12466
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12466
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Trivial
> Fix For: 3.x
>
> Attachments: 12466-trunk.patch
>
>
> Currently {{ant generate-eclipse-files}} will create an Eclipse project that 
> will write compile classes into the {{build/classes/main/}} output directory, 
> just as ant does. This causes some issues in practice:
> * Eclipse doesn't recognize changes to compiled classes when compiling with 
> ant. You'll have to manually refresh the project and Eclipse acts weird if 
> you forget to do so.
> * Cleaning the project from Eclipse will remove the {{hotspot_compile}} file 
> and {{ant jar}} won't work any longer as this file is required with ant. 
> Eclipse will be happy to delete it during clean but won't be able to generate 
> it.
> * Tests run by ant may pick up classes compiled by Eclipse that may use 
> different build settings and produce different results for testing
> My suggestion is to simply configure Eclipse to use {{build/classes/eclipse}} 
> instead and leave the ant classes alone. See trivial patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12373) 3.0 breaks CQL compatibility with super columns families

[Alex Petrov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Petrov updated CASSANDRA-12373:

Status: Patch Available  (was: Open)

I hope I've covered all the corner cases. A small note on the implementation: 
currently I'm using hardcoded column names {{column2}} and {{value}} for the 
fake columns. If you think that can lead to some sort of collision or problem, 
we can try relying on column name generation from {{CompactTables}}, although 
it's going to be more or less same. These columns are not persisted together 
with the rest of schema, they're completely virtual and created during 
{{CFMetadata}} construction.

As [~slebresne] mentioned, {{SelectStatement}}, {{UpdateStatement}} and 
{{DeleteStatement}} were modified to special-case supercolumns, converting from 
map to two columns and reverse.

|[trunk|https://github.com/ifesdjeen/cassandra/tree/12373-trunk-squashed]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12373-trunk-squashed-dtest/]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12373-trunk-squashed-testall/]|
|[2.2|https://github.com/ifesdjeen/cassandra/tree/12373-2.2-squashed]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12373-2.2-squashed-dtest/]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12373-2.2-squashed-testall/]|
|[dtest patch|https://github.com/ifesdjeen/cassandra-dtest/tree/12373]|

> 3.0 breaks CQL compatibility with super columns families
> 
>
> Key: CASSANDRA-12373
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12373
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Sylvain Lebresne
>Assignee: Alex Petrov
> Fix For: 3.0.x, 3.x
>
>
> This is a follow-up to CASSANDRA-12335 to fix the CQL side of super column 
> compatibility.
> The details and a proposed solution can be found in the comments of 
> CASSANDRA-12335 but the crux of the issue is that super column famillies show 
> up differently in CQL in 3.0.x/3.x compared to 2.x, hence breaking backward 
> compatibilty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12651) Failure in SecondaryIndexTest.testAllowFilteringOnPartitionKeyWithSecondaryIndex

[Alex Petrov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604660#comment-15604660
 ] 

Alex Petrov edited comment on CASSANDRA-12651 at 10/25/16 8:35 AM:
---

I've tried to track the problem down, although it's flaking quite infrequently. 
So far I have several "working hypotheses", one of them is that that we have 
name clashes. There's some evidence to name clashes 
[here|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-11803-3.X-testall/lastCompletedBuild/testReport/org.apache.cassandra.index.internal/CassandraIndexTest/indexOnFirstClusteringColumn_compression/]
 and 
[here|http://cassci.datastax.com/job/ifesdjeen-11803-test-fix-trunk-testall/1/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexOnFirstClusteringColumn_compression/].
 

|[trunk|https://github.com/ifesdjeen/cassandra/commits/12651-trunk]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12651-trunk-improved-testall/4/]|

(dtest is not applicable since only test code was changed)

Since the test fails quite infrequently, I just keep re-running with some code 
wrapped around the mentioned failure to re-try multiple times to gather more 
data. However, with this patch I could not reproduce after 30 test runs. I'll 
keep trying though.


was (Author: ifesdjeen):
I've tried to track the problem down, although it's flaking quite infrequently. 
So far I have several "working hypotheses", one of them is that that we have 
name clashes. There's some evidence to name clashes 
[here|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-11803-3.X-testall/lastCompletedBuild/testReport/org.apache.cassandra.index.internal/CassandraIndexTest/indexOnFirstClusteringColumn_compression/]
 and [here|
http://cassci.datastax.com/job/ifesdjeen-11803-test-fix-trunk-testall/1/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexOnFirstClusteringColumn_compression/].
 

|[trunk|https://github.com/ifesdjeen/cassandra/commits/12651-trunk]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12651-trunk-improved-testall/4/]|

(dtest is not applicable since only test code was changed)

Since the test fails quite infrequently, I just keep re-running with some code 
wrapped around the mentioned failure to re-try multiple times to gather more 
data. However, with this patch I could not reproduce after 30 test runs. I'll 
keep trying though.

> Failure in 
> SecondaryIndexTest.testAllowFilteringOnPartitionKeyWithSecondaryIndex
> 
>
> Key: CASSANDRA-12651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12651
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Alex Petrov
>
> This has failed with/without compression.
> Stacktrace:
> {code}
> junit.framework.AssertionFailedError: Got less rows than expected. Expected 2 
> but got 0
>   at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:909)
>   at 
> org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest.lambda$testAllowFilteringOnPartitionKeyWithSecondaryIndex$78(SecondaryIndexTest.java:1228)
>   at 
> org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest$$Lambda$293/218688965.apply(Unknown
>  Source)
>   at 
> org.apache.cassandra.cql3.CQLTester.beforeAndAfterFlush(CQLTester.java:1215)
>   at 
> org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest.testAllowFilteringOnPartitionKeyWithSecondaryIndex(SecondaryIndexTest.java:1218)
> {code}
> Examples:
> http://cassci.datastax.com/job/trunk_testall/1176/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex/
> http://cassci.datastax.com/job/trunk_testall/1176/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex_compression/
> http://cassci.datastax.com/job/trunk_testall/1219/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex/
> http://cassci.datastax.com/job/trunk_testall/1216/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex/
> http://cassci.datastax.com/job/trunk_testall/1208/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex/
> http://cassci.datastax.com/job/trunk_testall/1176/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex/
> 

[jira] [Updated] (CASSANDRA-12651) Failure in SecondaryIndexTest.testAllowFilteringOnPartitionKeyWithSecondaryIndex

[Alex Petrov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Petrov updated CASSANDRA-12651:

Status: Patch Available  (was: Open)

I've tried to track the problem down, although it's flaking quite infrequently. 
So far I have several "working hypotheses", one of them is that that we have 
name clashes. There's some evidence to name clashes 
[here|http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-11803-3.X-testall/lastCompletedBuild/testReport/org.apache.cassandra.index.internal/CassandraIndexTest/indexOnFirstClusteringColumn_compression/]
 and [here|
http://cassci.datastax.com/job/ifesdjeen-11803-test-fix-trunk-testall/1/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexOnFirstClusteringColumn_compression/].
 

|[trunk|https://github.com/ifesdjeen/cassandra/commits/12651-trunk]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12651-trunk-improved-testall/4/]|

(dtest is not applicable since only test code was changed)

Since the test fails quite infrequently, I just keep re-running with some code 
wrapped around the mentioned failure to re-try multiple times to gather more 
data. However, with this patch I could not reproduce after 30 test runs. I'll 
keep trying though.

> Failure in 
> SecondaryIndexTest.testAllowFilteringOnPartitionKeyWithSecondaryIndex
> 
>
> Key: CASSANDRA-12651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12651
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Alex Petrov
>
> This has failed with/without compression.
> Stacktrace:
> {code}
> junit.framework.AssertionFailedError: Got less rows than expected. Expected 2 
> but got 0
>   at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:909)
>   at 
> org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest.lambda$testAllowFilteringOnPartitionKeyWithSecondaryIndex$78(SecondaryIndexTest.java:1228)
>   at 
> org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest$$Lambda$293/218688965.apply(Unknown
>  Source)
>   at 
> org.apache.cassandra.cql3.CQLTester.beforeAndAfterFlush(CQLTester.java:1215)
>   at 
> org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest.testAllowFilteringOnPartitionKeyWithSecondaryIndex(SecondaryIndexTest.java:1218)
> {code}
> Examples:
> http://cassci.datastax.com/job/trunk_testall/1176/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex/
> http://cassci.datastax.com/job/trunk_testall/1176/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex_compression/
> http://cassci.datastax.com/job/trunk_testall/1219/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex/
> http://cassci.datastax.com/job/trunk_testall/1216/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex/
> http://cassci.datastax.com/job/trunk_testall/1208/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex/
> http://cassci.datastax.com/job/trunk_testall/1176/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex/
> http://cassci.datastax.com/job/trunk_testall/1175/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex/
> May or may not be related, but there's a test failure (index duplicate):
> http://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-11803-3.X-testall/lastCompletedBuild/testReport/org.apache.cassandra.index.internal/CassandraIndexTest/indexOnFirstClusteringColumn_compression/
> http://cassci.datastax.com/job/ifesdjeen-11803-test-fix-trunk-testall/1/testReport/junit/org.apache.cassandra.index.internal/CassandraIndexTest/indexOnFirstClusteringColumn_compression/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12125) ERROR [MemtableFlushWriter:4] 2016-07-01 06:20:41,137 CassandraDaemon.java:185 - Exception in thread Thread[MemtableFlushWriter:4,5,main] java.lang.RuntimeEx

[Tom van der Woerdt (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604512#comment-15604512
 ] 

Tom van der Woerdt edited comment on CASSANDRA-12125 at 10/25/16 7:40 AM:
--

This issue still exists in 3.0.9.

{noformat}
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [10..11]: 11
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [12..13]: 38
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [14..15]: 23
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [16..17]: 17
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [18..19]: 12
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [20..21]: 9
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [22..29]: 6
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 Validator.java:235 - 
Validated 1868 partitions for bb1f9dd0-98db-11e6-ad5a-89fa523ea316.  Partition 
sizes are:
INFO  [AntiEntropyStage:1] 2016-10-23 04:46:59,703 Validator.java:274 - [repair 
#bb1f9dd0-98db-11e6-ad5a-89fa523ea316] Sending completed merkle tree to 
/10.0.0.6 for myschema.mytable2
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 -[17232..387341]: 99
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 -  [387342..1097582]: 16
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [1097583..1807823]: 3
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [1807824..2518064]: 7
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [2518065..3959516]: 3
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
CompactionManager.java:1135 - Validation finished in 793 msec, for [repair 
#bb1f9dd0-98db-11e6-ad5a-89fa523ea316 on myschema/mytable2, 
[(-6682001123294953015,-6681421039287311765]]]
DEBUG [CompactionExecutor:51358] 2016-10-23 04:47:00,499 
CompactionTask.java:218 - Compacted (bb4d3d80-98db-11e6-b4a3-2b509f67851f) 2 
sstables to 
[/var/lib/cassandra/data/myschema/mytable2-d66aa7605c6e11e583025dc6433c0832/mc-198850-big,]
 to level=0.  31,664,366 bytes to 31,653,685 (~99% of original) in 1,592ms = 
18.961876MB/s.  0 total partitions merged to 1,888.  Partition merge counts 
were {1:2063, }
DEBUG [GossipStage:1] 2016-10-23 04:47:00,705 FailureDetector.java:456 - 
Ignoring interval time of 2065449328 for /10.0.0.1
DEBUG [GossipStage:1] 2016-10-23 04:47:00,706 FailureDetector.java:456 - 
Ignoring interval time of 2065577694 for /10.0.0.2
DEBUG [GossipStage:1] 2016-10-23 04:47:00,706 FailureDetector.java:456 - 
Ignoring interval time of 2065549822 for /10.0.0.3
DEBUG [Thread-6] 2016-10-23 04:47:01,201 StorageProxy.java:2246 - Schemas are 
in agreement.
DEBUG [GossipStage:1] 2016-10-23 04:47:01,635 FailureDetector.java:456 - 
Ignoring interval time of 2543137972 for /10.0.0.4
DEBUG [GossipStage:1] 2016-10-23 04:47:04,310 FailureDetector.java:456 - 
Ignoring interval time of 2218246254 for /10.0.0.4
DEBUG [GossipStage:1] 2016-10-23 04:47:04,310 FailureDetector.java:456 - 
Ignoring interval time of 2218388771 for /10.0.0.5
DEBUG [GossipStage:1] 2016-10-23 04:47:04,549 FailureDetector.java:456 - 
Ignoring interval time of 2000269752 for /10.0.0.2
DEBUG [AntiEntropyStage:1] 2016-10-23 04:47:05,281 
RepairMessageVerbHandler.java:116 - Validating 
ValidationRequest{gcBefore=1474606025} 
org.apache.cassandra.repair.messages.ValidationRequest@57e4b3c9
DEBUG [ValidationExecutor:3656] 2016-10-23 04:47:05,281 
StorageService.java:2955 - Forcing flush on keyspace myschema, CF mytable1
DEBUG [ValidationExecutor:3656] 2016-10-23 04:47:05,282 
ColumnFamilyStore.java:850 - Enqueuing flush of mytable1: 28142 (0%) on-heap, 
16292220 (0%) off-heap
DEBUG [MemtableFlushWriter:5503] 2016-10-23 04:47:05,282 Memtable.java:368 - 
Writing Memtable-mytable1@1772797855(3.616MiB serialized bytes, 47 ops, 0%/0% 
of on/off-heap limit)
DEBUG [AntiEntropyStage:1] 2016-10-23 04:47:05,285 
RepairMessageVerbHandler.java:133 - Syncing SyncRequest{initiator=/10.0.0.6, 
src=/10.0.0.7, dst=/10.0.0.1, 
ranges=[(-6681996591388643318,-6681992059482333621], 
(-6681946740419236648,-6681942208512926951], 
(-6681933144700307557,-6681928612793997859], 
(-6681915017075068768,-6681910485168759070], 
(-6681896889449829979,-6681892357543520281], 
(-6681887825637210584,-6681883293730900887], 
(-6681842506574113612,-6681837974667803914], 
(-6681837974667803914,-6681833442761494217], 
(-6681815315136255428,-6681810783229945731], 
(-6681810783229945731,-6681801719417326336], 
(-6681783591792087547,-6681779059885777850], 
(-6681769996073158456,-6681765464166848758], 

[jira] [Comment Edited] (CASSANDRA-12125) ERROR [MemtableFlushWriter:4] 2016-07-01 06:20:41,137 CassandraDaemon.java:185 - Exception in thread Thread[MemtableFlushWriter:4,5,main] java.lang.RuntimeEx

[Tom van der Woerdt (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604512#comment-15604512
 ] 

Tom van der Woerdt edited comment on CASSANDRA-12125 at 10/25/16 7:40 AM:
--

This issue still exists in 3.0.9.

{noformat}
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [10..11]: 11
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [12..13]: 38
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [14..15]: 23
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [16..17]: 17
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [18..19]: 12
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [20..21]: 9
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [22..29]: 6
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 Validator.java:235 - 
Validated 1868 partitions for bb1f9dd0-98db-11e6-ad5a-89fa523ea316.  Partition 
sizes are:
INFO  [AntiEntropyStage:1] 2016-10-23 04:46:59,703 Validator.java:274 - [repair 
#bb1f9dd0-98db-11e6-ad5a-89fa523ea316] Sending completed merkle tree to 
/10.0.0.6 for myschema.mytable2
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 -[17232..387341]: 99
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 -  [387342..1097582]: 16
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [1097583..1807823]: 3
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [1807824..2518064]: 7
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [2518065..3959516]: 3
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
CompactionManager.java:1135 - Validation finished in 793 msec, for [repair 
#bb1f9dd0-98db-11e6-ad5a-89fa523ea316 on myschema/mytable2, 
[(-6682001123294953015,-6681421039287311765]]]
DEBUG [CompactionExecutor:51358] 2016-10-23 04:47:00,499 
CompactionTask.java:218 - Compacted (bb4d3d80-98db-11e6-b4a3-2b509f67851f) 2 
sstables to 
[/var/lib/cassandra/data/myschema/mytable2-d66aa7605c6e11e583025dc6433c0832/mc-198850-big,]
 to level=0.  31,664,366 bytes to 31,653,685 (~99% of original) in 1,592ms = 
18.961876MB/s.  0 total partitions merged to 1,888.  Partition merge counts 
were {1:2063, }
DEBUG [GossipStage:1] 2016-10-23 04:47:00,705 FailureDetector.java:456 - 
Ignoring interval time of 2065449328 for /10.0.0.1
DEBUG [GossipStage:1] 2016-10-23 04:47:00,706 FailureDetector.java:456 - 
Ignoring interval time of 2065577694 for /10.0.0.2
DEBUG [GossipStage:1] 2016-10-23 04:47:00,706 FailureDetector.java:456 - 
Ignoring interval time of 2065549822 for /10.0.0.3
DEBUG [Thread-6] 2016-10-23 04:47:01,201 StorageProxy.java:2246 - Schemas are 
in agreement.
DEBUG [GossipStage:1] 2016-10-23 04:47:01,635 FailureDetector.java:456 - 
Ignoring interval time of 2543137972 for /10.0.0.4
DEBUG [GossipStage:1] 2016-10-23 04:47:04,310 FailureDetector.java:456 - 
Ignoring interval time of 2218246254 for /10.0.0.4
DEBUG [GossipStage:1] 2016-10-23 04:47:04,310 FailureDetector.java:456 - 
Ignoring interval time of 2218388771 for /10.0.0.5
DEBUG [GossipStage:1] 2016-10-23 04:47:04,549 FailureDetector.java:456 - 
Ignoring interval time of 2000269752 for /10.0.0.2
DEBUG [AntiEntropyStage:1] 2016-10-23 04:47:05,281 
RepairMessageVerbHandler.java:116 - Validating 
ValidationRequest{gcBefore=1474606025} 
org.apache.cassandra.repair.messages.ValidationRequest@57e4b3c9
DEBUG [ValidationExecutor:3656] 2016-10-23 04:47:05,281 
StorageService.java:2955 - Forcing flush on keyspace myschema, CF mytable1
DEBUG [ValidationExecutor:3656] 2016-10-23 04:47:05,282 
ColumnFamilyStore.java:850 - Enqueuing flush of mytable1: 28142 (0%) on-heap, 
16292220 (0%) off-heap
DEBUG [MemtableFlushWriter:5503] 2016-10-23 04:47:05,282 Memtable.java:368 - 
Writing Memtable-mytable1@1772797855(3.616MiB serialized bytes, 47 ops, 0%/0% 
of on/off-heap limit)
DEBUG [AntiEntropyStage:1] 2016-10-23 04:47:05,285 
RepairMessageVerbHandler.java:133 - Syncing SyncRequest{initiator=/10.0.0.6, 
src=/10.0.0.7, dst=/10.0.0.1, 
ranges=[(-6681996591388643318,-6681992059482333621], 
(-6681946740419236648,-6681942208512926951], 
(-6681933144700307557,-6681928612793997859], 
(-6681915017075068768,-6681910485168759070], 
(-6681896889449829979,-6681892357543520281], 
(-6681887825637210584,-6681883293730900887], 
(-6681842506574113612,-6681837974667803914], 
(-6681837974667803914,-6681833442761494217], 
(-6681815315136255428,-6681810783229945731], 
(-6681810783229945731,-6681801719417326336], 
(-6681783591792087547,-6681779059885777850], 
(-6681769996073158456,-6681765464166848758], 

[jira] [Commented] (CASSANDRA-12125) ERROR [MemtableFlushWriter:4] 2016-07-01 06:20:41,137 CassandraDaemon.java:185 - Exception in thread Thread[MemtableFlushWriter:4,5,main] java.lang.RuntimeExcepti

[Tom van der Woerdt (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604512#comment-15604512
 ] 

Tom van der Woerdt commented on CASSANDRA-12125:


This issue still exists in 3.0.9.

{noformat}
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [10..11]: 11
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [12..13]: 38
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [14..15]: 23
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [16..17]: 17
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [18..19]: 12
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [20..21]: 9
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [22..29]: 6
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 Validator.java:235 - 
Validated 1868 partitions for bb1f9dd0-98db-11e6-ad5a-89fa523ea316.  Partition 
sizes are:
INFO  [AntiEntropyStage:1] 2016-10-23 04:46:59,703 Validator.java:274 - [repair 
#bb1f9dd0-98db-11e6-ad5a-89fa523ea316] Sending completed merkle tree to 
/10.0.0.6 for myschema.mytable2
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 -[17232..387341]: 99
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 -  [387342..1097582]: 16
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [1097583..1807823]: 3
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [1807824..2518064]: 7
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
EstimatedHistogram.java:304 - [2518065..3959516]: 3
DEBUG [ValidationExecutor:3656] 2016-10-23 04:46:59,704 
CompactionManager.java:1135 - Validation finished in 793 msec, for [repair 
#bb1f9dd0-98db-11e6-ad5a-89fa523ea316 on myschema/mytable2, 
[(-6682001123294953015,-6681421039287311765]]]
DEBUG [CompactionExecutor:51358] 2016-10-23 04:47:00,499 
CompactionTask.java:218 - Compacted (bb4d3d80-98db-11e6-b4a3-2b509f67851f) 2 
sstables to 
[/var/lib/cassandra/data/myschema/mytable2-d66aa7605c6e11e583025dc6433c0832/mc-198850-big,]
 to level=0.  31,664,366 bytes to 31,653,685 (~99% of original) in 1,592ms = 
18.961876MB/s.  0 total partitions merged to 1,888.  Partition merge counts 
were {1:2063, }
DEBUG [GossipStage:1] 2016-10-23 04:47:00,705 FailureDetector.java:456 - 
Ignoring interval time of 2065449328 for /10.0.0.1
DEBUG [GossipStage:1] 2016-10-23 04:47:00,706 FailureDetector.java:456 - 
Ignoring interval time of 2065577694 for /10.0.0.2
DEBUG [GossipStage:1] 2016-10-23 04:47:00,706 FailureDetector.java:456 - 
Ignoring interval time of 2065549822 for /10.0.0.3
DEBUG [Thread-6] 2016-10-23 04:47:01,201 StorageProxy.java:2246 - Schemas are 
in agreement.
DEBUG [GossipStage:1] 2016-10-23 04:47:01,635 FailureDetector.java:456 - 
Ignoring interval time of 2543137972 for /10.0.0.4
DEBUG [GossipStage:1] 2016-10-23 04:47:04,310 FailureDetector.java:456 - 
Ignoring interval time of 2218246254 for /10.0.0.4
DEBUG [GossipStage:1] 2016-10-23 04:47:04,310 FailureDetector.java:456 - 
Ignoring interval time of 2218388771 for /10.0.0.5
DEBUG [GossipStage:1] 2016-10-23 04:47:04,549 FailureDetector.java:456 - 
Ignoring interval time of 2000269752 for /10.0.0.2
DEBUG [AntiEntropyStage:1] 2016-10-23 04:47:05,281 
RepairMessageVerbHandler.java:116 - Validating 
ValidationRequest{gcBefore=1474606025} 
org.apache.cassandra.repair.messages.ValidationRequest@57e4b3c9
DEBUG [ValidationExecutor:3656] 2016-10-23 04:47:05,281 
StorageService.java:2955 - Forcing flush on keyspace myschema, CF mytable1
DEBUG [ValidationExecutor:3656] 2016-10-23 04:47:05,282 
ColumnFamilyStore.java:850 - Enqueuing flush of mytable1: 28142 (0%) on-heap, 
16292220 (0%) off-heap
DEBUG [MemtableFlushWriter:5503] 2016-10-23 04:47:05,282 Memtable.java:368 - 
Writing Memtable-mytable1@1772797855(3.616MiB serialized bytes, 47 ops, 0%/0% 
of on/off-heap limit)
DEBUG [AntiEntropyStage:1] 2016-10-23 04:47:05,285 
RepairMessageVerbHandler.java:133 - Syncing SyncRequest{initiator=/10.0.0.6, 
src=/10.0.0.7, dst=/10.0.0.1, 
ranges=[(-6681996591388643318,-6681992059482333621], 
(-6681946740419236648,-6681942208512926951], 
(-6681933144700307557,-6681928612793997859], 
(-6681915017075068768,-6681910485168759070], 
(-6681896889449829979,-6681892357543520281], 
(-6681887825637210584,-6681883293730900887], 
(-6681842506574113612,-6681837974667803914], 
(-6681837974667803914,-6681833442761494217], 
(-6681815315136255428,-6681810783229945731], 
(-6681810783229945731,-6681801719417326336], 
(-6681783591792087547,-6681779059885777850], 
(-6681769996073158456,-6681765464166848758], 
(-6681747336541609969,-6681742804635300272], 

[jira] [Commented] (CASSANDRA-12802) RecoveryManagerTruncateTest fails in 2.1

[Branimir Lambov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604451#comment-15604451
 ] 

Branimir Lambov commented on CASSANDRA-12802:
-

Code LGTM

[~zznate]: I would say that this patch removes risk as it replaces racy logic 
in {{recover}} with a very simple filter based on a value that:
- was there before the patch;
- could cause serious trouble if it was wrong regardless of the patch.

> RecoveryManagerTruncateTest fails in 2.1
> 
>
> Key: CASSANDRA-12802
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12802
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x
>
>
> Example failure:
> http://cassci.datastax.com/view/cassandra-2.1/job/cassandra-2.1_testall/388/testReport/junit/org.apache.cassandra.db/RecoveryManagerTruncateTest/testTruncatePointInTime/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)