cassandra git commit: Restore resumable hints delivery

[aleksey]

Repository: cassandra
Updated Branches:
  refs/heads/trunk d5c53d2bb -> cee22ad54


Restore resumable hints delivery

patch by Stefan Podkowinski and Branimir Lambov; reviewed by Branimir Lambov 
for CASSANDRA-11960


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

Branch: refs/heads/trunk
Commit: cee22ad54d7c28aaf0868dd45aeb9b5b708b0e78
Parents: d5c53d2
Author: Stefan Podkowinski 
Authored: Thu Jun 16 16:31:54 2016 +0200
Committer: Aleksey Yeschenko 
Committed: Mon Aug 8 13:56:57 2016 +0100

--
 CHANGES.txt |   1 +
 .../cassandra/hints/ChecksummedDataInput.java   |  53 +++-
 .../hints/CompressedChecksummedDataInput.java   |  51 +++-
 .../hints/EncryptedChecksummedDataInput.java|  50 +++-
 .../cassandra/hints/HintsDispatchExecutor.java  |  21 +-
 .../apache/cassandra/hints/HintsDispatcher.java |  48 ++--
 .../org/apache/cassandra/hints/HintsReader.java |  34 +--
 .../apache/cassandra/hints/HintsService.java|  27 +-
 .../org/apache/cassandra/hints/HintsStore.java  |  14 +-
 .../apache/cassandra/hints/InputPosition.java   |   9 +
 .../cassandra/security/EncryptionUtils.java |   5 +
 .../cassandra/service/StorageService.java   |   2 +-
 .../apache/cassandra/hints/AlteredHints.java|  17 ++
 .../cassandra/hints/HintsCatalogTest.java   |  31 +++
 .../cassandra/hints/HintsServiceTest.java   | 254 +++
 15 files changed, 540 insertions(+), 77 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/cee22ad5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 15e5001..6fdc04a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -32,6 +32,7 @@
 
 
 3.9
+ * Restore resumable hints delivery (CASSANDRA-11960)
  * Fix nodetool tablestats miss SSTable count (CASSANDRA-12205)
  * Fixed flacky SSTablesIteratedTest (CASSANDRA-12282)
  * Fixed flacky SSTableRewriterTest: check file counts before calling 
validateCFS (CASSANDRA-12348)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/cee22ad5/src/java/org/apache/cassandra/hints/ChecksummedDataInput.java
--
diff --git a/src/java/org/apache/cassandra/hints/ChecksummedDataInput.java 
b/src/java/org/apache/cassandra/hints/ChecksummedDataInput.java
index 8bb5b6d..0db95af 100644
--- a/src/java/org/apache/cassandra/hints/ChecksummedDataInput.java
+++ b/src/java/org/apache/cassandra/hints/ChecksummedDataInput.java
@@ -26,18 +26,19 @@ import com.google.common.base.Preconditions;
 
 import org.apache.cassandra.io.compress.BufferType;
 import org.apache.cassandra.io.util.*;
+import org.apache.cassandra.utils.CLibrary;
 import org.apache.cassandra.utils.memory.BufferPool;
 
 /**
- * A {@link RandomAccessReader} wrapper that calctulates the CRC in place.
+ * A {@link RandomAccessReader} wrapper that calculates the CRC in place.
  *
  * Useful for {@link org.apache.cassandra.hints.HintsReader}, for example, 
where we must verify the CRC, yet don't want
  * to allocate an extra byte array just that purpose. The CRC can be embedded 
in the input stream and checked via checkCrc().
  *
- * In addition to calculating the CRC, it allows to enforce a maximim known 
size. This is needed
+ * In addition to calculating the CRC, it allows to enforce a maximum known 
size. This is needed
  * so that {@link org.apache.cassandra.db.Mutation.MutationSerializer} doesn't 
blow up the heap when deserializing a
  * corrupted sequence by reading a huge corrupted length of bytes via
- * via {@link 
org.apache.cassandra.utils.ByteBufferUtil#readWithLength(java.io.DataInput)}.
+ * {@link 
org.apache.cassandra.utils.ByteBufferUtil#readWithLength(java.io.DataInput)}.
  */
 public class ChecksummedDataInput extends RebufferingInputStream
 {
@@ -81,13 +82,37 @@ public class ChecksummedDataInput extends 
RebufferingInputStream
 return getPosition() == channel.size();
 }
 
+static class Position implements InputPosition
+{
+final long sourcePosition;
+
+public Position(long sourcePosition)
+{
+super();
+this.sourcePosition = sourcePosition;
+}
+
+@Override
+public long subtract(InputPosition other)
+{
+return sourcePosition - ((Position)other).sourcePosition;
+}
+}
+
 /**
- * Returns the position in the source file, which is different for 
getPosition() for compressed/encrypted files
- * and may be imprecise.
+ * Return a seekable representation of 

[jira] [Updated] (CASSANDRA-12377) Add byteman support for 2.2

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-12377:
---
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

Thanks, committed as {{bc9af92e801c631ea4588fae1b4d874a70b0716e}}.

> Add byteman support for 2.2
> ---
>
> Key: CASSANDRA-12377
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12377
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Trivial
> Fix For: 2.2.x
>
>
> Using byteman for dtest is useful to interrupt streaming reliably 
> (CASSANDRA-10810 / https://github.com/riptano/cassandra-dtest/pull/1145).
> Unfortunately, it is available for 3.0+.
> This ticket backports it to 2.2.x.



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

[08/10] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.9

[yukim]

Merge branch 'cassandra-3.0' into cassandra-3.9


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

Branch: refs/heads/cassandra-3.9
Commit: 55aea2db8029f55ccc730e85d01544caccf38746
Parents: 5a902ba 47e63fe
Author: Yuki Morishita 
Authored: Mon Aug 8 07:54:27 2016 -0500
Committer: Yuki Morishita 
Committed: Mon Aug 8 07:54:27 2016 -0500

--

--

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

[yukim]

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/47e63feb
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/47e63feb
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/47e63feb

Branch: refs/heads/cassandra-3.9
Commit: 47e63feb1720c0e427bdd019acfc1312d0b60fe4
Parents: 2d73f3b bc9af92
Author: Yuki Morishita 
Authored: Mon Aug 8 07:54:19 2016 -0500
Committer: Yuki Morishita 
Committed: Mon Aug 8 07:54:19 2016 -0500

--

--

[04/10] cassandra git commit: Add byteman support for testing in 2.2

[yukim]

Add byteman support for testing in 2.2

patch by yukim; reviewed by Paulo Motta for CASSANDRA-12377


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

Branch: refs/heads/trunk
Commit: bc9af92e801c631ea4588fae1b4d874a70b0716e
Parents: dc8a017
Author: Yuki Morishita 
Authored: Wed Aug 3 20:56:35 2016 -0500
Committer: Yuki Morishita 
Committed: Mon Aug 8 07:53:34 2016 -0500

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bc9af92e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5ac79cf..f734476 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.8
+ * Add byteman support for testing (CASSANDRA-12377)
  * Fix INSERT JSON, fromJson() support of smallint, tinyint types 
(CASSANDRA-12371)
  * Restore JVM metric export for metric reporters (CASSANDRA-12312)
  * Release sstables of failed stream sessions only when outgoing transfers are 
finished (CASSANDRA-11345)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/bc9af92e/build.xml
--
diff --git a/build.xml b/build.xml
index 1441194..49a0366 100644
--- a/build.xml
+++ b/build.xml
@@ -116,6 +116,8 @@
 
 
 
+
+
 
 
 
@@ -390,6 +392,11 @@
   
   
 
+  
+  
+  
+
+
   
   
 
@@ -504,6 +511,9 @@
 
 
 
+
+
+
   
 
   

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

[yukim]

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/47e63feb
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/47e63feb
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/47e63feb

Branch: refs/heads/cassandra-3.0
Commit: 47e63feb1720c0e427bdd019acfc1312d0b60fe4
Parents: 2d73f3b bc9af92
Author: Yuki Morishita 
Authored: Mon Aug 8 07:54:19 2016 -0500
Committer: Yuki Morishita 
Committed: Mon Aug 8 07:54:19 2016 -0500

--

--

[02/10] cassandra git commit: Add byteman support for testing in 2.2

[yukim]

Add byteman support for testing in 2.2

patch by yukim; reviewed by Paulo Motta for CASSANDRA-12377


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

Branch: refs/heads/cassandra-3.0
Commit: bc9af92e801c631ea4588fae1b4d874a70b0716e
Parents: dc8a017
Author: Yuki Morishita 
Authored: Wed Aug 3 20:56:35 2016 -0500
Committer: Yuki Morishita 
Committed: Mon Aug 8 07:53:34 2016 -0500

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bc9af92e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5ac79cf..f734476 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.8
+ * Add byteman support for testing (CASSANDRA-12377)
  * Fix INSERT JSON, fromJson() support of smallint, tinyint types 
(CASSANDRA-12371)
  * Restore JVM metric export for metric reporters (CASSANDRA-12312)
  * Release sstables of failed stream sessions only when outgoing transfers are 
finished (CASSANDRA-11345)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/bc9af92e/build.xml
--
diff --git a/build.xml b/build.xml
index 1441194..49a0366 100644
--- a/build.xml
+++ b/build.xml
@@ -116,6 +116,8 @@
 
 
 
+
+
 
 
 
@@ -390,6 +392,11 @@
   
   
 
+  
+  
+  
+
+
   
   
 
@@ -504,6 +511,9 @@
 
 
 
+
+
+
   
 
   

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

[yukim]

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/47e63feb
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/47e63feb
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/47e63feb

Branch: refs/heads/trunk
Commit: 47e63feb1720c0e427bdd019acfc1312d0b60fe4
Parents: 2d73f3b bc9af92
Author: Yuki Morishita 
Authored: Mon Aug 8 07:54:19 2016 -0500
Committer: Yuki Morishita 
Committed: Mon Aug 8 07:54:19 2016 -0500

--

--

[03/10] cassandra git commit: Add byteman support for testing in 2.2

[yukim]

Add byteman support for testing in 2.2

patch by yukim; reviewed by Paulo Motta for CASSANDRA-12377


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

Branch: refs/heads/cassandra-3.9
Commit: bc9af92e801c631ea4588fae1b4d874a70b0716e
Parents: dc8a017
Author: Yuki Morishita 
Authored: Wed Aug 3 20:56:35 2016 -0500
Committer: Yuki Morishita 
Committed: Mon Aug 8 07:53:34 2016 -0500

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bc9af92e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5ac79cf..f734476 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.8
+ * Add byteman support for testing (CASSANDRA-12377)
  * Fix INSERT JSON, fromJson() support of smallint, tinyint types 
(CASSANDRA-12371)
  * Restore JVM metric export for metric reporters (CASSANDRA-12312)
  * Release sstables of failed stream sessions only when outgoing transfers are 
finished (CASSANDRA-11345)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/bc9af92e/build.xml
--
diff --git a/build.xml b/build.xml
index 1441194..49a0366 100644
--- a/build.xml
+++ b/build.xml
@@ -116,6 +116,8 @@
 
 
 
+
+
 
 
 
@@ -390,6 +392,11 @@
   
   
 
+  
+  
+  
+
+
   
   
 
@@ -504,6 +511,9 @@
 
 
 
+
+
+
   
 
   

[01/10] cassandra git commit: Add byteman support for testing in 2.2

[yukim]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 dc8a017c7 -> bc9af92e8
  refs/heads/cassandra-3.0 2d73f3bc4 -> 47e63feb1
  refs/heads/cassandra-3.9 5a902babc -> 55aea2db8
  refs/heads/trunk 143a7d959 -> d5c53d2bb


Add byteman support for testing in 2.2

patch by yukim; reviewed by Paulo Motta for CASSANDRA-12377


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

Branch: refs/heads/cassandra-2.2
Commit: bc9af92e801c631ea4588fae1b4d874a70b0716e
Parents: dc8a017
Author: Yuki Morishita 
Authored: Wed Aug 3 20:56:35 2016 -0500
Committer: Yuki Morishita 
Committed: Mon Aug 8 07:53:34 2016 -0500

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bc9af92e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5ac79cf..f734476 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.8
+ * Add byteman support for testing (CASSANDRA-12377)
  * Fix INSERT JSON, fromJson() support of smallint, tinyint types 
(CASSANDRA-12371)
  * Restore JVM metric export for metric reporters (CASSANDRA-12312)
  * Release sstables of failed stream sessions only when outgoing transfers are 
finished (CASSANDRA-11345)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/bc9af92e/build.xml
--
diff --git a/build.xml b/build.xml
index 1441194..49a0366 100644
--- a/build.xml
+++ b/build.xml
@@ -116,6 +116,8 @@
 
 
 
+
+
 
 
 
@@ -390,6 +392,11 @@
   
   
 
+  
+  
+  
+
+
   
   
 
@@ -504,6 +511,9 @@
 
 
 
+
+
+
   
 
   

[09/10] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.9

[yukim]

Merge branch 'cassandra-3.0' into cassandra-3.9


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

Branch: refs/heads/trunk
Commit: 55aea2db8029f55ccc730e85d01544caccf38746
Parents: 5a902ba 47e63fe
Author: Yuki Morishita 
Authored: Mon Aug 8 07:54:27 2016 -0500
Committer: Yuki Morishita 
Committed: Mon Aug 8 07:54:27 2016 -0500

--

--

[10/10] cassandra git commit: Merge branch 'cassandra-3.9' into trunk

[yukim]

Merge branch 'cassandra-3.9' into trunk


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

Branch: refs/heads/trunk
Commit: d5c53d2bb68fb442e1aad0b67fee18f930032954
Parents: 143a7d9 55aea2d
Author: Yuki Morishita 
Authored: Mon Aug 8 07:54:40 2016 -0500
Committer: Yuki Morishita 
Committed: Mon Aug 8 07:54:40 2016 -0500

--

--

[jira] [Updated] (CASSANDRA-8303) Create a capability limitation framework

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-8303:
---
Status: Patch Available  (was: In Progress)

I've pushed a branch with the bones of an implementation, there are a few 
things left to do on it but nothing that needs to hold up review really. I've 
also added a new dtest fixture.

As [~zznate] suggested, I've left out the generational cache stuff for now. My 
preference is still to include this in the final patch, rather than defer it to 
a separate ticket which I think should be feasible. It ought to be as 
straightforward as dropping in a caching {{RestrictionHandler}} which delegates 
to the table-based one to populate the cache. Obviously, there's slightly more 
to consider, but I'm hopeful of getting it in before commit but if that's not 
possible, at least it isn't blocking anything.

Other stuff which is outstanding & on my todo list:
* javadoc, in-tree docs and commenting new properties in cassandra.yaml
* metrics
* cqlsh help & completion
* there are a couple of unit tests which are just placeholders & need 
implementing
* performance test

||branch||dtest branch||testall||dtest||
|[8303-trunk|https://github.com/beobal/cassandra/tree/8303-trunk]|[8303|https://github.com/beobal/cassandra-dtest/tree/8303]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-8303-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-8303-trunk-dtest]|


> Create a capability limitation framework
> 
>
> Key: CASSANDRA-8303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8303
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Distributed Metadata
>Reporter: Anupam Arora
>Assignee: Sam Tunnicliffe
> Fix For: 3.x
>
>
> In addition to our current Auth framework that acts as a white list, and 
> regulates access to data, functions, and roles, it would be beneficial to 
> have a different, capability limitation framework, that would be orthogonal 
> to Auth, and would act as a blacklist.
> Example uses:
> - take away the ability to TRUNCATE from all users but the admin (TRUNCATE 
> itself would still require MODIFY permission)
> - take away the ability to use ALLOW FILTERING from all users but 
> Spark/Hadoop (SELECT would still require SELECT permission)
> - take away the ability to use UNLOGGED BATCH from everyone (the operation 
> itself would still require MODIFY permission)
> - take away the ability to use certain consistency levels (make certain 
> tables LWT-only for all users, for example)
> Original description:
> Please provide a "strict mode" option in cassandra that will kick out any CQL 
> queries that are expensive, e.g. any query with ALLOWS FILTERING, 
> multi-partition queries, secondary index queries, etc.



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

[jira] [Commented] (CASSANDRA-8911) Consider Mutation-based Repairs

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-8911:


Thanks for the early review

bq. I don't entirely get why we need a separate HUGE response, can't we just 
page back the data from the mismatching replica in the MBRResponse similar to 
ordinary responses?
There are two reasons, first one is that we save one round trip during repair 
of a page. Second reason is that it is easier do diff the remote data with the 
local data if we are not paging. (ie, we know we are comparing the entire 
result, not just a page of it)
bq. While it's handy to have a rows/s metric for repaired rows, I think it 
might be more useful for operators to have a repair throttle knob in MB/S (in 
line with compaction/stream throughput) rather than rows/s, since the load 
imposed by a repairing row can vary between different tables, so it might be a 
bit trickier to do capacity planning based on rows/s.
I have not focused on metrics at all yet, and yes we should add more.
bq. Currently we're throttling only at the coordinator, but it would probably 
be interesting to use the same rate limiter to also throttle participant 
reads/writes.
hmm, maybe makes sense to only throttle on the replicas
bq. Can we make MBROnHeapUnfilteredPartitions a lazy iterator that caches rows 
while its traversed?
good point, will fix
bq. Also, can we leverage MBROnHeapUnfilteredPartitions (or similar) to cache 
iterated rows on MBRVerbHandler?
yep
bq. Try to generify unfiltered and filtered methods/classes into common 
classes/methods when possible (UnfilteredPager, UnfilteredPagersIterator, 
getUnfilteredRangeSlice, etc) (this is probably on your TODO but just a 
friendly reminder)
yeah, a bunch of todos in the code around this
bq. Right now the service runs a full repair for a table which probably makes 
sense for triggered repairs, but when we make that continuous we will probably 
need to interleave subrange repair of different tables to ensure fairness (so 
big tables don't starvate small table repairs).
Yes, splitting the local ranges in smaller parts based on the size of the 
table, then sequentially repairing each part probably makes sense
bq. While repairing other replicas right away will probably get nodes 
consistent faster, I wonder if we can make any simplification by repairing only 
the coordinator node but since the diffs are already there I don't see any 
reason not to do it.
yes we should repair the replicas as well since we know what the replicas need 
to be in sync - also, for incremental repair a range is only repaired if we 
know that the replicas are in sync


> Consider Mutation-based Repairs
> ---
>
> Key: CASSANDRA-8911
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8911
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Tyler Hobbs
>Assignee: Marcus Eriksson
> Fix For: 3.x
>
>
> We should consider a mutation-based repair to replace the existing streaming 
> repair.  While we're at it, we could do away with a lot of the complexity 
> around merkle trees.
> I have not planned this out in detail, but here's roughly what I'm thinking:
>  * Instead of building an entire merkle tree up front, just send the "leaves" 
> one-by-one.  Instead of dealing with token ranges, make the leaves primary 
> key ranges.  The PK ranges would need to be contiguous, so that the start of 
> each range would match the end of the previous range. (The first and last 
> leaves would need to be open-ended on one end of the PK range.) This would be 
> similar to doing a read with paging.
>  * Once one page of data is read, compute a hash of it and send it to the 
> other replicas along with the PK range that it covers and a row count.
>  * When the replicas receive the hash, the perform a read over the same PK 
> range (using a LIMIT of the row count + 1) and compare hashes (unless the row 
> counts don't match, in which case this can be skipped).
>  * If there is a mismatch, the replica will send a mutation covering that 
> page's worth of data (ignoring the row count this time) to the source node.
> Here are the advantages that I can think of:
>  * With the current repair behavior of streaming, vnode-enabled clusters may 
> need to stream hundreds of small SSTables.  This results in increased compact
> ion load on the receiving node.  With the mutation-based approach, memtables 
> would naturally merge these.
>  * It's simple to throttle.  For example, you could give a number of rows/sec 
> that should be repaired.
>  * It's easy to see what PK range has been repaired so far.  This could make 
> it simpler to resume a repair that fails midway.
>  * Inconsistencies start to be repaired almost right away.
>  * Less special code \(?\)

[jira] [Reopened] (CASSANDRA-12280) nodetool repair hangs

[Benjamin Roth (JIRA)]

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

Benjamin Roth reopened CASSANDRA-12280:
---
Reproduced In: 3.7, 3.0.8, 3.9  (was: 3.0.8)

I encountered this issue again (and again and again).
Last time it even happened with the keyspace mentioned in the issue 
description, which contains exactly 6 records in table "dislike" and nothing 
else.
There are currently no reads or writes on that keyspace. Other keypaces in the 
cluster are already in production, so the cluster itself is a bit busy but far 
from being overloaded.
We use reaper for queuing the repairs. The repair that hung was a parallel 
repair with a token range on the whole keyspace.
The repair can not be cancelled by JMX (or by reaper using JMX again), the JMX 
call also hangs. Only restarting all the nodes with hanging repair helps.
I don't see any logs indicating a hard error like broken pipe, timeouts, ...
tpstats shows the hanging repairs, no compactions are ongoing or pending. 
netstats shows 1 or 2 pending messages all the time but it is hard to tell if 
they belong to the hanging repair.

To me it somehow smells of a deadlock situation caused by a race condition. May 
that maybe relate to MVs? Maybe if a base table and a related MV are repaired 
at the same time?

Sometimes I saw in the logs sth like "Could not create snapshot". But it is not 
so easy to tell if that was a cause or an effect.

Are there any tools to dig deeper? More detailed logging? A way to get a trace 
of the repair thread? I mean there are not so many ways to "hang" either the 
thread is waiting for IO or it is locked. It should be quite easy to find out 
whats going on when seeing the BT.

> nodetool repair hangs
> -
>
> Key: CASSANDRA-12280
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12280
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Benjamin Roth
>
> nodetool repair hangs when repairing a keyspace, does not hang when 
> repairting table/mv by table/mv.
> Command executed (both variants make it hang):
> nodetool repair likes like dislike_by_source_mv like_by_contact_mv 
> match_valid_mv like_out dislike match match_by_contact_mv like_valid_mv 
> like_out_by_source_mv
> OR
> nodetool repair likes
> Logs:
> https://gist.github.com/brstgt/bf8b20fa1942d29ab60926ede7340b75
> Nodetool output:
> https://gist.github.com/brstgt/3aa73662da4b0190630ac1aad6c90a6f
> Schema:
> https://gist.github.com/brstgt/3fd59e0166f86f8065085532e3638097



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

[jira] [Updated] (CASSANDRA-11906) Unstable JVM due too many files when anticompacting big LCS tables

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-11906:

Assignee: DS Test Eng

[~cassandra-te] could you try to reproduce this?

> Unstable JVM due too many files when anticompacting big LCS tables
> --
>
> Key: CASSANDRA-11906
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11906
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefano Ortolani
>Assignee: DS Test Eng
>
> I have recently moved from C* 2.1.x to C* 3.0.6. The setup is quite 
> heavy:
>   - 13 nodes with spinning disks
>   - ~120 GB of data per node
>   - 50% of CFs are LCS and have quite wide rows.
>   - 2/3 CFs with LCS have more than 200 SStables
> Incremental repairs do not seem to play really well with that.
> I have been running some tests node by node by using the -pr option:
> {code:xml}
> nodetool -h localhost repair -pr keyscheme
> {code}
> and to my surprise the whole process takes quite some time (1 hour
> minimum, 8 hours if I haven't been repairing for 5/6 days).
> Yesterday I tried to run the command with the -seq option so to 
> decrease the number of simultanoues compactions. After a while
> the node on which I was running the repair simply died during
> the anticompaction phase with the following
> exception in the logs.
> {code:xml}
> ERROR [metrics-graphite-reporter-1-thread-1] 2016-05-25 21:54:21,868 
> ScheduledReporter.java:119 - RuntimeException thrown from 
> GraphiteReporter#report. Exception was suppressed.
> java.lang.RuntimeException: Failed to list files in 
> /data/cassandra/data/keyschema/columnfamily-3996ce80b7ac11e48a9b6776bf484396
>   at 
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:57)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:547)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.filter(Directories.java:691)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$SSTableLister.listFiles(Directories.java:662)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories$TrueFilesSizeVisitor.(Directories.java:981)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.getTrueAllocatedSizeIn(Directories.java:893)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.Directories.trueSnapshotsSize(Directories.java:883) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.trueSnapshotsSize(ColumnFamilyStore.java:2332)
>  ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:637) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> org.apache.cassandra.metrics.TableMetrics$32.getValue(TableMetrics.java:634) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at 
> com.codahale.metrics.graphite.GraphiteReporter.reportGauge(GraphiteReporter.java:281)
>  ~[metrics-graphite-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.graphite.GraphiteReporter.report(GraphiteReporter.java:158)
>  ~[metrics-graphite-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162) 
> ~[metrics-core-3.1.0.jar:3.1.0]
>   at 
> com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117) 
> ~[metrics-core-3.1.0.jar:3.1.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_91]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_91]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_91]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> Caused by: java.lang.RuntimeException: java.nio.file.FileSystemException: 
> /data/cassandra/data/keyschema/columnfamily-3996ce80b7ac11e48a9b6776bf484396/ma_txn_anticompactionafterrepair_f20b50d0-22bd-11e6-970f-6f22464f4624.log:
>  Too many open files
>   at org.apache.cassandra.io.util.FileUtils.readLines(FileUtils.java:622) 
> ~[apache-cassandra-3.0.6.jar:3.0.6]
>   at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1321) 
> ~[na:1.8.0_91]
> 

[jira] [Commented] (CASSANDRA-12405) node health status inconsistent

[Benjamin Roth (JIRA)]

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

Benjamin Roth commented on CASSANDRA-12405:
---

I recognized, that the node "cas1" hat different seeds configured. Seems that 
puppet did not run. Don't know if that relates to the issue.

Seeds are: 10.23.71.101,10.23.71.1,10.23.71.2
On cas1 I think they where 10.23.71.2,10.23.71.3

> node health status inconsistent
> ---
>
> Key: CASSANDRA-12405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12405
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.9, Linux Xenial
>Reporter: Benjamin Roth
>
> ATM we run a 4 node cluster with cassandra 3.9
> Due to another issue (hanging repairs) I am forced to restart nodes from time 
> to time. Before I restart a node, all nodes are listed as UP from any other 
> node.
> When I restart one node in the cluster, the health statuses of other nodes 
> are affected as well.
> After having restarted node "cas", the "nodetool status" output on all nodes 
> looks like this during startup phase of cas1: 
> https://gist.github.com/brstgt/9be77470814d2fd160617a1c06579804
> After cas1 is up again, I restart cas2. During the startup phase of cas2 the 
> status looks like this:
> https://gist.github.com/brstgt/d27ef540b2389b3a7d2d015ab83af547
> The nodetool output goes along with log messages like this:
> 2016-08-08T07:30:06+00:00 cas1 [GossipTasks: 1] 
> org.apache.cassandra.gms.Gossiper Convicting /10.23.71.3 with status NORMAL - 
> alive false
> 2016-08-08T07:30:06+00:00 cas1 [GossipTasks: 1] 
> org.apache.cassandra.gms.Gossiper Convicting /10.23.71.2 with status NORMAL - 
> alive false
> In extreme cases, nodes didn't even come up again after a restart with an 
> error that there are no seed hosts (sorry, don't have the error message in 
> current logs), but the seed host(s) were definitively up and running. A 
> reboot fixed that issue, starting the node again and again did not help.



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

[jira] [Comment Edited] (CASSANDRA-12358) Slow PostFlush execution due to 2i flushing can cause near OOM to OOM

[Branimir Lambov (JIRA)]

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

Branimir Lambov edited comment on CASSANDRA-12358 at 8/8/16 7:48 AM:
-

Looks good.

The tests are very dirty, though, could you rebase and rerun them?


was (Author: blambov):
Looks good.

> Slow PostFlush execution due to 2i flushing can cause near OOM to OOM
> -
>
> Key: CASSANDRA-12358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12358
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
> Fix For: 3.10
>
>
> 2i can be slow to flush for a variety of reasons. Potentially slower than the 
> rate at which Memtables can ingest and flush data. If this occurs the heap 
> fills up with Memtables that are waiting for PostFlush to run.
> This occurs because reclaiming the memory is done before PostFlush runs.
> I will post a branch that has the reclaim memory task run after PostFlush has 
> completed. As far as I can tell this is safe and correct since the memory is 
> committed up until that point.
> It's not clear to me if PostFlush has to bind the Memtables or not. I suspect 
> it does, but I'm not sure if that is a route I should go down.



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

[jira] [Commented] (CASSANDRA-12358) Slow PostFlush execution due to 2i flushing can cause near OOM to OOM

[Branimir Lambov (JIRA)]

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

Branimir Lambov commented on CASSANDRA-12358:
-

Looks good.

> Slow PostFlush execution due to 2i flushing can cause near OOM to OOM
> -
>
> Key: CASSANDRA-12358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12358
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
> Fix For: 3.10
>
>
> 2i can be slow to flush for a variety of reasons. Potentially slower than the 
> rate at which Memtables can ingest and flush data. If this occurs the heap 
> fills up with Memtables that are waiting for PostFlush to run.
> This occurs because reclaiming the memory is done before PostFlush runs.
> I will post a branch that has the reclaim memory task run after PostFlush has 
> completed. As far as I can tell this is safe and correct since the memory is 
> committed up until that point.
> It's not clear to me if PostFlush has to bind the Memtables or not. I suspect 
> it does, but I'm not sure if that is a route I should go down.



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

[jira] [Updated] (CASSANDRA-12366) Fix compaction throttle

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-12366:

Status: Open  (was: Patch Available)

> Fix compaction throttle
> ---
>
> Key: CASSANDRA-12366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12366
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: T Jake Luciani
>Assignee: T Jake Luciani
> Fix For: 3.x
>
>
> Compaction throttling is broken in the following ways:
>   * It throttles bytes read after being decompressed
>   * Compaction creates multiple scanners which share the rate limiter causing 
> too much throttling
>   * It bears no resemblance to the reported compaction time remaining 
> calculation (Bytes of source sstables processed since start of compaction)
> To fix this we need to simplify the throttling to be only at the 
> CompactionIterator level.



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

[jira] [Commented] (CASSANDRA-12405) node health status inconsistent

[Benjamin Roth (JIRA)]

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

Benjamin Roth commented on CASSANDRA-12405:
---

After all nodes have been restarted, all nodes are reported as UP by all nodes.

> node health status inconsistent
> ---
>
> Key: CASSANDRA-12405
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12405
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.9, Linux Xenial
>Reporter: Benjamin Roth
>
> ATM we run a 4 node cluster with cassandra 3.9
> Due to another issue (hanging repairs) I am forced to restart nodes from time 
> to time. Before I restart a node, all nodes are listed as UP from any other 
> node.
> When I restart one node in the cluster, the health statuses of other nodes 
> are affected as well.
> After having restarted node "cas", the "nodetool status" output on all nodes 
> looks like this during startup phase of cas1: 
> https://gist.github.com/brstgt/9be77470814d2fd160617a1c06579804
> After cas1 is up again, I restart cas2. During the startup phase of cas2 the 
> status looks like this:
> https://gist.github.com/brstgt/d27ef540b2389b3a7d2d015ab83af547
> The nodetool output goes along with log messages like this:
> 2016-08-08T07:30:06+00:00 cas1 [GossipTasks: 1] 
> org.apache.cassandra.gms.Gossiper Convicting /10.23.71.3 with status NORMAL - 
> alive false
> 2016-08-08T07:30:06+00:00 cas1 [GossipTasks: 1] 
> org.apache.cassandra.gms.Gossiper Convicting /10.23.71.2 with status NORMAL - 
> alive false
> In extreme cases, nodes didn't even come up again after a restart with an 
> error that there are no seed hosts (sorry, don't have the error message in 
> current logs), but the seed host(s) were definitively up and running. A 
> reboot fixed that issue, starting the node again and again did not help.



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

[jira] [Created] (CASSANDRA-12405) node health status inconsistent

[Benjamin Roth (JIRA)]

Benjamin Roth created CASSANDRA-12405:
-

 Summary: node health status inconsistent
 Key: CASSANDRA-12405
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12405
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 3.9, Linux Xenial
Reporter: Benjamin Roth


ATM we run a 4 node cluster with cassandra 3.9
Due to another issue (hanging repairs) I am forced to restart nodes from time 
to time. Before I restart a node, all nodes are listed as UP from any other 
node.
When I restart one node in the cluster, the health statuses of other nodes are 
affected as well.

After having restarted node "cas", the "nodetool status" output on all nodes 
looks like this during startup phase of cas1: 
https://gist.github.com/brstgt/9be77470814d2fd160617a1c06579804

After cas1 is up again, I restart cas2. During the startup phase of cas2 the 
status looks like this:
https://gist.github.com/brstgt/d27ef540b2389b3a7d2d015ab83af547

The nodetool output goes along with log messages like this:
2016-08-08T07:30:06+00:00 cas1 [GossipTasks: 1] 
org.apache.cassandra.gms.Gossiper Convicting /10.23.71.3 with status NORMAL - 
alive false
2016-08-08T07:30:06+00:00 cas1 [GossipTasks: 1] 
org.apache.cassandra.gms.Gossiper Convicting /10.23.71.2 with status NORMAL - 
alive false

In extreme cases, nodes didn't even come up again after a restart with an error 
that there are no seed hosts (sorry, don't have the error message in current 
logs), but the seed host(s) were definitively up and running. A reboot fixed 
that issue, starting the node again and again did not help.



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

[jira] [Commented] (CASSANDRA-11960) Hints are not seekable

[Branimir Lambov (JIRA)]

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

Branimir Lambov commented on CASSANDRA-11960:
-

LGTM

> Hints are not seekable
> --
>
> Key: CASSANDRA-11960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11960
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Stefan Podkowinski
> Attachments: 11960-trunk.patch
>
>
> Got the following error message on trunk. No idea how to reproduce. But the 
> only thing the (not overridden) seek method does is throwing this exception.
> {code}
> ERROR [HintsDispatcher:2] 2016-06-05 18:51:09,397 CassandraDaemon.java:222 - 
> Exception in thread Thread[HintsDispatcher:2,1,main]
> java.lang.UnsupportedOperationException: Hints are not seekable.
>   at org.apache.cassandra.hints.HintsReader.seek(HintsReader.java:114) 
> ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.seek(HintsDispatcher.java:79) 
> ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:257)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:220)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:199)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_91]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_91]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> {code}



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

[jira] [Updated] (CASSANDRA-11960) Hints are not seekable

[Branimir Lambov (JIRA)]

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

Branimir Lambov updated CASSANDRA-11960:

Status: Ready to Commit  (was: Patch Available)

> Hints are not seekable
> --
>
> Key: CASSANDRA-11960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11960
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Stefan Podkowinski
> Attachments: 11960-trunk.patch
>
>
> Got the following error message on trunk. No idea how to reproduce. But the 
> only thing the (not overridden) seek method does is throwing this exception.
> {code}
> ERROR [HintsDispatcher:2] 2016-06-05 18:51:09,397 CassandraDaemon.java:222 - 
> Exception in thread Thread[HintsDispatcher:2,1,main]
> java.lang.UnsupportedOperationException: Hints are not seekable.
>   at org.apache.cassandra.hints.HintsReader.seek(HintsReader.java:114) 
> ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatcher.seek(HintsDispatcher.java:79) 
> ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:257)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:220)
>  ~[main/:na]
>   at 
> org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:199)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_91]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_91]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_91]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> {code}



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

[jira] [Commented] (CASSANDRA-12242) Could not create trigger

[RocWay Li (JIRA)]

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

RocWay Li commented on CASSANDRA-12242:
---

HI Alex,

Even though running with provided trigger example, the result is still the 
same. Cassandra could not find the trigger class.

Regards
RocWay

> Could not create trigger
> 
>
> Key: CASSANDRA-12242
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12242
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: RocWay Li
> Attachments: DataTrigger.java
>
>
> I tried cassandra 2.2.6 and 3.7, both of them could not create triggers.
> It reports that the trigger class doesn't exist. But it actually does and is 
> at the right directory, the conf/triggers.
> I debugged the source code, and I found that SEPWorker is used to create 
> triggers, but it's thread is not a secure thread, which should be managed by 
> cassandra's SecurityManager and belongs to SecurityThreadGroup.
> When security validation failed, an exception will be thrown. That's direct 
> cause for creating triggers failed.



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

[jira] [Commented] (CASSANDRA-11521) Implement streaming for bulk read requests

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-11521:
--

Thank you!

> Implement streaming for bulk read requests
> --
>
> Key: CASSANDRA-11521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11521
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Local Write-Read Paths
>Reporter: Stefania
>Assignee: Stefania
>  Labels: client-impacting, protocolv5
> Fix For: 3.x
>
> Attachments: final-patch-jfr-profiles-1.zip
>
>
> Allow clients to stream data from a C* host, bypassing the coordination layer 
> and eliminating the need to query individual pages one by one.



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

[jira] [Commented] (CASSANDRA-12403) Slow query detecting

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-12403:
--

Sure, if you have any questions don't hesitate to ask.

> Slow query detecting
> 
>
> Key: CASSANDRA-12403
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12403
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Shogo Hoshii
>Assignee: Shogo Hoshii
> Attachments: sample.log, slow_query.patch
>
>
> Hello,
> In cassandra production environment, users sometimes build anti-pattern 
> tables and throw queries in inefficient manners.
> So I would like to suggest a feature that enables to log slow query.
> The feature can help cassandra operators to identify bad query patterns.
> Then operators can give advices about queries and data model to users who 
> don't know cassandra so much.
> This ticket is related to CASSANDRA-6226, and I focus on detecting bad query 
> patterns, not aborting them.



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

[jira] [Commented] (CASSANDRA-11521) Implement streaming for bulk read requests

[DOAN DuyHai (JIRA)]

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

DOAN DuyHai commented on CASSANDRA-11521:
-

Thanks Stefania, great works!




> Implement streaming for bulk read requests
> --
>
> Key: CASSANDRA-11521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11521
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Local Write-Read Paths
>Reporter: Stefania
>Assignee: Stefania
>  Labels: client-impacting, protocolv5
> Fix For: 3.x
>
> Attachments: final-patch-jfr-profiles-1.zip
>
>
> Allow clients to stream data from a C* host, bypassing the coordination layer 
> and eliminating the need to query individual pages one by one.



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

[jira] [Commented] (CASSANDRA-12403) Slow query detecting

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-12403:
-

Sure, I was just trying to be helpful, as under some circumstances that'd be at 
least a part of possible solution. I understand that this can be helpful for 
the operators.

> Slow query detecting
> 
>
> Key: CASSANDRA-12403
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12403
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Shogo Hoshii
>Assignee: Shogo Hoshii
> Attachments: sample.log, slow_query.patch
>
>
> Hello,
> In cassandra production environment, users sometimes build anti-pattern 
> tables and throw queries in inefficient manners.
> So I would like to suggest a feature that enables to log slow query.
> The feature can help cassandra operators to identify bad query patterns.
> Then operators can give advices about queries and data model to users who 
> don't know cassandra so much.
> This ticket is related to CASSANDRA-6226, and I focus on detecting bad query 
> patterns, not aborting them.



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