[jira] [Commented] (CASSANDRA-12730) Thousands of empty SSTables created during repair - TMOF death

[Benjamin Roth (JIRA)]

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

Benjamin Roth commented on CASSANDRA-12730:
---

Good point. I also encountered situations where repairs behaved not as expected 
(e.g. see CASSANDRA-12489). Unfortunately I did not have the time yet to 
investigate more on that.

But for that very case we run into recently, I guess this "harmless 
optimization" could help the server to survive that situation without crashing. 
The cause that crashed the server was not that there were a lot of streams 
(which in this case were probably in deed necessary) but that there were more 
than 100k open files which could have been easily avoided if the flushes 
wouldn't have created tens of thousands nearly empty SSTables.

So why not optimize the one situation and investigate on the other?


> Thousands of empty SSTables created during repair - TMOF death
> --
>
> Key: CASSANDRA-12730
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12730
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Benjamin Roth
>Priority: Critical
>
> Last night I ran a repair on a keyspace with 7 tables and 4 MVs each 
> containing a few hundret million records. After a few hours a node died 
> because of "too many open files".
> Normally one would just raise the limit, but: We already set this to 100k. 
> The problem was that the repair created roughly over 100k SSTables for a 
> certain MV. The strange thing is that these SSTables had almost no data (like 
> 53bytes, 90bytes, ...). Some of them (<5%) had a few 100 KB, very few (<1% 
> had normal sizes like >= few MB). I could understand, that SSTables queue up 
> as they are flushed and not compacted in time but then they should have at 
> least a few MB (depending on config and avail mem), right?
> Of course then the node runs out of FDs and I guess it is not a good idea to 
> raise the limit even higher as I expect that this would just create even more 
> empty SSTables before dying at last.
> Only 1 CF (MV) was affected. All other CFs (also MVs) behave sanely. Empty 
> SSTables have been created equally over time. 100-150 every minute. Among the 
> empty SSTables there are also Tables that look normal like having few MBs.
> I didn't see any errors or exceptions in the logs until TMOF occured. Just 
> tons of streams due to the repair (which I actually run over cs-reaper as 
> subrange, full repairs).
> After having restarted that node (and no more repair running), the number of 
> SSTables went down again as they are compacted away slowly.
> According to [~zznate] this issue may relate to CASSANDRA-10342 + 
> CASSANDRA-8641



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

[jira] [Commented] (CASSANDRA-12730) Thousands of empty SSTables created during repair - TMOF death

[Benjamin Roth (JIRA)]

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

Benjamin Roth commented on CASSANDRA-12730:
---

Currently we use a fork that fixed CASSANDRA-12689, which is already merged but 
we haven't rolled the current trunk.

https://github.com/Jaumo/cassandra/commits/CASSANDRA-12689. So the closest 
official commit is bddfd643b0d1ccebf129a10fa0e0a60289c9dea0 from 23/Sep/16

> Thousands of empty SSTables created during repair - TMOF death
> --
>
> Key: CASSANDRA-12730
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12730
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Benjamin Roth
>Priority: Critical
>
> Last night I ran a repair on a keyspace with 7 tables and 4 MVs each 
> containing a few hundret million records. After a few hours a node died 
> because of "too many open files".
> Normally one would just raise the limit, but: We already set this to 100k. 
> The problem was that the repair created roughly over 100k SSTables for a 
> certain MV. The strange thing is that these SSTables had almost no data (like 
> 53bytes, 90bytes, ...). Some of them (<5%) had a few 100 KB, very few (<1% 
> had normal sizes like >= few MB). I could understand, that SSTables queue up 
> as they are flushed and not compacted in time but then they should have at 
> least a few MB (depending on config and avail mem), right?
> Of course then the node runs out of FDs and I guess it is not a good idea to 
> raise the limit even higher as I expect that this would just create even more 
> empty SSTables before dying at last.
> Only 1 CF (MV) was affected. All other CFs (also MVs) behave sanely. Empty 
> SSTables have been created equally over time. 100-150 every minute. Among the 
> empty SSTables there are also Tables that look normal like having few MBs.
> I didn't see any errors or exceptions in the logs until TMOF occured. Just 
> tons of streams due to the repair (which I actually run over cs-reaper as 
> subrange, full repairs).
> After having restarted that node (and no more repair running), the number of 
> SSTables went down again as they are compacted away slowly.
> According to [~zznate] this issue may relate to CASSANDRA-10342 + 
> CASSANDRA-8641



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

[jira] [Commented] (CASSANDRA-12876) Negative mean write latency

[JIRA]

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

Per Otterström commented on CASSANDRA-12876:


Yes, must be related to the 30 minute rescaling. I'm able o reproduce in a test 
cluster. I'm seeing a similar pattern for the standard deviation as well.

Can't make out why this happens just by reviewing code, but I'll run some more 
tests.

> Negative mean write latency
> ---
>
> Key: CASSANDRA-12876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12876
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability
>Reporter: Kévin LOVATO
> Attachments: negative_mean.png, negative_mean_periodicity.PNG
>
>
> The mean write latency returned by JMX turns negative every 30 minutes. As 
> the attached screenshots show, the value turns negative every 30 minutes 
> after the startup of the node.
> We did not experience this behavior in 2.1.16.



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

[jira] [Assigned] (CASSANDRA-12876) Negative mean write latency

[JIRA]

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

Per Otterström reassigned CASSANDRA-12876:
--

Assignee: Per Otterström

> Negative mean write latency
> ---
>
> Key: CASSANDRA-12876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12876
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability
>Reporter: Kévin LOVATO
>Assignee: Per Otterström
> Attachments: negative_mean.png, negative_mean_periodicity.PNG
>
>
> The mean write latency returned by JMX turns negative every 30 minutes. As 
> the attached screenshots show, the value turns negative every 30 minutes 
> after the startup of the node.
> We did not experience this behavior in 2.1.16.



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

[jira] [Commented] (CASSANDRA-10876) Alter behavior of batch WARN and fail on single partition batches

[Oleg Krayushkin (JIRA)]

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

Oleg Krayushkin commented on CASSANDRA-10876:
-

+1

> Alter behavior of batch WARN and fail on single partition batches
> -
>
> Key: CASSANDRA-10876
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10876
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Patrick McFadin
>Assignee: Sylvain Lebresne
>Priority: Minor
>  Labels: lhf
> Fix For: 3.6
>
> Attachments: 10876.txt
>
>
> In an attempt to give operator insight into potentially harmful batch usage, 
> Jiras were created to log WARN or fail on certain batch sizes. This ignores 
> the single partition batch, which doesn't create the same issues as a 
> multi-partition batch. 
> The proposal is to ignore size on single partition batch statements. 
> Reference:
> [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487]
> [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011]



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

[jira] [Commented] (CASSANDRA-12676) Message coalescing regression

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-12676:


3.x, maybe, but not 3.0. People who validate releases for prod clusters don't 
tend to enjoy hidden config changes mid-branch, especially for options not in 
the yaml.





> Message coalescing regression
> -
>
> Key: CASSANDRA-12676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12676
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>  Labels: docs-impacting
> Fix For: 2.2.x, 3.0.x
>
>
> The default in 2.2+ was to enable TIMEHORIZON message coalescing.  After 
> reports of performance regressions after upgrading from 2.1 to 2.2/3.0 we 
> have discovered the issue to be this default.
> We need to re-test our assumptions on this feature but in the meantime we 
> should default back to disabled.
> Here is a performance run [with and without message 
> coalescing|http://cstar.datastax.com/graph?command=one_job=9a26b5f2-7f48-11e6-92e7-0256e416528f=op_rate=2_user=1_aggregates=true=0=508.86=0=91223]
>  



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

[jira] [Commented] (CASSANDRA-12855) Correct Spelling Errors in IEndPointSnitch JavaDocs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-12855:


Github user asfgit closed the pull request at:

https://github.com/apache/cassandra/pull/79


> Correct Spelling Errors in IEndPointSnitch JavaDocs
> ---
>
> Key: CASSANDRA-12855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12855
> Project: Cassandra
>  Issue Type: Task
>  Components: Distributed Metadata, Documentation and Website
>Reporter: Christopher Licata 
>Priority: Trivial
>  Labels: lhf
> Fix For: 4.0
>
> Attachments: 12855-trunk.txt
>
>
> There are some spelling errors in the JavaDocs for IEndpointSnitch. 



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

[jira] [Resolved] (CASSANDRA-12855) Correct Spelling Errors in IEndPointSnitch JavaDocs

[mck (JIRA)]

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

mck resolved CASSANDRA-12855.
-
Resolution: Fixed

> Correct Spelling Errors in IEndPointSnitch JavaDocs
> ---
>
> Key: CASSANDRA-12855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12855
> Project: Cassandra
>  Issue Type: Task
>  Components: Distributed Metadata, Documentation and Website
>Reporter: Christopher Licata 
>Priority: Trivial
>  Labels: lhf
> Fix For: 4.0
>
> Attachments: 12855-trunk.txt
>
>
> There are some spelling errors in the JavaDocs for IEndpointSnitch. 



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

cassandra git commit: Correct Spelling Errors in IEndPointSnitch JavaDocs

[mck]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 459946aee -> 138f7b5d0


Correct Spelling Errors in IEndPointSnitch JavaDocs

Patch by Christopher Licata ; reviewed by Mick Semb Wever for CASSANDRA-12855
This closes #79


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

Branch: refs/heads/trunk
Commit: 138f7b5d005c9554e9c87a7fa03df23c32d551a4
Parents: 459946a
Author: Mick Semb Wever 
Authored: Tue Nov 8 12:32:03 2016 +1100
Committer: Mick Semb Wever 
Committed: Tue Nov 8 12:32:03 2016 +1100

--
 src/java/org/apache/cassandra/locator/IEndpointSnitch.java | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/138f7b5d/src/java/org/apache/cassandra/locator/IEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/IEndpointSnitch.java 
b/src/java/org/apache/cassandra/locator/IEndpointSnitch.java
index 690b84f..71b441c 100644
--- a/src/java/org/apache/cassandra/locator/IEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/IEndpointSnitch.java
@@ -22,15 +22,15 @@ import java.util.Collection;
 import java.util.List;
 
 /**
- * This interface helps determine location of node in the data center relative 
to another node.
+ * This interface helps determine location of node in the datacenter relative 
to another node.
  * Give a node A and another node B it can tell if A and B are on the same 
rack or in the same
- * data center.
+ * datacenter.
  */
 
 public interface IEndpointSnitch
 {
 /**
- * returns a String repesenting the rack this endpoint belongs to
+ * returns a String representing the rack this endpoint belongs to
  */
 public String getRack(InetAddress endpoint);
 

[Cassandra Wiki] Update of "ContributorsGroup" by MichaelShuler

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "ContributorsGroup" page has been changed by MichaelShuler:
https://wiki.apache.org/cassandra/ContributorsGroup?action=diff=65=66

   * RussellHatch
   * SamTunnicliffe
   * SergeRider
+  * SmartCat
   * StefaniaAlborghetti
   * StephenBlackheath
   * StephenConnolly

[jira] [Updated] (CASSANDRA-12855) Correct Spelling Errors in IEndPointSnitch JavaDocs

[mck (JIRA)]

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

mck updated CASSANDRA-12855:

Attachment: 12855-trunk.txt

> Correct Spelling Errors in IEndPointSnitch JavaDocs
> ---
>
> Key: CASSANDRA-12855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12855
> Project: Cassandra
>  Issue Type: Task
>  Components: Distributed Metadata, Documentation and Website
>Reporter: Christopher Licata 
>Priority: Trivial
>  Labels: lhf
> Fix For: 4.0
>
> Attachments: 12855-trunk.txt
>
>
> There are some spelling errors in the JavaDocs for IEndpointSnitch. 



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

[jira] [Updated] (CASSANDRA-12855) Correct Spelling Errors in IEndPointSnitch JavaDocs

[mck (JIRA)]

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

mck updated CASSANDRA-12855:

Reviewer: mck

> Correct Spelling Errors in IEndPointSnitch JavaDocs
> ---
>
> Key: CASSANDRA-12855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12855
> Project: Cassandra
>  Issue Type: Task
>  Components: Distributed Metadata, Documentation and Website
>Reporter: Christopher Licata 
>Priority: Trivial
>  Labels: lhf
> Fix For: 4.0
>
>
> There are some spelling errors in the JavaDocs for IEndpointSnitch. 



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

[jira] [Updated] (CASSANDRA-12855) Correct Spelling Errors in IEndPointSnitch JavaDocs

[mck (JIRA)]

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

mck updated CASSANDRA-12855:

Fix Version/s: (was: 3.x)
   4.0

> Correct Spelling Errors in IEndPointSnitch JavaDocs
> ---
>
> Key: CASSANDRA-12855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12855
> Project: Cassandra
>  Issue Type: Task
>  Components: Distributed Metadata, Documentation and Website
>Reporter: Christopher Licata 
>Priority: Trivial
>  Labels: lhf
> Fix For: 4.0
>
>
> There are some spelling errors in the JavaDocs for IEndpointSnitch. 



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

[jira] [Commented] (CASSANDRA-8502) Static columns returning null for pages after first

[Philip Thompson (JIRA)]

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

Philip Thompson commented on CASSANDRA-8502:


I believe so. I assume either the follow-up patch should have been committed to 
2.0, or a separate jira should have been opened, if the fix vers were going to 
deviate.

> Static columns returning null for pages after first
> ---
>
> Key: CASSANDRA-8502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8502
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Flavien Charlon
>Assignee: Tyler Hobbs
> Fix For: 2.0.16, 2.1.6, 2.2.0 rc1
>
> Attachments: 8502-2.0-v2.txt, 8502-2.0.txt, 8502-2.1-v2.txt, 
> null-static-column.txt
>
>
> When paging is used for a query containing a static column, the first page 
> contains the right value for the static column, but subsequent pages have 
> null null for the static column instead of the expected value.
> Repro steps:
> - Create a table with a static column
> - Create a partition with 500 cells
> - Using cqlsh, query that partition
> Actual result:
> - You will see that first, the static column appears as expected, but if you 
> press a key after "---MORE---", the static columns will appear as null.
> See the attached file for a repro of the output.
> I am using a single node cluster.



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

[jira] [Commented] (CASSANDRA-8502) Static columns returning null for pages after first

[Richard Low (JIRA)]

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

Richard Low commented on CASSANDRA-8502:


Doesn't Dave's patch change behaviour though? We think we're seeing this in 
2.0.17 but not 2.1.

> Static columns returning null for pages after first
> ---
>
> Key: CASSANDRA-8502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8502
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Flavien Charlon
>Assignee: Tyler Hobbs
> Fix For: 2.0.16, 2.1.6, 2.2.0 rc1
>
> Attachments: 8502-2.0-v2.txt, 8502-2.0.txt, 8502-2.1-v2.txt, 
> null-static-column.txt
>
>
> When paging is used for a query containing a static column, the first page 
> contains the right value for the static column, but subsequent pages have 
> null null for the static column instead of the expected value.
> Repro steps:
> - Create a table with a static column
> - Create a partition with 500 cells
> - Using cqlsh, query that partition
> Actual result:
> - You will see that first, the static column appears as expected, but if you 
> press a key after "---MORE---", the static columns will appear as null.
> See the attached file for a repro of the output.
> I am using a single node cluster.



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

[jira] [Commented] (CASSANDRA-8502) Static columns returning null for pages after first

[Philip Thompson (JIRA)]

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

Philip Thompson commented on CASSANDRA-8502:


Well, the original patch was committed to 2.0.16, but Dave's proposed follow-up 
was not. Seems like it is appropriate to leave 2.0.16 in the fixvers?

> Static columns returning null for pages after first
> ---
>
> Key: CASSANDRA-8502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8502
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Flavien Charlon
>Assignee: Tyler Hobbs
> Fix For: 2.0.16, 2.1.6, 2.2.0 rc1
>
> Attachments: 8502-2.0-v2.txt, 8502-2.0.txt, 8502-2.1-v2.txt, 
> null-static-column.txt
>
>
> When paging is used for a query containing a static column, the first page 
> contains the right value for the static column, but subsequent pages have 
> null null for the static column instead of the expected value.
> Repro steps:
> - Create a table with a static column
> - Create a partition with 500 cells
> - Using cqlsh, query that partition
> Actual result:
> - You will see that first, the static column appears as expected, but if you 
> press a key after "---MORE---", the static columns will appear as null.
> See the attached file for a repro of the output.
> I am using a single node cluster.



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

[jira] [Commented] (CASSANDRA-10446) Run repair with down replicas

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-10446:
-

Oh wow, good catch, that's not good. So that issue, and several others, will be 
addressed in CASSANDRA-9143. I'm hoping to post a patch for it by the end of 
this week. Since that should address the fundamental issue of data being 
misclassified as repaired I've just pushed a commit up to my branch that 
doesn't set repairedAt, or run anti-compaction when the force flag is set.

> Run repair with down replicas
> -
>
> Key: CASSANDRA-10446
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10446
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 4.0
>
>
> We should have an option of running repair when replicas are down. We can 
> call it -force.



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

[jira] [Commented] (CASSANDRA-8502) Static columns returning null for pages after first

[Richard Low (JIRA)]

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

Richard Low commented on CASSANDRA-8502:


Can someone remove 2.0.16 from the fix versions, since the above change was 
only applied in 2.1?

> Static columns returning null for pages after first
> ---
>
> Key: CASSANDRA-8502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8502
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Flavien Charlon
>Assignee: Tyler Hobbs
> Fix For: 2.0.16, 2.1.6, 2.2.0 rc1
>
> Attachments: 8502-2.0-v2.txt, 8502-2.0.txt, 8502-2.1-v2.txt, 
> null-static-column.txt
>
>
> When paging is used for a query containing a static column, the first page 
> contains the right value for the static column, but subsequent pages have 
> null null for the static column instead of the expected value.
> Repro steps:
> - Create a table with a static column
> - Create a partition with 500 cells
> - Using cqlsh, query that partition
> Actual result:
> - You will see that first, the static column appears as expected, but if you 
> press a key after "---MORE---", the static columns will appear as null.
> See the attached file for a repro of the output.
> I am using a single node cluster.



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

[jira] [Commented] (CASSANDRA-12730) Thousands of empty SSTables created during repair - TMOF death

[Kurt Greaves (JIRA)]

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

Kurt Greaves commented on CASSANDRA-12730:
--

For the record, it seems to me like this is a potentially harmless 
optimisation, but doesn't really fix the core issue.

 I've seen similar issues on a lot of clusters on a lot of different versions 
(pretty much every version since 2.1.11). This issue occurs quite frequently 
and not necessarily on clusters under heap pressure. Usually when we see this 
issue the logs report masses of streaming sessions and flushes. The proposed 
solution seems to be simple and harmless enough even though it may not fix the 
real issue and I think would help in cases where there are a small amount of 
constant writes to a table such that the memtable is never/rarely clean when 
the flush is triggered, resulting in lots of small SSTables. 

I think the real issue is a problem elsewhere that triggers lots of stream 
sessions during the repair even though the data is consistent. We've seen this 
sort of thing in cases where we're fairly sure there have been no down nodes 
and no dropped mutations, and even running repairs continuously results in many 
streams.



> Thousands of empty SSTables created during repair - TMOF death
> --
>
> Key: CASSANDRA-12730
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12730
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Benjamin Roth
>Priority: Critical
>
> Last night I ran a repair on a keyspace with 7 tables and 4 MVs each 
> containing a few hundret million records. After a few hours a node died 
> because of "too many open files".
> Normally one would just raise the limit, but: We already set this to 100k. 
> The problem was that the repair created roughly over 100k SSTables for a 
> certain MV. The strange thing is that these SSTables had almost no data (like 
> 53bytes, 90bytes, ...). Some of them (<5%) had a few 100 KB, very few (<1% 
> had normal sizes like >= few MB). I could understand, that SSTables queue up 
> as they are flushed and not compacted in time but then they should have at 
> least a few MB (depending on config and avail mem), right?
> Of course then the node runs out of FDs and I guess it is not a good idea to 
> raise the limit even higher as I expect that this would just create even more 
> empty SSTables before dying at last.
> Only 1 CF (MV) was affected. All other CFs (also MVs) behave sanely. Empty 
> SSTables have been created equally over time. 100-150 every minute. Among the 
> empty SSTables there are also Tables that look normal like having few MBs.
> I didn't see any errors or exceptions in the logs until TMOF occured. Just 
> tons of streams due to the repair (which I actually run over cs-reaper as 
> subrange, full repairs).
> After having restarted that node (and no more repair running), the number of 
> SSTables went down again as they are compacted away slowly.
> According to [~zznate] this issue may relate to CASSANDRA-10342 + 
> CASSANDRA-8641



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

[jira] [Comment Edited] (CASSANDRA-12649) Add BATCH metrics

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer edited comment on CASSANDRA-12649 at 11/7/16 10:45 PM:
--

I had a discussion earlier today with [~tjake] who has more experience than me 
with Cassandra performance and Stress. He pointed out to me that we already use 
{{PartitionUpdate::dataSize}} to issue batch size warnings in 
{{BatchStatement::verifyBatchSize}}. His suggestion was to move the metric to 
{{BatchStatement}} as it will allow the patch to reuse the result of the 
existing call and avoid having the to compute the size on each replica.
The idea would be then to add that metric to your {{BatchMetrics}} instead of 
adding it to {{TableMetrics}}.

I looked at {{BatchStatement}} and it seems that the {{verifyBatchSize}} is 
only called for batch without conditions. I opened CASSANDRA-12885 to address 
that problem. If you can fix it first, it would be great :-).

Regarding your initial patch, I also have the following nits:
* {{BatchMetrics}} has a {{start}} method that does nothing and should be 
removed (including the call to it in {{StorageService}})
* Instead of making {{BatchMetrics}} a singleton you could have a public static 
variable in {{BatchStatement}} (similar to {{CQLMetrics}} in 
{{QueryProcessor}}) as it is more inline with the rest of the code.
* It would be nice if you could add the documentation for those new metrics in 
{{doc/source/operating/metrics.rts}} 




was (Author: blerer):
I had a discussion earlier today with [~tjake] who has more experience than me 
with Cassandra performance and Stress. It pointed out to me that we already use 
{{PartitionUpdate::dataSize}} to issue batch size warnings in 
{{BatchStatement::verifyBatchSize}}. His suggestion was to move the metric to 
{{BatchStatement}} as it will allow the patch to reuse the result of the 
existing call and avoid having the to compute the size on each replica.
The idea would be then to add that metric to your {{BatchMetrics}} instead of 
adding it to {{TableMetrics}}.

I looked at {{BatchStatement}} and it seems that the {{verifyBatchSize}} is 
only called for batch without conditions. I opened CASSANDRA-12885 to address 
that problem. If you can fix it first, it would be great :-).

Regarding your initial patch, I also have the following nits:
* {{BatchMetrics}} has a {{start}} method that does nothing and should be 
removed (including the call to it in {{StorageService}})
* Instead of making {{BatchMetrics}} a singleton you could have a public static 
variable in {{BatchStatement}} (similar to {{CQLMetrics}} in 
{{QueryProcessor}}) as it is more inline with the rest of the code.
* It would be nice if you could add the documentation for those new metrics in 
{{doc/source/operating/metrics.rts}} 



> Add BATCH metrics
> -
>
> Key: CASSANDRA-12649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12649
> Project: Cassandra
>  Issue Type: Wish
>Reporter: Alwyn Davis
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 12649-3.x.patch, stress-batch-metrics.tar.gz, 
> stress-trunk.tar.gz, trunk-12649.txt
>
>
> To identify causes of load on a cluster, it would be useful to have some 
> additional metrics:
> * *Mutation size distribution:* I believe this would be relevant when 
> tracking the performance of unlogged batches.
> * *Logged / Unlogged Partitions per batch distribution:* This would also give 
> a count of batch types processed. Multiple distinct tables in batch would 
> just be considered as separate partitions.



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

[jira] [Comment Edited] (CASSANDRA-12649) Add BATCH metrics

[Alwyn Davis (JIRA)]

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

Alwyn Davis edited comment on CASSANDRA-12649 at 11/7/16 10:13 PM:
---

Thanks for the awesome feedback! I'll try moving the metrics to 
{{BatchStatement}} and verifying the performance impact with some JMH 
benchmarks.


was (Author: alwyn):
Thanks for the awesome feedback! I'll try moving the metrics to 
`BatchStatement` and verifying the performance impact with some JMH benchmarks.

> Add BATCH metrics
> -
>
> Key: CASSANDRA-12649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12649
> Project: Cassandra
>  Issue Type: Wish
>Reporter: Alwyn Davis
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 12649-3.x.patch, stress-batch-metrics.tar.gz, 
> stress-trunk.tar.gz, trunk-12649.txt
>
>
> To identify causes of load on a cluster, it would be useful to have some 
> additional metrics:
> * *Mutation size distribution:* I believe this would be relevant when 
> tracking the performance of unlogged batches.
> * *Logged / Unlogged Partitions per batch distribution:* This would also give 
> a count of batch types processed. Multiple distinct tables in batch would 
> just be considered as separate partitions.



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

[jira] [Commented] (CASSANDRA-12649) Add BATCH metrics

[Alwyn Davis (JIRA)]

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

Alwyn Davis commented on CASSANDRA-12649:
-

Thanks for the awesome feedback! I'll try moving the metrics to 
`BatchStatement` and verifying the performance impact with some JMH benchmarks.

> Add BATCH metrics
> -
>
> Key: CASSANDRA-12649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12649
> Project: Cassandra
>  Issue Type: Wish
>Reporter: Alwyn Davis
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 12649-3.x.patch, stress-batch-metrics.tar.gz, 
> stress-trunk.tar.gz, trunk-12649.txt
>
>
> To identify causes of load on a cluster, it would be useful to have some 
> additional metrics:
> * *Mutation size distribution:* I believe this would be relevant when 
> tracking the performance of unlogged batches.
> * *Logged / Unlogged Partitions per batch distribution:* This would also give 
> a count of batch types processed. Multiple distinct tables in batch would 
> just be considered as separate partitions.



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

[jira] [Commented] (CASSANDRA-12730) Thousands of empty SSTables created during repair - TMOF death

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-12730:


Just a quick clarification, [~brstgt]: you indicated this is on 3.10 on 
29/Sep/16.
3.10 has not been released, and the first release vote for 3.10 was on Mon Oct 
31 2016 (failed on a regression). What version, exactly, is this on? If on a 
git checkout, what sha?

Thanks!

> Thousands of empty SSTables created during repair - TMOF death
> --
>
> Key: CASSANDRA-12730
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12730
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Benjamin Roth
>Priority: Critical
>
> Last night I ran a repair on a keyspace with 7 tables and 4 MVs each 
> containing a few hundret million records. After a few hours a node died 
> because of "too many open files".
> Normally one would just raise the limit, but: We already set this to 100k. 
> The problem was that the repair created roughly over 100k SSTables for a 
> certain MV. The strange thing is that these SSTables had almost no data (like 
> 53bytes, 90bytes, ...). Some of them (<5%) had a few 100 KB, very few (<1% 
> had normal sizes like >= few MB). I could understand, that SSTables queue up 
> as they are flushed and not compacted in time but then they should have at 
> least a few MB (depending on config and avail mem), right?
> Of course then the node runs out of FDs and I guess it is not a good idea to 
> raise the limit even higher as I expect that this would just create even more 
> empty SSTables before dying at last.
> Only 1 CF (MV) was affected. All other CFs (also MVs) behave sanely. Empty 
> SSTables have been created equally over time. 100-150 every minute. Among the 
> empty SSTables there are also Tables that look normal like having few MBs.
> I didn't see any errors or exceptions in the logs until TMOF occured. Just 
> tons of streams due to the repair (which I actually run over cs-reaper as 
> subrange, full repairs).
> After having restarted that node (and no more repair running), the number of 
> SSTables went down again as they are compacted away slowly.
> According to [~zznate] this issue may relate to CASSANDRA-10342 + 
> CASSANDRA-8641



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

[jira] [Updated] (CASSANDRA-12885) BatchStatement::verifyBatchSize is only called for batch without conditions

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-12885:
---
Reproduced In: 3.9, 3.0.9, 2.2.8

> BatchStatement::verifyBatchSize is only called for batch without conditions
> ---
>
> Key: CASSANDRA-12885
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12885
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Benjamin Lerer
>
> Why looking at the code, I noticed that {{BatchStatement::verifyBatchSize}} 
> is only called for batch without conditions. 



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

[jira] [Comment Edited] (CASSANDRA-12649) Add BATCH metrics

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer edited comment on CASSANDRA-12649 at 11/7/16 9:42 PM:
-

I had a discussion earlier today with [~tjake] who has more experience than me 
with Cassandra performance and Stress. It pointed out to me that we already use 
{{PartitionUpdate::dataSize}} to issue batch size warnings in 
{{BatchStatement::verifyBatchSize}}. His suggestion was to move the metric to 
{{BatchStatement}} as it will allow the patch to reuse the result of the 
existing call and avoid having the to compute the size on each replica.
The idea would be then to add that metric to your {{BatchMetrics}} instead of 
adding it to {{TableMetrics}}.

I looked at {{BatchStatement}} and it seems that the {{verifyBatchSize}} is 
only called for batch without conditions. I opened CASSANDRA-12885 to address 
that problem. If you can fix it first, it would be great :-).

Regarding your initial patch, I also have the following nits:
* {{BatchMetrics}} has a {{start}} method that does nothing and should be 
removed (including the call to it in {{StorageService}})
* Instead of making {{BatchMetrics}} a singleton you could have a public static 
variable in {{BatchStatement}} (similar to {{CQLMetrics}} in 
{{QueryProcessor}}) as it is more inline with the rest of the code.
* It would be nice if you could add the documentation for those new metrics in 
{{doc/source/operating/metrics.rts}} 




was (Author: blerer):
I had a discussion earlier today with [~tjake] who has more experience than me 
with Cassandra performance and Stress. It pointed out to me that we already use 
{{PartitionUpdate::dataSize}} to issue batch size warnings in 
{{BatchStatement::verifyBatchSize}}. His suggestion was to move the metric to 
{{BatchStatement}} as it will allow the patch to reuse the result of the 
existing call and avoid having the to compute the size on each replica.
The idea would be then to add that metric to your {{BatchMetrics}} instead of 
adding it to {{TableMetrics}}.

I looked at {{BatchStatement}} and it seems that the {{verifyBatchSize}} is 
only called for batch without conditions. I opened CASSANDRA-12885 to address 
that problem. If you can fix it first, it would be great :-).

Regarding your initial patch, I also have the following nits:
* {{BatchMetrics}} has a start method that does nothing and should be removed 
(including the call to it in StorageService)
* Instead of making {{BatchMetrics}} a singleton you could have a public static 
variable in {{BatchStatement}} (similar to {{CQLMetrics}} in 
{{QueryProcessor}}) as it is more inline with the rest of the code.
* It would be nice if you could add the documentation for those new metrics in 
{{doc/source/operating/metrics.rts}} 



> Add BATCH metrics
> -
>
> Key: CASSANDRA-12649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12649
> Project: Cassandra
>  Issue Type: Wish
>Reporter: Alwyn Davis
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 12649-3.x.patch, stress-batch-metrics.tar.gz, 
> stress-trunk.tar.gz, trunk-12649.txt
>
>
> To identify causes of load on a cluster, it would be useful to have some 
> additional metrics:
> * *Mutation size distribution:* I believe this would be relevant when 
> tracking the performance of unlogged batches.
> * *Logged / Unlogged Partitions per batch distribution:* This would also give 
> a count of batch types processed. Multiple distinct tables in batch would 
> just be considered as separate partitions.



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

[jira] [Commented] (CASSANDRA-12649) Add BATCH metrics

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-12649:


I had a discussion earlier today with [~tjake] who has more experience than me 
with Cassandra performance and Stress. It pointed out to me that we already use 
{{PartitionUpdate::dataSize}} to issue batch size warnings in 
{{BatchStatement::verifyBatchSize}}. His suggestion was to move the metric to 
{{BatchStatement}} as it will allow the patch to reuse the result of the 
existing call and avoid having the to compute the size on each replica.
The idea would be then to add that metric to your {{BatchMetrics}} instead of 
adding it to {{TableMetrics}}.

I looked at {{BatchStatement}} and it seems that the {{verifyBatchSize}} is 
only called for batch without conditions. I opened CASSANDRA-12885 to address 
that problem. If you can fix it first, it would be great :-).

Regarding your initial patch, I also have the following nits:
* {{BatchMetrics}} has a start method that does nothing and should be removed 
(including the call to it in StorageService)
* Instead of making {{BatchMetrics}} a singleton you could have a public static 
variable in {{BatchStatement}} (similar to {{CQLMetrics}} in 
{{QueryProcessor}}) as it is more inline with the rest of the code.
* It would be nice if you could add the documentation for those new metrics in 
{{doc/source/operating/metrics.rts}} 



> Add BATCH metrics
> -
>
> Key: CASSANDRA-12649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12649
> Project: Cassandra
>  Issue Type: Wish
>Reporter: Alwyn Davis
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 12649-3.x.patch, stress-batch-metrics.tar.gz, 
> stress-trunk.tar.gz, trunk-12649.txt
>
>
> To identify causes of load on a cluster, it would be useful to have some 
> additional metrics:
> * *Mutation size distribution:* I believe this would be relevant when 
> tracking the performance of unlogged batches.
> * *Logged / Unlogged Partitions per batch distribution:* This would also give 
> a count of batch types processed. Multiple distinct tables in batch would 
> just be considered as separate partitions.



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

[jira] [Updated] (CASSANDRA-12885) BatchStatement::verifyBatchSize is only called for batch without conditions

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-12885:
---
Description: Why looking at the code, I noticed that 
{{BatchStatement::verifyBatchSize}} is only called for batch without 
conditions.   (was: Why looking at the code, I noticed that {{verifyBatchSize}} 
is only called for batch without conditions. )
Summary: BatchStatement::verifyBatchSize is only called for batch 
without conditions  (was: verifyBatchSize is only called for batch without 
conditions)

> BatchStatement::verifyBatchSize is only called for batch without conditions
> ---
>
> Key: CASSANDRA-12885
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12885
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Benjamin Lerer
>
> Why looking at the code, I noticed that {{BatchStatement::verifyBatchSize}} 
> is only called for batch without conditions. 



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

[jira] [Created] (CASSANDRA-12885) verifyBatchSize is only called for batch without conditions

[Benjamin Lerer (JIRA)]

Benjamin Lerer created CASSANDRA-12885:
--

 Summary: verifyBatchSize is only called for batch without 
conditions
 Key: CASSANDRA-12885
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12885
 Project: Cassandra
  Issue Type: Bug
  Components: CQL
Reporter: Benjamin Lerer


Why looking at the code, I noticed that {{verifyBatchSize}} is only called for 
batch without conditions. 



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

[jira] [Commented] (CASSANDRA-10446) Run repair with down replicas

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-10446:
-

It seems repairedAt field is not being set on remote sync tasks, what will 
cause streamed data to be marked as repaired (see SYNC_REQUEST handling on 
RepairMessageVerbHandler). We could add a repairedAt field to SyncRequest 
message (what would break minor compatibility, so could only go on 4.0), but 
this shows a more fundamental problem with repair failure handling which is 
that if a repair session fails in the middle of sync, streamed sstables will be 
marked as repaired even if not all nodes got the data. In order to solve this 
we could stream sstables with repairedAt=0, and add them to the pool of 
sstables to be anti-compacted, so they will only be marked as repaired at the 
end of the parent repair session.

If we want to add support to -force without fixing the more fundamental problem 
with repair sync failure handling, we could mark a forced ParentRepairSession 
as !isGlobal, what would mark all streamed sstables as *not* repaired as well 
as skip anti-compaction for the whole parent repair session.

> Run repair with down replicas
> -
>
> Key: CASSANDRA-10446
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10446
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 4.0
>
>
> We should have an option of running repair when replicas are down. We can 
> call it -force.



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

[jira] [Updated] (CASSANDRA-10446) Run repair with down replicas

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-10446:

Reviewer: Paulo Motta

> Run repair with down replicas
> -
>
> Key: CASSANDRA-10446
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10446
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 4.0
>
>
> We should have an option of running repair when replicas are down. We can 
> call it -force.



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

[jira] [Comment Edited] (CASSANDRA-12676) Message coalescing regression

[T Jake Luciani (JIRA)]

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

T Jake Luciani edited comment on CASSANDRA-12676 at 11/7/16 9:13 PM:
-

Hmm actually, since this entry isn't even in the yaml so is there an issue just 
changing the (hidden) default in 3.0.x 3.x?


was (Author: tjake):
Hmm actually, since this entry isn't even in the yaml so is there an issue just 
changing the (hidden) default?

> Message coalescing regression
> -
>
> Key: CASSANDRA-12676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12676
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>  Labels: docs-impacting
> Fix For: 2.2.x, 3.0.x
>
>
> The default in 2.2+ was to enable TIMEHORIZON message coalescing.  After 
> reports of performance regressions after upgrading from 2.1 to 2.2/3.0 we 
> have discovered the issue to be this default.
> We need to re-test our assumptions on this feature but in the meantime we 
> should default back to disabled.
> Here is a performance run [with and without message 
> coalescing|http://cstar.datastax.com/graph?command=one_job=9a26b5f2-7f48-11e6-92e7-0256e416528f=op_rate=2_user=1_aggregates=true=0=508.86=0=91223]
>  



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

[jira] [Commented] (CASSANDRA-12676) Message coalescing regression

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-12676:


Hmm actually, since this entry isn't even in the yaml so is there an issue just 
changing the (hidden) default?

> Message coalescing regression
> -
>
> Key: CASSANDRA-12676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12676
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>  Labels: docs-impacting
> Fix For: 2.2.x, 3.0.x
>
>
> The default in 2.2+ was to enable TIMEHORIZON message coalescing.  After 
> reports of performance regressions after upgrading from 2.1 to 2.2/3.0 we 
> have discovered the issue to be this default.
> We need to re-test our assumptions on this feature but in the meantime we 
> should default back to disabled.
> Here is a performance run [with and without message 
> coalescing|http://cstar.datastax.com/graph?command=one_job=9a26b5f2-7f48-11e6-92e7-0256e416528f=op_rate=2_user=1_aggregates=true=0=508.86=0=91223]
>  



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

[jira] [Commented] (CASSANDRA-12676) Message coalescing regression

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-12676:


Yeah.

> Message coalescing regression
> -
>
> Key: CASSANDRA-12676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12676
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>  Labels: docs-impacting
> Fix For: 2.2.x, 3.0.x
>
>
> The default in 2.2+ was to enable TIMEHORIZON message coalescing.  After 
> reports of performance regressions after upgrading from 2.1 to 2.2/3.0 we 
> have discovered the issue to be this default.
> We need to re-test our assumptions on this feature but in the meantime we 
> should default back to disabled.
> Here is a performance run [with and without message 
> coalescing|http://cstar.datastax.com/graph?command=one_job=9a26b5f2-7f48-11e6-92e7-0256e416528f=op_rate=2_user=1_aggregates=true=0=508.86=0=91223]
>  



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

[jira] [Updated] (CASSANDRA-12676) Message coalescing regression

[Nate McCall (JIRA)]

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

Nate McCall updated CASSANDRA-12676:

Labels: docs-impacting  (was: )

> Message coalescing regression
> -
>
> Key: CASSANDRA-12676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12676
> Project: Cassandra
>  Issue Type: Bug
>Reporter: T Jake Luciani
>  Labels: docs-impacting
> Fix For: 2.2.x, 3.0.x
>
>
> The default in 2.2+ was to enable TIMEHORIZON message coalescing.  After 
> reports of performance regressions after upgrading from 2.1 to 2.2/3.0 we 
> have discovered the issue to be this default.
> We need to re-test our assumptions on this feature but in the meantime we 
> should default back to disabled.
> Here is a performance run [with and without message 
> coalescing|http://cstar.datastax.com/graph?command=one_job=9a26b5f2-7f48-11e6-92e7-0256e416528f=op_rate=2_user=1_aggregates=true=0=508.86=0=91223]
>  



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

[jira] [Updated] (CASSANDRA-11381) Node running with join_ring=false and authentication can not serve requests

[Joel Knighton (JIRA)]

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

Joel Knighton updated CASSANDRA-11381:
--
Status: Awaiting Feedback  (was: Open)

> Node running with join_ring=false and authentication can not serve requests
> ---
>
> Key: CASSANDRA-11381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11381
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
> Attachments: 11381-2.1.txt, 11381-2.2.txt, 11381-3.0.txt, 
> 11381-trunk.txt, dtest-11381-trunk.txt
>
>
> Starting up a node with {{-Dcassandra.join_ring=false}} in a cluster that has 
> authentication configured, eg PasswordAuthenticator, won't be able to serve 
> requests. This is because {{Auth.setup()}} never gets called during the 
> startup.
> Without {{Auth.setup()}} having been called in {{StorageService}} clients 
> connecting to the node fail with the node throwing
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:119)
> at 
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1471)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3505)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3489)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at 
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The exception thrown from the 
> [code|https://github.com/apache/cassandra/blob/cassandra-2.0.16/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L119]
> {code}
> ResultMessage.Rows rows = 
> authenticateStatement.execute(QueryState.forInternalCalls(), new 
> QueryOptions(consistencyForUser(username),
>   
>Lists.newArrayList(ByteBufferUtil.bytes(username;
> {code}



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

[jira] [Comment Edited] (CASSANDRA-11381) Node running with join_ring=false and authentication can not serve requests

[Joel Knighton (JIRA)]

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

Joel Knighton edited comment on CASSANDRA-11381 at 11/7/16 8:10 PM:


Thanks for pinging me on this - as you suspected, it slipped through the 
cracks. 

On reviewing the final version of this patch, I found one problem with the 2.2+ 
patches. The proposed patch technically breaks the documented {{IRoleManager}}, 
{{IAuthenticator}}, and {{IAuthorizer}} interfaces. With the implementation 
given, {{doAuthSetup}} will be called twice for a node started with 
{{join_ring=False}}, so {{setup()}} will be called twice for the role manager, 
authenticator, and authorizer. In the documentation for these three public 
interfaces, we state that {{setup()}} will only be called once after starting a 
node. I think we should preserve this documented behavior. While slightly less 
elegant, I think we should instead track whether we've run {{doAuthSetup}} and 
not repeat this call for a node started with {{join_ring=False}} that is asked 
to join. This means the parts of the patch implementing idempotency for the 
MigrationManager listener registration become unnecessary.


was (Author: jkni):
Thanks for pinging me on this - as you suspected, it slipped through the 
cracks. 

On reviewing the final version of this patch, I found one problem with the 2.2+ 
patches. The proposed patch technically breaks the documented {{IRoleManager}}, 
{{IAuthenticator}}, and {{IAuthorizer}} interfaces. With the implementation 
given, {{doAuthSetup}} will be called twice for a node started with 
{{join_ring=False}}, so {{setup()}} will be called twice for the role manager, 
authenticator, and authorizer. In the documentation for these three public 
interfaces, we state that {{setup()}} will only be called once after starting a 
node. I think we should preserve this documented behavior. While slightly less 
elegant, I think we should instead track whether we've run {{doAuthSetup}} and 
not repeat this call for a node started with {{join_ring=False}} that is asked 
to join. 

> Node running with join_ring=false and authentication can not serve requests
> ---
>
> Key: CASSANDRA-11381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11381
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
> Attachments: 11381-2.1.txt, 11381-2.2.txt, 11381-3.0.txt, 
> 11381-trunk.txt, dtest-11381-trunk.txt
>
>
> Starting up a node with {{-Dcassandra.join_ring=false}} in a cluster that has 
> authentication configured, eg PasswordAuthenticator, won't be able to serve 
> requests. This is because {{Auth.setup()}} never gets called during the 
> startup.
> Without {{Auth.setup()}} having been called in {{StorageService}} clients 
> connecting to the node fail with the node throwing
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:119)
> at 
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1471)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3505)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3489)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at 
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The exception thrown from the 
> [code|https://github.com/apache/cassandra/blob/cassandra-2.0.16/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L119]
> {code}
> ResultMessage.Rows rows = 
> authenticateStatement.execute(QueryState.forInternalCalls(), new 
> QueryOptions(consistencyForUser(username),
>   
>Lists.newArrayList(ByteBufferUtil.bytes(username;
> {code}



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

[jira] [Updated] (CASSANDRA-11381) Node running with join_ring=false and authentication can not serve requests

[Joel Knighton (JIRA)]

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

Joel Knighton updated CASSANDRA-11381:
--
Status: Open  (was: Patch Available)

> Node running with join_ring=false and authentication can not serve requests
> ---
>
> Key: CASSANDRA-11381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11381
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
> Attachments: 11381-2.1.txt, 11381-2.2.txt, 11381-3.0.txt, 
> 11381-trunk.txt, dtest-11381-trunk.txt
>
>
> Starting up a node with {{-Dcassandra.join_ring=false}} in a cluster that has 
> authentication configured, eg PasswordAuthenticator, won't be able to serve 
> requests. This is because {{Auth.setup()}} never gets called during the 
> startup.
> Without {{Auth.setup()}} having been called in {{StorageService}} clients 
> connecting to the node fail with the node throwing
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:119)
> at 
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1471)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3505)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3489)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at 
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The exception thrown from the 
> [code|https://github.com/apache/cassandra/blob/cassandra-2.0.16/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L119]
> {code}
> ResultMessage.Rows rows = 
> authenticateStatement.execute(QueryState.forInternalCalls(), new 
> QueryOptions(consistencyForUser(username),
>   
>Lists.newArrayList(ByteBufferUtil.bytes(username;
> {code}



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

[jira] [Commented] (CASSANDRA-11381) Node running with join_ring=false and authentication can not serve requests

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-11381:
---

Thanks for pinging me on this - as you suspected, it slipped through the 
cracks. 

On reviewing the final version of this patch, I found one problem with the 2.2+ 
patches. The proposed patch technically breaks the documented {{IRoleManager}}, 
{{IAuthenticator}}, and {{IAuthorizer}} interfaces. With the implementation 
given, {{doAuthSetup}} will be called twice for a node started with 
{{join_ring=False}}, so {{setup()}} will be called twice for the role manager, 
authenticator, and authorizer. In the documentation for these three public 
interfaces, we state that {{setup()}} will only be called once after starting a 
node. I think we should preserve this documented behavior. While slightly less 
elegant, I think we should instead track whether we've run {{doAuthSetup}} and 
not repeat this call for a node started with {{join_ring=False}} that is asked 
to join. 

> Node running with join_ring=false and authentication can not serve requests
> ---
>
> Key: CASSANDRA-11381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11381
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
> Attachments: 11381-2.1.txt, 11381-2.2.txt, 11381-3.0.txt, 
> 11381-trunk.txt, dtest-11381-trunk.txt
>
>
> Starting up a node with {{-Dcassandra.join_ring=false}} in a cluster that has 
> authentication configured, eg PasswordAuthenticator, won't be able to serve 
> requests. This is because {{Auth.setup()}} never gets called during the 
> startup.
> Without {{Auth.setup()}} having been called in {{StorageService}} clients 
> connecting to the node fail with the node throwing
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:119)
> at 
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1471)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3505)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3489)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at 
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The exception thrown from the 
> [code|https://github.com/apache/cassandra/blob/cassandra-2.0.16/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L119]
> {code}
> ResultMessage.Rows rows = 
> authenticateStatement.execute(QueryState.forInternalCalls(), new 
> QueryOptions(consistencyForUser(username),
>   
>Lists.newArrayList(ByteBufferUtil.bytes(username;
> {code}



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

[jira] [Updated] (CASSANDRA-12695) Truncate ALWAYS not applied

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-12695:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

committed in {{d582d034083d4e39d2206739984369d38518696a}} Thx!

> Truncate ALWAYS not applied
> ---
>
> Key: CASSANDRA-12695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12695
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alwyn Davis
>Assignee: Alwyn Davis
>Priority: Trivial
>  Labels: stress
> Fix For: 3.x
>
> Attachments: 12695-trunk-v2.patch, 12695-trunk.patch
>
>
> If truncate is set to ALWAYS and rate sets a specific thread count, the 
> stress table is not actually truncated. E.g.
> {code}
> truncate=always -rate threads=4
> {code}
> This can cause an unexpected number of rows to be left in the table.



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

[jira] [Updated] (CASSANDRA-12695) Truncate ALWAYS not applied

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-12695:
---
Assignee: Alwyn Davis

> Truncate ALWAYS not applied
> ---
>
> Key: CASSANDRA-12695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12695
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alwyn Davis
>Assignee: Alwyn Davis
>Priority: Trivial
>  Labels: stress
> Fix For: 3.10
>
> Attachments: 12695-trunk-v2.patch, 12695-trunk.patch
>
>
> If truncate is set to ALWAYS and rate sets a specific thread count, the 
> stress table is not actually truncated. E.g.
> {code}
> truncate=always -rate threads=4
> {code}
> This can cause an unexpected number of rows to be left in the table.



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

[jira] [Updated] (CASSANDRA-12695) Truncate ALWAYS not applied

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-12695:
---
Fix Version/s: (was: 3.x)
   3.10

> Truncate ALWAYS not applied
> ---
>
> Key: CASSANDRA-12695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12695
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alwyn Davis
>Assignee: Alwyn Davis
>Priority: Trivial
>  Labels: stress
> Fix For: 3.10
>
> Attachments: 12695-trunk-v2.patch, 12695-trunk.patch
>
>
> If truncate is set to ALWAYS and rate sets a specific thread count, the 
> stress table is not actually truncated. E.g.
> {code}
> truncate=always -rate threads=4
> {code}
> This can cause an unexpected number of rows to be left in the table.



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

[jira] [Commented] (CASSANDRA-12535) Occasionally seeing AccessControlException, CodecNotFoundException when executing a User Defined Aggregate

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-12535:


Maybe if we retry the function if we get a {{SecurityException}} would be the 
best course of action for this. It seems like this is a low enough occurrence 
that if we haven't had any UDF failures, retrying won't add significant 
overhead; if we have had recent failures (which might point to a bad UDF), then 
we could fail right away.

If that doesn't seem feasible, I think we should commit this patch, as it will 
suppress the biggest source of {{SecurityException}}s. I'm +1 on the code 
changes here.

> Occasionally seeing AccessControlException, CodecNotFoundException when 
> executing a User Defined Aggregate
> --
>
> Key: CASSANDRA-12535
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12535
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.7 (via brew install), Mac OS X 10.11.6
>Reporter: Pat Patterson
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> I have defined a UDA to implement standard deviation:
> {noformat}
> cqlsh:mykeyspace> CREATE OR REPLACE FUNCTION sdState ( state 
> tuple, val double ) CALLED ON NULL INPUT RETURNS 
> tuple LANGUAGE java AS 
>  ... 'int n = state.getInt(0); double mean = state.getDouble(1); double m2 = 
> state.getDouble(2); n++; double delta = val - mean; mean += delta / n; m2 += 
> delta * (val - mean); state.setInt(0, n); state.setDouble(1, mean); 
> state.setDouble(2, m2); return state;'; 
> cqlsh:mykeyspace> CREATE OR REPLACE FUNCTION sdFinal ( state 
> tuple ) CALLED ON NULL INPUT RETURNS double LANGUAGE java 
> AS 
>  ... 'int n = state.getInt(0); double m2 = state.getDouble(2); if (n < 1) { 
> return null; } return Math.sqrt(m2 / (n - 1));';
> cqlsh:mykeyspace> CREATE AGGREGATE IF NOT EXISTS stdev ( double ) 
>  ... SFUNC sdState STYPE tuple FINALFUNC sdFinal INITCOND 
> (0,0,0);
> {noformat}
> My table:
> {noformat}
> CREATE TABLE readings (
> sensor_id int,
> time timestamp,
> temperature double,
> status text,
> PRIMARY KEY (sensor_id, time)
> ) WITH CLUSTERING ORDER BY (time ASC);
> {noformat}
> I'm inserting a row every 0.1 seconds. The data looks like this:
> {noformat}
> cqlsh:mykeyspace> select * from readings limit 10;
>  sensor_id | time| status | temperature
> ---+-++-
>  5 | 2016-08-24 19:11:34.896000+ | OK |9.97
>  5 | 2016-08-24 19:11:43.933000+ | OK |   10.28
>  5 | 2016-08-24 19:11:49.958000+ | OK |7.65
>  5 | 2016-08-24 19:11:51.968000+ | OK |   10.11
>  5 | 2016-08-24 19:12:58.512000+ |  Fault |   10.41
>  5 | 2016-08-24 19:13:04.542000+ | OK |9.66
>  5 | 2016-08-24 19:13:16.593000+ | OK |10.9
>  5 | 2016-08-24 19:13:37.692000+ | OK |11.2
>  5 | 2016-08-24 19:13:46.738000+ | OK |   10.34
>  5 | 2016-08-24 19:13:49.757000+ | OK |10.6
> {noformat}
> I'm running a query every few seconds with my UDA - like this (timestamps are 
> different each time):
> {noformat}
> select avg(temperature), stdev(temperature) from readings where sensor_id = 1 
> and time > 1472066523193;
> {noformat}
> Most of the time, this works just fine:
> {noformat}
> cqlsh:mykeyspace> select avg(temperature), stdev(temperature) from readings 
> where sensor_id = 1 and time > 1472066523193;
>  system.avg(temperature) | mykeyspace.stdev(temperature)
> -+---
>   9.9291 |   0.94179
> (1 rows)
> {noformat}
> But, occasionally, it fails with one of two exceptions:
> {noformat}
> cqlsh:mykeyspace> select avg(temperature), stdev(temperature) from readings 
> where sensor_id = 1 and time > 1472066523193;
> Traceback (most recent call last):
>   File "/usr/local/Cellar/cassandra/3.7/libexec/bin/cqlsh.py", line 1277, in 
> perform_simple_statement
> result = future.result()
>   File "cassandra/cluster.py", line 3629, in 
> cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69369)
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure] 
> message="execution of 'mykeyspace.sdstate[frozen>, 
> double]' failed: java.security.AccessControlException: access denied 
> ("java.io.FilePermission" 

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

[jake]

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

Branch: refs/heads/trunk
Commit: 459946aeef05e2a5a0db7b61b48861eb54958b08
Parents: c47d395 d582d03
Author: T Jake Luciani 
Authored: Mon Nov 7 14:10:15 2016 -0500
Committer: T Jake Luciani 
Committed: Mon Nov 7 14:10:15 2016 -0500

--
 CHANGES.txt| 1 +
 tools/stress/src/org/apache/cassandra/stress/StressAction.java | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/459946ae/CHANGES.txt
--
diff --cc CHANGES.txt
index bbe79e6,bdb6e29..21f179f
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,12 -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)
 +
 +
  3.10
+  * Fix cassandra-stress truncate option (CASSANDRA-12695)
   * Fix crossNode value when receiving messages (CASSANDRA-12791)
   * Don't load MX4J beans twice (CASSANDRA-12869)
   * Extend native protocol request flags, add versions to SUPPORTED, and 
introduce ProtocolVersion enum (CASSANDRA-12838)

[1/3] cassandra git commit: Fix cassandra-stress truncate option

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.X 2b4567313 -> d582d0340
  refs/heads/trunk c47d395d8 -> 459946aee


Fix cassandra-stress truncate option

Patch by Alwyn Davis; reviewed by tjake for CASSANDRA-12695


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

Branch: refs/heads/cassandra-3.X
Commit: d582d034083d4e39d2206739984369d38518696a
Parents: 2b45673
Author: Alwyn 
Authored: Fri Sep 23 16:12:13 2016 +1000
Committer: T Jake Luciani 
Committed: Mon Nov 7 14:09:06 2016 -0500

--
 CHANGES.txt| 1 +
 tools/stress/src/org/apache/cassandra/stress/StressAction.java | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d582d034/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1123553..bdb6e29 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Fix cassandra-stress truncate option (CASSANDRA-12695)
  * Fix crossNode value when receiving messages (CASSANDRA-12791)
  * Don't load MX4J beans twice (CASSANDRA-12869)
  * Extend native protocol request flags, add versions to SUPPORTED, and 
introduce ProtocolVersion enum (CASSANDRA-12838)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d582d034/tools/stress/src/org/apache/cassandra/stress/StressAction.java
--
diff --git a/tools/stress/src/org/apache/cassandra/stress/StressAction.java 
b/tools/stress/src/org/apache/cassandra/stress/StressAction.java
index eaee752..30f8899 100644
--- a/tools/stress/src/org/apache/cassandra/stress/StressAction.java
+++ b/tools/stress/src/org/apache/cassandra/stress/StressAction.java
@@ -62,7 +62,8 @@ public class StressAction implements Runnable
 if (!settings.command.noWarmup)
 warmup(settings.command.getFactory(settings));
 
-if (settings.command.truncate == SettingsCommand.TruncateWhen.ONCE)
+if ((settings.command.truncate == SettingsCommand.TruncateWhen.ONCE) ||
+((settings.rate.threadCount != -1) && (settings.command.truncate 
== SettingsCommand.TruncateWhen.ALWAYS)))
 settings.command.truncateTables(settings);
 
 // Required for creating a graph from the output file

[2/3] cassandra git commit: Fix cassandra-stress truncate option

[jake]

Fix cassandra-stress truncate option

Patch by Alwyn Davis; reviewed by tjake for CASSANDRA-12695


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

Branch: refs/heads/trunk
Commit: d582d034083d4e39d2206739984369d38518696a
Parents: 2b45673
Author: Alwyn 
Authored: Fri Sep 23 16:12:13 2016 +1000
Committer: T Jake Luciani 
Committed: Mon Nov 7 14:09:06 2016 -0500

--
 CHANGES.txt| 1 +
 tools/stress/src/org/apache/cassandra/stress/StressAction.java | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d582d034/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1123553..bdb6e29 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * Fix cassandra-stress truncate option (CASSANDRA-12695)
  * Fix crossNode value when receiving messages (CASSANDRA-12791)
  * Don't load MX4J beans twice (CASSANDRA-12869)
  * Extend native protocol request flags, add versions to SUPPORTED, and 
introduce ProtocolVersion enum (CASSANDRA-12838)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d582d034/tools/stress/src/org/apache/cassandra/stress/StressAction.java
--
diff --git a/tools/stress/src/org/apache/cassandra/stress/StressAction.java 
b/tools/stress/src/org/apache/cassandra/stress/StressAction.java
index eaee752..30f8899 100644
--- a/tools/stress/src/org/apache/cassandra/stress/StressAction.java
+++ b/tools/stress/src/org/apache/cassandra/stress/StressAction.java
@@ -62,7 +62,8 @@ public class StressAction implements Runnable
 if (!settings.command.noWarmup)
 warmup(settings.command.getFactory(settings));
 
-if (settings.command.truncate == SettingsCommand.TruncateWhen.ONCE)
+if ((settings.command.truncate == SettingsCommand.TruncateWhen.ONCE) ||
+((settings.rate.threadCount != -1) && (settings.command.truncate 
== SettingsCommand.TruncateWhen.ALWAYS)))
 settings.command.truncateTables(settings);
 
 // Required for creating a graph from the output file

[Cassandra Wiki] Update of "ContributorsGroup" by MichaelShuler

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "ContributorsGroup" page has been changed by MichaelShuler:
https://wiki.apache.org/cassandra/ContributorsGroup?action=diff=64=65

   * thepaul
   * TylerHobbs
   * Victor Lownes
+  * winguzone
   * yukim
   * zznate
  
- 

[Cassandra Wiki] Update of "AdminGroup" by BrandonWilliams

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "AdminGroup" page has been changed by BrandonWilliams:
https://wiki.apache.org/cassandra/AdminGroup?action=diff=8=9

   * JonathanEllis
   * BrandonWilliams
   * jeremyhanna
+  * MichaelShuler
  
- 

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

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian updated CASSANDRA-12443:
---
Fix Version/s: (was: 3.0.x)
   3.x
   Status: Patch Available  (was: Open)

There was a failure from the UDT changes; the rest seem more related to the 
fact that this hasn't been rebased in awhile. In order to seperate that out, 
I've added the commit fixing the test onto the branches above, but pushed new 
branches which have been rebased to test:

||3.x|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12443/3.x-1]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-3.x-1-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-3.x-1-dtest/]|
||trunk|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12443/trunk-1]|[utest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-trunk-1-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/carlyeks/job/carlyeks-ticket-12443-trunk-1-dtest/]|

> 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.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-11995) Commitlog replaced with all NULs

[Jose Garcia (JIRA)]

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

Jose Garcia commented on CASSANDRA-11995:
-

Mine is running on Ubuntu. What I found was that the specific node had a bad 
memory stick. The machine in question was crashing constantly, every few hours. 
I think when the crash happens at the wrong moment, there is a log being 
created and initialized with NULL characters, or probably just allocated to be 
sure it gets enough space. When the crash happens at that time, the log stays 
allocated with NULL characters and that prevents the cassandra node from 
starting, as its format is incorrect. I think what is needed after reboot is to 
check for that condition and realize the failire and roll it back. and restart.

In our specific case, we replaced the memory stick, the machine stopped 
crashing and I've never seen the error again. Probably the condition is rare 
and only happens during bad timing of a crash, but loosing power on a large 
cluster would make such condition appear with some frequency. 

> Commitlog replaced with all NULs
> 
>
> Key: CASSANDRA-11995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11995
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Windows 10 Enterprise 1511
> DataStax Cassandra Community Server 2.2.3
>Reporter: James Howe
>
> I noticed this morning that Cassandra was failing to start, after being shut 
> down on Friday.
> {code}
> ERROR 09:13:37 Exiting due to error while processing commit log during 
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
> Could not read commit log descriptor in file C:\Program Files\DataStax 
> Community\data\commitlog\CommitLog-5-1465571056722.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
> [apache-cassandra-2.2.3.jar:2.2.3]
> {code}
> Checking the referenced file reveals it comprises 33,554,432 (32 * 1024 * 
> 1024) NUL bytes.
> No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
> appear exactly as normal.
> Is installed as a service via DataStax's distribution.



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

[jira] [Commented] (CASSANDRA-12796) Heap exhaustion when rebuilding secondary index over a table with wide partitions

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-12796:
-

b.q. I would like to know if this patch can be brought into Cassandra 3.0.x or 
are there other solutions to deal with large partitions with secondary indexes?

There aren't I'm afraid, so if you could post your patches for 2.2 & 3.0 I'll 
make sure they get reviewed (I shouldn't think a separate patch for trunk will 
be necessary).
Thanks.

> Heap exhaustion when rebuilding secondary index over a table with wide 
> partitions
> -
>
> Key: CASSANDRA-12796
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12796
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Milan Majercik
>Priority: Critical
>
> We have a table with rather wide partition and a secondary index defined over 
> it. As soon as we try to rebuild the index we observed exhaustion of Java 
> heap and eventual OOM error. After a lengthy investigation we have managed to 
> find a culprit which appears to be a wrong granule of barrier issuances in 
> method {{org.apache.cassandra.db.Keyspace.indexRow}}:
> {code}
> try (OpOrder.Group opGroup = cfs.keyspace.writeOrder.start()){html}
> {
> Set indexes = 
> cfs.indexManager.getIndexesByNames(idxNames);
> Iterator pager = QueryPagers.pageRowLocally(cfs, 
> key.getKey(), DEFAULT_PAGE_SIZE);
> while (pager.hasNext())
> {
> ColumnFamily cf = pager.next();
> ColumnFamily cf2 = cf.cloneMeShallow();
> for (Cell cell : cf)
> {
> if (cfs.indexManager.indexes(cell.name(), indexes))
> cf2.addColumn(cell);
> }
> cfs.indexManager.indexRow(key.getKey(), cf2, opGroup);
> }
> }
> {code}
> Please note the operation group granule is a partition of the source table 
> which poses a problem for wide partition tables as flush runnable 
> ({{org.apache.cassandra.db.ColumnFamilyStore.Flush.run()}}) won't proceed 
> with flushing secondary index memtable before completing operations prior 
> recent issue of the barrier. In our situation the flush runnable waits until 
> whole wide partition gets indexed into the secondary index memtable before 
> flushing it. This causes an exhaustion of the heap and eventual OOM error.
> After we changed granule of barrier issue in method 
> {{org.apache.cassandra.db.Keyspace.indexRow}} to query page as opposed to 
> table partition secondary index (see 
> [https://github.com/mmajercik/cassandra/commit/7e10e5aa97f1de483c2a5faf867315ecbf65f3d6?diff=unified]),
>  rebuild started to work without heap exhaustion. 



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

[jira] [Commented] (CASSANDRA-11995) Commitlog replaced with all NULs

[John Marsten (JIRA)]

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

John Marsten commented on CASSANDRA-11995:
--

I'm not too familiar with the Cassandra code base, but it looks like the 
CommitLogSegment.createSegment() method returns an instance that has had the 
log header written, but not synced. So until a sync is triggered (periodic, 
batch, or graceful shutdown), the segment file is left in a corrupt state 
because it has no header on disk. If I'm right about this, I'd suggest making 
CommitLogSegment.createSegment() call sync() on the new segment before 
returning it.

> Commitlog replaced with all NULs
> 
>
> Key: CASSANDRA-11995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11995
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Windows 10 Enterprise 1511
> DataStax Cassandra Community Server 2.2.3
>Reporter: James Howe
>
> I noticed this morning that Cassandra was failing to start, after being shut 
> down on Friday.
> {code}
> ERROR 09:13:37 Exiting due to error while processing commit log during 
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
> Could not read commit log descriptor in file C:\Program Files\DataStax 
> Community\data\commitlog\CommitLog-5-1465571056722.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
> [apache-cassandra-2.2.3.jar:2.2.3]
> {code}
> Checking the referenced file reveals it comprises 33,554,432 (32 * 1024 * 
> 1024) NUL bytes.
> No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
> appear exactly as normal.
> Is installed as a service via DataStax's distribution.



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

[jira] [Commented] (CASSANDRA-12652) Failure in SASIIndexTest.testStaticIndex-compression

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-12652:
-

My assumption was as follows: since this is a "compression" run, there are some 
sstable leftovers from the previous (non-compression) run. One run creates 2 
sstables, second run creates 2 sstables. Since “low” threshold of STCS is 4, we 
trigger a compaction. After comaction, index rebuild is asynchronous, so index 
might be empty, since there are no sasi memtables… So there’re three scenarios: 
one when we’ve flushed the index, one where we haven’t and one where we're 
still reading the old sstables. One of them (unflushed index) would fail.

I've tried running tests, where I would insert same data 2 more times (to 
create a total of 4 sstables) and "emulate" the long flush for the static cf 
(by adding a sleep when creating a 5th index for the {{static_sasi_test_cf}}). 
The test results are as expected:

{code}
junit.framework.AssertionFailedError: 
Expected :1
Actual   :0
{code}

Having that said, we might want to create another issue that would take care of 
making sure that SASI indexes are served correctly for the compacted tables..

> Failure in SASIIndexTest.testStaticIndex-compression
> 
>
> Key: CASSANDRA-12652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12652
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Alex Petrov
> Fix For: 3.x, 4.x
>
>
> Stacktrace:
> {code}
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
>   at 
> org.apache.cassandra.index.sasi.SASIIndexTest.testStaticIndex(SASIIndexTest.java:1839)
>   at 
> org.apache.cassandra.index.sasi.SASIIndexTest.testStaticIndex(SASIIndexTest.java:1786)
> {code}
> Example failure:
> http://cassci.datastax.com/job/trunk_testall/1176/testReport/org.apache.cassandra.index.sasi/SASIIndexTest/testStaticIndex_compression/



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

[jira] [Updated] (CASSANDRA-11995) Commitlog replaced with all NULs

[James Howe (JIRA)]

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

James Howe updated CASSANDRA-11995:
---
Description: 
I noticed this morning that Cassandra was failing to start, after being shut 
down on Friday.
{code}
ERROR 09:13:37 Exiting due to error while processing commit log during 
initialization.
org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
Could not read commit log descriptor in file C:\Program Files\DataStax 
Community\data\commitlog\CommitLog-5-1465571056722.log
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
[apache-cassandra-2.2.3.jar:2.2.3]
{code}
Checking the referenced file reveals it comprises 33,554,432 (32 * 1024 * 1024) 
NUL bytes.
No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
appear exactly as normal.
Is installed as a service via DataStax's distribution.

  was:
I noticed this morning that Cassandra was failing to start, after being shut 
down on Friday.
{code}
ERROR 09:13:37 Exiting due to error while processing commit log during 
initialization.
org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
Could not read commit log descriptor in file C:\Program Files\DataStax 
Community\data\commitlog\CommitLog-5-1465571056722.log
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
[apache-cassandra-2.2.3.jar:2.2.3]
{code}
Checking the referenced file reveals it comprises 33,554,432 NUL bytes.
No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
appear exactly as normal.
Is installed as a service via DataStax's distribution.


> Commitlog replaced with all NULs
> 
>
> Key: CASSANDRA-11995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11995
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Windows 10 Enterprise 1511
> DataStax Cassandra Community Server 2.2.3
>Reporter: James Howe
>
> I noticed this morning that Cassandra was failing to start, after being shut 
> down on Friday.
> {code}
> ERROR 09:13:37 Exiting due to error while processing commit log during 
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
> Could not read commit log descriptor in file C:\Program Files\DataStax 
> Community\data\commitlog\CommitLog-5-1465571056722.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> 

[jira] [Commented] (CASSANDRA-11995) Commitlog replaced with all NULs

[John Marsten (JIRA)]

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

John Marsten commented on CASSANDRA-11995:
--

We observed this phenomenon running Apache Cassandra 3.8 on Windows Server 2012 
VM. The precise history and state of the VM in question was unclear, but 
apparently the administrators took a live snapshot, and after reverting to the 
snapshot, Cassandra would no longer start due to the error above. In this case, 
the commit log file was 48MB of NUL bytes. The Cassandra system log showed an 
ungraceful termination and a handful of warnings related to slow commit log 
syncs, but no errors prior to the CommitLogReplayException on subsequent 
startups.

Cassandra was configured for batch mode commit log syncing with a window size 
of 50ms. It's not clear whether the system was writing to Cassandra at the time 
of the snapshot.

> Commitlog replaced with all NULs
> 
>
> Key: CASSANDRA-11995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11995
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Windows 10 Enterprise 1511
> DataStax Cassandra Community Server 2.2.3
>Reporter: James Howe
>
> I noticed this morning that Cassandra was failing to start, after being shut 
> down on Friday.
> {code}
> ERROR 09:13:37 Exiting due to error while processing commit log during 
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
> Could not read commit log descriptor in file C:\Program Files\DataStax 
> Community\data\commitlog\CommitLog-5-1465571056722.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
> [apache-cassandra-2.2.3.jar:2.2.3]
> {code}
> Checking the referenced file reveals it comprises 33,554,432 NUL bytes.
> No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
> appear exactly as normal.
> Is installed as a service via DataStax's distribution.



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

[jira] [Updated] (CASSANDRA-12884) Batch logic can lead to unbalanced use of system.batches

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-12884:
--
Fix Version/s: 3.x
   3.0.x

> Batch logic can lead to unbalanced use of system.batches
> 
>
> Key: CASSANDRA-12884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12884
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Adam Hattrell
>Assignee: Aleksey Yeschenko
> Fix For: 3.0.x, 3.x
>
>
> It looks as though there are some odd edge cases in how we distribute the 
> copies in system.batches.
> The main issue is in the filter method for 
> org.apache.cassandra.batchlog.BatchlogManager
> {code:java}
>  if (validated.size() - validated.get(localRack).size() >= 2)
>  {
> // we have enough endpoints in other racks
> validated.removeAll(localRack);
>   }
>  if (validated.keySet().size() == 1)
>  {
>// we have only 1 `other` rack
>Collection otherRack = 
> Iterables.getOnlyElement(validated.asMap().values());
>
> return Lists.newArrayList(Iterables.limit(otherRack, 2));
>  }
> {code}
> So with one or two racks we just return the first 2 entries in the list.  
> There's no shuffle or randomisation here.



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

[jira] [Assigned] (CASSANDRA-12884) Batch logic can lead to unbalanced use of system.batches

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko reassigned CASSANDRA-12884:
-

Assignee: Aleksey Yeschenko

> Batch logic can lead to unbalanced use of system.batches
> 
>
> Key: CASSANDRA-12884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12884
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Adam Hattrell
>Assignee: Aleksey Yeschenko
>
> It looks as though there are some odd edge cases in how we distribute the 
> copies in system.batches.
> The main issue is in the filter method for 
> org.apache.cassandra.batchlog.BatchlogManager
> {code:java}
>  if (validated.size() - validated.get(localRack).size() >= 2)
>  {
> // we have enough endpoints in other racks
> validated.removeAll(localRack);
>   }
>  if (validated.keySet().size() == 1)
>  {
>// we have only 1 `other` rack
>Collection otherRack = 
> Iterables.getOnlyElement(validated.asMap().values());
>
> return Lists.newArrayList(Iterables.limit(otherRack, 2));
>  }
> {code}
> So with one or two racks we just return the first 2 entries in the list.  
> There's no shuffle or randomisation here.



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

[jira] [Commented] (CASSANDRA-12281) Gossip blocks on startup when another node is bootstrapping

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-12281:
---

Ah, good catch on the aggregate log message spanning the trace and debug cases. 
That makes a lot of sense - thanks for the explanation. I'll keep this at the 
top of my queue for when CI is available.

> Gossip blocks on startup when another node is bootstrapping
> ---
>
> Key: CASSANDRA-12281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12281
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Eric Evans
>Assignee: Stefan Podkowinski
> Attachments: 12281-2.2.patch, 12281-3.0.patch, 12281-trunk.patch, 
> restbase1015-a_jstack.txt
>
>
> In our cluster, normal node startup times (after a drain on shutdown) are 
> less than 1 minute.  However, when another node in the cluster is 
> bootstrapping, the same node startup takes nearly 30 minutes to complete, the 
> apparent result of gossip blocking on pending range calculations.
> {noformat}
> $ nodetool-a tpstats
> Pool NameActive   Pending  Completed   Blocked  All 
> time blocked
> MutationStage 0 0   1840 0
>  0
> ReadStage 0 0   2350 0
>  0
> RequestResponseStage  0 0 53 0
>  0
> ReadRepairStage   0 0  1 0
>  0
> CounterMutationStage  0 0  0 0
>  0
> HintedHandoff 0 0 44 0
>  0
> MiscStage 0 0  0 0
>  0
> CompactionExecutor3 3395 0
>  0
> MemtableReclaimMemory 0 0 30 0
>  0
> PendingRangeCalculator1 2 29 0
>  0
> GossipStage   1  5602164 0
>  0
> MigrationStage0 0  0 0
>  0
> MemtablePostFlush 0 0111 0
>  0
> ValidationExecutor0 0  0 0
>  0
> Sampler   0 0  0 0
>  0
> MemtableFlushWriter   0 0 30 0
>  0
> InternalResponseStage 0 0  0 0
>  0
> AntiEntropyStage  0 0  0 0
>  0
> CacheCleanupExecutor  0 0  0 0
>  0
> Message type   Dropped
> READ 0
> RANGE_SLICE  0
> _TRACE   0
> MUTATION 0
> COUNTER_MUTATION 0
> REQUEST_RESPONSE 0
> PAGED_RANGE  0
> READ_REPAIR  0
> {noformat}
> A full thread dump is attached, but the relevant bit seems to be here:
> {noformat}
> [ ... ]
> "GossipStage:1" #1801 daemon prio=5 os_prio=0 tid=0x7fe4cd54b000 
> nid=0xea9 waiting on condition [0x7fddcf883000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x0004c1e922c0> (a 
> java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
>   at 
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
>   at 
> org.apache.cassandra.locator.TokenMetadata.updateNormalTokens(TokenMetadata.java:174)
>   at 
> org.apache.cassandra.locator.TokenMetadata.updateNormalTokens(TokenMetadata.java:160)
>   at 
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2023)
>   at 
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1682)
>   at 
> org.apache.cassandra.gms.Gossiper.doOnChangeNotifications(Gossiper.java:1182)
>   at 

[jira] [Created] (CASSANDRA-12884) Batch logic can lead to unbalanced use of system.batches

[Adam Hattrell (JIRA)]

Adam Hattrell created CASSANDRA-12884:
-

 Summary: Batch logic can lead to unbalanced use of system.batches
 Key: CASSANDRA-12884
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12884
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Adam Hattrell


It looks as though there are some odd edge cases in how we distribute the 
copies in system.batches.

The main issue is in the filter method for 
org.apache.cassandra.batchlog.BatchlogManager

{code:java}
 if (validated.size() - validated.get(localRack).size() >= 2)
 {
// we have enough endpoints in other racks
validated.removeAll(localRack);
  }

 if (validated.keySet().size() == 1)
 {
   // we have only 1 `other` rack
   Collection otherRack = 
Iterables.getOnlyElement(validated.asMap().values());
   
return Lists.newArrayList(Iterables.limit(otherRack, 2));
 }
{code}

So with one or two racks we just return the first 2 entries in the list.  
There's no shuffle or randomisation here.



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

[jira] [Commented] (CASSANDRA-11865) Improve compaction logging details

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-11865:


[~weideng]: This ticket is focused on adding new content to the 
{{compaction.log}}, not necessarily focused on the current debug logging.

Some of this data is already available, like the merge statistics, and most of 
the other data can be obtained using the {{MergeListener}}. For example, 
figuring out the number of merged CQL rows, as well as the merged tombstones.

The wide partition detection is done inside of {{BigTableWriter}}, so that will 
be more difficult to pull out, but we could probably get the same thing from 
going through {{CompactionAwareWriter}} instead of the {{BigTableWriter}}.

Metrics we already collect
* Partitions Processed: {{totalKeysWritten}} in {{CompactionTask}}
* Partition Merge Stats: {{mergedRowCounts}} in {{CompactionTask}}
* Partition Size: {{mean}} in {{StatsMetadata}} from the output SSTables

Metrics we need to collect
* Adding in {{MergeListener}} in {{CompactionIterator}}
** Rows Processed
** Rows Merged
** Row count min/max/avg per partition
** Cells Requiring Merge
** Number of Tombstones Encountered
* {{BigTableWriter}}/{{CompactionAwareWriter}}
** Wide row

> Improve compaction logging details
> --
>
> Key: CASSANDRA-11865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11865
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Compaction
>Reporter: T Jake Luciani
>Assignee: Carl Yeksigian
>
> I'd like to see per compaction entry:
>   * Partitions processed
>   * Rows processed
>   * Partition merge stats
>   * If a wide row was detected
>   * The partition min/max/avg size
>   * The min/max/avg row count across partitions
> Anything else [~krummas]?



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

[jira] [Updated] (CASSANDRA-12867) Batch with multiple conditional updates for the same partition causes AssertionError

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-12867:
-
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

Committed, thanks.

> Batch with multiple conditional updates for the same partition causes 
> AssertionError
> 
>
> Key: CASSANDRA-12867
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12867
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Kurt Greaves
>Assignee: Sylvain Lebresne
>Priority: Critical
> Fix For: 3.0.10, 3.10
>
> Attachments: 12867-3.0.patch
>
>
> Reproduced in 3.0.10 and 3.10. Used to work in 3.0.9 and earlier. Bug was 
> introduced in CASSANDRA-12060.
> The following causes an AssertionError:
> {code}
> CREATE KEYSPACE test WITH replication = { 'class' : 'SimpleStrategy', 
> 'replication_factor' : 1 };
> create table test.test (id int PRIMARY KEY, val text);
> BEGIN BATCH INSERT INTO test.test (id, val) VALUES (999, 'aaa') IF NOT 
> EXISTS; INSERT INTO test.test (id, val) VALUES (999, 'ccc') IF NOT EXISTS; 
> APPLY BATCH ;
> {code}
> Stack trace is as follows:
> {code}
> ERROR [Native-Transport-Requests-2] 2016-10-31 04:16:44,231 Message.java:622 
> - Unexpected exception during request; channel = [id: 0x176e1c04, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:59743]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.setConditionsForRow(CQL3CasRequest.java:138)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.addExistsCondition(CQL3CasRequest.java:104)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.addNotExist(CQL3CasRequest.java:84)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.IfNotExistsCondition.addConditionsTo(IfNotExistsCondition.java:28)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.addConditions(ModificationStatement.java:482)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.makeCasRequest(BatchStatement.java:434)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.executeWithConditions(BatchStatement.java:379)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:358)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:346)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:341)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:218)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:249) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:234) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:516)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:409)
>  [main/:na]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_102]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [main/:na]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102]
> {code}
> The problem is that previous will receive a value after the first statement 
> in the batch is evaluated in BatchStatement.makeCasRequest. I can't see any 
> reason why we have this assertion, it seems to me that it's unnecessary.
> Removing it fixes the problem (obviously) but I'm not sure if it breaks 
> something else, or if this is an intended failure case (in which case it 
> should be 

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

[slebresne]

Merge branch 'cassandra-3.X' into trunk

* cassandra-3.X:
  Batch with multiple conditional updates for the same partition causes 
AssertionError


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

Branch: refs/heads/trunk
Commit: c47d395d86d44a5ad48434a320826de3c1eb4a2b
Parents: 0e132f4 2b45673
Author: Sylvain Lebresne 
Authored: Mon Nov 7 14:10:54 2016 +0100
Committer: Sylvain Lebresne 
Committed: Mon Nov 7 14:10:54 2016 +0100

--
 CHANGES.txt |   1 +
 .../cql3/statements/CQL3CasRequest.java |  27 -
 .../operations/InsertUpdateIfConditionTest.java | 104 +++
 3 files changed, 127 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c47d395d/CHANGES.txt
--
diff --cc CHANGES.txt
index 446d550,1123553..bbe79e6
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -105,8 -97,9 +105,9 @@@
   * Remove pre-startup check for open JMX port (CASSANDRA-12074)
   * Remove compaction Severity from DynamicEndpointSnitch (CASSANDRA-11738)
   * Restore resumable hints delivery (CASSANDRA-11960)
 - * Properly report LWT contention (CASSANDRA-12626)
 + * Properly record CAS contention (CASSANDRA-12626)
  Merged from 3.0:
+  * Batch with multiple conditional updates for the same partition causes 
AssertionError (CASSANDRA-12867)
   * Make AbstractReplicationStrategy extendable from outside its package 
(CASSANDRA-12788)
   * Don't tell users to turn off consistent rangemovements during rebuild. 
(CASSANDRA-12296)
   * Fix CommitLogTest.testDeleteIfNotDirty (CASSANDRA-12854)

[1/6] cassandra git commit: Batch with multiple conditional updates for the same partition causes AssertionError

[slebresne]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 f7aa37142 -> 78fdfe233
  refs/heads/cassandra-3.X 9b4297465 -> 2b4567313
  refs/heads/trunk 0e132f4eb -> c47d395d8


Batch with multiple conditional updates for the same partition causes 
AssertionError

patch by Sylvain Lebresne; reviewed by Benjamin Lerer for CASSANDRA-12867


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

Branch: refs/heads/cassandra-3.0
Commit: 78fdfe2336048ba37a8b4c321ee4ab5d7bfb1357
Parents: f7aa371
Author: Sylvain Lebresne 
Authored: Wed Nov 2 14:47:42 2016 +0100
Committer: Sylvain Lebresne 
Committed: Mon Nov 7 14:09:22 2016 +0100

--
 CHANGES.txt |   1 +
 .../cql3/statements/CQL3CasRequest.java |  27 -
 .../operations/InsertUpdateIfConditionTest.java | 104 +++
 3 files changed, 127 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/78fdfe23/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f708602..1d2c8f3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.10
+ * Batch with multiple conditional updates for the same partition causes 
AssertionError (CASSANDRA-12867)
  * Make AbstractReplicationStrategy extendable from outside its package 
(CASSANDRA-12788)
  * Fix CommitLogTest.testDeleteIfNotDirty (CASSANDRA-12854)
  * Don't tell users to turn off consistent rangemovements during rebuild. 
(CASSANDRA-12296)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/78fdfe23/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java 
b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
index cf4110c..d9e8796 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
@@ -93,12 +93,29 @@ public class CQL3CasRequest implements CASRequest
 {
 assert condition instanceof ExistCondition || condition instanceof 
NotExistCondition;
 RowCondition previous = getConditionsForRow(clustering);
-if (previous != null && 
!(previous.getClass().equals(condition.getClass(
+if (previous != null)
 {
-// these should be prevented by the parser, but it doesn't hurt to 
check
-throw (previous instanceof NotExistCondition || previous 
instanceof ExistCondition)
-? new InvalidRequestException("Cannot mix IF EXISTS and IF NOT 
EXISTS conditions for the same row")
-: new InvalidRequestException("Cannot mix IF conditions and IF 
" + (isNotExist ? "NOT " : "") + "EXISTS for the same row");
+if (previous.getClass().equals(condition.getClass()))
+{
+// We can get here if a BATCH has 2 different statements on 
the same row with the same "exist" condition.
+// For instance (assuming 'k' is the full PK):
+//   BEGIN BATCH
+//  INSERT INTO t(k, v1) VALUES (0, 'foo') IF NOT EXISTS;
+//  INSERT INTO t(k, v2) VALUES (0, 'bar') IF NOT EXISTS;
+//   APPLY BATCH;
+// Of course, those can be trivially rewritten by the user as 
a single INSERT statement, but we still don't
+// want this to be a problem (see #12867 in particular), so we 
simply return (the condition itself has
+// already be set).
+assert hasExists; // We shouldn't have a previous condition 
unless hasExists has been set already.
+return;
+}
+else
+{
+// these should be prevented by the parser, but it doesn't 
hurt to check
+throw (previous instanceof NotExistCondition || previous 
instanceof ExistCondition)
+? new InvalidRequestException("Cannot mix IF EXISTS and IF 
NOT EXISTS conditions for the same row")
+: new InvalidRequestException("Cannot mix IF conditions 
and IF " + (isNotExist ? "NOT " : "") + "EXISTS for the same row");
+}
 }
 
 setConditionsForRow(clustering, condition);

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

[3/6] cassandra git commit: Batch with multiple conditional updates for the same partition causes AssertionError

[slebresne]

Batch with multiple conditional updates for the same partition causes 
AssertionError

patch by Sylvain Lebresne; reviewed by Benjamin Lerer for CASSANDRA-12867


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

Branch: refs/heads/trunk
Commit: 78fdfe2336048ba37a8b4c321ee4ab5d7bfb1357
Parents: f7aa371
Author: Sylvain Lebresne 
Authored: Wed Nov 2 14:47:42 2016 +0100
Committer: Sylvain Lebresne 
Committed: Mon Nov 7 14:09:22 2016 +0100

--
 CHANGES.txt |   1 +
 .../cql3/statements/CQL3CasRequest.java |  27 -
 .../operations/InsertUpdateIfConditionTest.java | 104 +++
 3 files changed, 127 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/78fdfe23/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f708602..1d2c8f3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.10
+ * Batch with multiple conditional updates for the same partition causes 
AssertionError (CASSANDRA-12867)
  * Make AbstractReplicationStrategy extendable from outside its package 
(CASSANDRA-12788)
  * Fix CommitLogTest.testDeleteIfNotDirty (CASSANDRA-12854)
  * Don't tell users to turn off consistent rangemovements during rebuild. 
(CASSANDRA-12296)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/78fdfe23/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java 
b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
index cf4110c..d9e8796 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
@@ -93,12 +93,29 @@ public class CQL3CasRequest implements CASRequest
 {
 assert condition instanceof ExistCondition || condition instanceof 
NotExistCondition;
 RowCondition previous = getConditionsForRow(clustering);
-if (previous != null && 
!(previous.getClass().equals(condition.getClass(
+if (previous != null)
 {
-// these should be prevented by the parser, but it doesn't hurt to 
check
-throw (previous instanceof NotExistCondition || previous 
instanceof ExistCondition)
-? new InvalidRequestException("Cannot mix IF EXISTS and IF NOT 
EXISTS conditions for the same row")
-: new InvalidRequestException("Cannot mix IF conditions and IF 
" + (isNotExist ? "NOT " : "") + "EXISTS for the same row");
+if (previous.getClass().equals(condition.getClass()))
+{
+// We can get here if a BATCH has 2 different statements on 
the same row with the same "exist" condition.
+// For instance (assuming 'k' is the full PK):
+//   BEGIN BATCH
+//  INSERT INTO t(k, v1) VALUES (0, 'foo') IF NOT EXISTS;
+//  INSERT INTO t(k, v2) VALUES (0, 'bar') IF NOT EXISTS;
+//   APPLY BATCH;
+// Of course, those can be trivially rewritten by the user as 
a single INSERT statement, but we still don't
+// want this to be a problem (see #12867 in particular), so we 
simply return (the condition itself has
+// already be set).
+assert hasExists; // We shouldn't have a previous condition 
unless hasExists has been set already.
+return;
+}
+else
+{
+// these should be prevented by the parser, but it doesn't 
hurt to check
+throw (previous instanceof NotExistCondition || previous 
instanceof ExistCondition)
+? new InvalidRequestException("Cannot mix IF EXISTS and IF 
NOT EXISTS conditions for the same row")
+: new InvalidRequestException("Cannot mix IF conditions 
and IF " + (isNotExist ? "NOT " : "") + "EXISTS for the same row");
+}
 }
 
 setConditionsForRow(clustering, condition);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/78fdfe23/test/unit/org/apache/cassandra/cql3/validation/operations/InsertUpdateIfConditionTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/operations/InsertUpdateIfConditionTest.java
 

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

[slebresne]

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

* cassandra-3.0:
  Batch with multiple conditional updates for the same partition causes 
AssertionError


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

Branch: refs/heads/cassandra-3.X
Commit: 2b456731319c0b6c9283961611ff39e4aefdf86e
Parents: 9b42974 78fdfe2
Author: Sylvain Lebresne 
Authored: Mon Nov 7 14:10:42 2016 +0100
Committer: Sylvain Lebresne 
Committed: Mon Nov 7 14:10:42 2016 +0100

--
 CHANGES.txt |   1 +
 .../cql3/statements/CQL3CasRequest.java |  27 -
 .../operations/InsertUpdateIfConditionTest.java | 104 +++
 3 files changed, 127 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2b456731/CHANGES.txt
--
diff --cc CHANGES.txt
index ab34d46,1d2c8f3..1123553
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,108 -1,9 +1,109 @@@
 -3.0.10
 +3.10
 + * Fix crossNode value when receiving messages (CASSANDRA-12791)
 + * Don't load MX4J beans twice (CASSANDRA-12869)
 + * Extend native protocol request flags, add versions to SUPPORTED, and 
introduce ProtocolVersion enum (CASSANDRA-12838)
 + * Set JOINING mode when running pre-join tasks (CASSANDRA-12836)
 + * remove net.mintern.primitive library due to license issue (CASSANDRA-12845)
 + * Properly format IPv6 addresses when logging JMX service URL 
(CASSANDRA-12454)
 + * 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)
 + * 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)
 + * Make the fanout size for LeveledCompactionStrategy to be configurable 
(CASSANDRA-11550)
 + * Add duration data type (CASSANDRA-11873)
 + * Fix timeout in ReplicationAwareTokenAllocatorTest (CASSANDRA-12784)
 + * Improve sum aggregate functions (CASSANDRA-12417)
 + * Make cassandra.yaml docs for batch_size_*_threshold_in_kb reflect changes 
in CASSANDRA-10876 (CASSANDRA-12761)
 + * cqlsh fails to format collections when using aliases (CASSANDRA-11534)
 + * Check for hash conflicts in prepared statements (CASSANDRA-12733)
 + * Exit query parsing upon first error (CASSANDRA-12598)
 + * Fix cassandra-stress to use single seed in UUID generation 
(CASSANDRA-12729)
 + * CQLSSTableWriter does not allow Update statement (CASSANDRA-12450)
 + * Config class uses boxed types but DD exposes primitive types 
(CASSANDRA-12199)
 + * Add pre- and post-shutdown hooks to Storage Service (CASSANDRA-12461)
 + * Add hint delivery metrics (CASSANDRA-12693)
 + * Remove IndexInfo cache from FileIndexInfoRetriever (CASSANDRA-12731)
 + * ColumnIndex does not reuse buffer (CASSANDRA-12502)
 + * cdc column addition still breaks schema migration tasks (CASSANDRA-12697)
 + * Upgrade metrics-reporter dependencies (CASSANDRA-12089)
 + * Tune compaction thread count via nodetool (CASSANDRA-12248)
 + * Add +=/-= shortcut syntax for update queries (CASSANDRA-12232)
 + * Include repair session IDs in repair start message (CASSANDRA-12532)
 + * Add a blocking task to Index, run before joining the ring (CASSANDRA-12039)
 + * Fix NPE when using CQLSSTableWriter (CASSANDRA-12667)
 + * Support optional backpressure strategies at the coordinator 
(CASSANDRA-9318)
 + * Make randompartitioner work with new vnode allocation (CASSANDRA-12647)
 + * Fix cassandra-stress graphing (CASSANDRA-12237)
 + * Allow filtering on partition key columns for queries without secondary 
indexes (CASSANDRA-11031)
 + * Fix Cassandra Stress reporting thread model and precision (CASSANDRA-12585)
 + * Add JMH benchmarks.jar (CASSANDRA-12586)
 + * Add row offset support to SASI (CASSANDRA-11990)
 + * Cleanup uses of AlterTableStatementColumn (CASSANDRA-12567)
 + * Add keep-alive to streaming (CASSANDRA-11841)
 + * Tracing payload is passed through newSession(..) (CASSANDRA-11706)
 + * avoid deleting non existing sstable files and improve related log messages 
(CASSANDRA-12261)
 + * json/yaml output format for nodetool compactionhistory (CASSANDRA-12486)
 + * Retry all internode messages once after a connection is
 +   closed and reopened (CASSANDRA-12192)
 + * Add support to rebuild from 

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

[slebresne]

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

* cassandra-3.0:
  Batch with multiple conditional updates for the same partition causes 
AssertionError


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

Branch: refs/heads/trunk
Commit: 2b456731319c0b6c9283961611ff39e4aefdf86e
Parents: 9b42974 78fdfe2
Author: Sylvain Lebresne 
Authored: Mon Nov 7 14:10:42 2016 +0100
Committer: Sylvain Lebresne 
Committed: Mon Nov 7 14:10:42 2016 +0100

--
 CHANGES.txt |   1 +
 .../cql3/statements/CQL3CasRequest.java |  27 -
 .../operations/InsertUpdateIfConditionTest.java | 104 +++
 3 files changed, 127 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2b456731/CHANGES.txt
--
diff --cc CHANGES.txt
index ab34d46,1d2c8f3..1123553
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,108 -1,9 +1,109 @@@
 -3.0.10
 +3.10
 + * Fix crossNode value when receiving messages (CASSANDRA-12791)
 + * Don't load MX4J beans twice (CASSANDRA-12869)
 + * Extend native protocol request flags, add versions to SUPPORTED, and 
introduce ProtocolVersion enum (CASSANDRA-12838)
 + * Set JOINING mode when running pre-join tasks (CASSANDRA-12836)
 + * remove net.mintern.primitive library due to license issue (CASSANDRA-12845)
 + * Properly format IPv6 addresses when logging JMX service URL 
(CASSANDRA-12454)
 + * 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)
 + * 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)
 + * Make the fanout size for LeveledCompactionStrategy to be configurable 
(CASSANDRA-11550)
 + * Add duration data type (CASSANDRA-11873)
 + * Fix timeout in ReplicationAwareTokenAllocatorTest (CASSANDRA-12784)
 + * Improve sum aggregate functions (CASSANDRA-12417)
 + * Make cassandra.yaml docs for batch_size_*_threshold_in_kb reflect changes 
in CASSANDRA-10876 (CASSANDRA-12761)
 + * cqlsh fails to format collections when using aliases (CASSANDRA-11534)
 + * Check for hash conflicts in prepared statements (CASSANDRA-12733)
 + * Exit query parsing upon first error (CASSANDRA-12598)
 + * Fix cassandra-stress to use single seed in UUID generation 
(CASSANDRA-12729)
 + * CQLSSTableWriter does not allow Update statement (CASSANDRA-12450)
 + * Config class uses boxed types but DD exposes primitive types 
(CASSANDRA-12199)
 + * Add pre- and post-shutdown hooks to Storage Service (CASSANDRA-12461)
 + * Add hint delivery metrics (CASSANDRA-12693)
 + * Remove IndexInfo cache from FileIndexInfoRetriever (CASSANDRA-12731)
 + * ColumnIndex does not reuse buffer (CASSANDRA-12502)
 + * cdc column addition still breaks schema migration tasks (CASSANDRA-12697)
 + * Upgrade metrics-reporter dependencies (CASSANDRA-12089)
 + * Tune compaction thread count via nodetool (CASSANDRA-12248)
 + * Add +=/-= shortcut syntax for update queries (CASSANDRA-12232)
 + * Include repair session IDs in repair start message (CASSANDRA-12532)
 + * Add a blocking task to Index, run before joining the ring (CASSANDRA-12039)
 + * Fix NPE when using CQLSSTableWriter (CASSANDRA-12667)
 + * Support optional backpressure strategies at the coordinator 
(CASSANDRA-9318)
 + * Make randompartitioner work with new vnode allocation (CASSANDRA-12647)
 + * Fix cassandra-stress graphing (CASSANDRA-12237)
 + * Allow filtering on partition key columns for queries without secondary 
indexes (CASSANDRA-11031)
 + * Fix Cassandra Stress reporting thread model and precision (CASSANDRA-12585)
 + * Add JMH benchmarks.jar (CASSANDRA-12586)
 + * Add row offset support to SASI (CASSANDRA-11990)
 + * Cleanup uses of AlterTableStatementColumn (CASSANDRA-12567)
 + * Add keep-alive to streaming (CASSANDRA-11841)
 + * Tracing payload is passed through newSession(..) (CASSANDRA-11706)
 + * avoid deleting non existing sstable files and improve related log messages 
(CASSANDRA-12261)
 + * json/yaml output format for nodetool compactionhistory (CASSANDRA-12486)
 + * Retry all internode messages once after a connection is
 +   closed and reopened (CASSANDRA-12192)
 + * Add support to rebuild from targeted 

[2/6] cassandra git commit: Batch with multiple conditional updates for the same partition causes AssertionError

[slebresne]

Batch with multiple conditional updates for the same partition causes 
AssertionError

patch by Sylvain Lebresne; reviewed by Benjamin Lerer for CASSANDRA-12867


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

Branch: refs/heads/cassandra-3.X
Commit: 78fdfe2336048ba37a8b4c321ee4ab5d7bfb1357
Parents: f7aa371
Author: Sylvain Lebresne 
Authored: Wed Nov 2 14:47:42 2016 +0100
Committer: Sylvain Lebresne 
Committed: Mon Nov 7 14:09:22 2016 +0100

--
 CHANGES.txt |   1 +
 .../cql3/statements/CQL3CasRequest.java |  27 -
 .../operations/InsertUpdateIfConditionTest.java | 104 +++
 3 files changed, 127 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/78fdfe23/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f708602..1d2c8f3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.10
+ * Batch with multiple conditional updates for the same partition causes 
AssertionError (CASSANDRA-12867)
  * Make AbstractReplicationStrategy extendable from outside its package 
(CASSANDRA-12788)
  * Fix CommitLogTest.testDeleteIfNotDirty (CASSANDRA-12854)
  * Don't tell users to turn off consistent rangemovements during rebuild. 
(CASSANDRA-12296)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/78fdfe23/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java 
b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
index cf4110c..d9e8796 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CQL3CasRequest.java
@@ -93,12 +93,29 @@ public class CQL3CasRequest implements CASRequest
 {
 assert condition instanceof ExistCondition || condition instanceof 
NotExistCondition;
 RowCondition previous = getConditionsForRow(clustering);
-if (previous != null && 
!(previous.getClass().equals(condition.getClass(
+if (previous != null)
 {
-// these should be prevented by the parser, but it doesn't hurt to 
check
-throw (previous instanceof NotExistCondition || previous 
instanceof ExistCondition)
-? new InvalidRequestException("Cannot mix IF EXISTS and IF NOT 
EXISTS conditions for the same row")
-: new InvalidRequestException("Cannot mix IF conditions and IF 
" + (isNotExist ? "NOT " : "") + "EXISTS for the same row");
+if (previous.getClass().equals(condition.getClass()))
+{
+// We can get here if a BATCH has 2 different statements on 
the same row with the same "exist" condition.
+// For instance (assuming 'k' is the full PK):
+//   BEGIN BATCH
+//  INSERT INTO t(k, v1) VALUES (0, 'foo') IF NOT EXISTS;
+//  INSERT INTO t(k, v2) VALUES (0, 'bar') IF NOT EXISTS;
+//   APPLY BATCH;
+// Of course, those can be trivially rewritten by the user as 
a single INSERT statement, but we still don't
+// want this to be a problem (see #12867 in particular), so we 
simply return (the condition itself has
+// already be set).
+assert hasExists; // We shouldn't have a previous condition 
unless hasExists has been set already.
+return;
+}
+else
+{
+// these should be prevented by the parser, but it doesn't 
hurt to check
+throw (previous instanceof NotExistCondition || previous 
instanceof ExistCondition)
+? new InvalidRequestException("Cannot mix IF EXISTS and IF 
NOT EXISTS conditions for the same row")
+: new InvalidRequestException("Cannot mix IF conditions 
and IF " + (isNotExist ? "NOT " : "") + "EXISTS for the same row");
+}
 }
 
 setConditionsForRow(clustering, condition);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/78fdfe23/test/unit/org/apache/cassandra/cql3/validation/operations/InsertUpdateIfConditionTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/operations/InsertUpdateIfConditionTest.java
 

[jira] [Resolved] (CASSANDRA-11672) Upgradesstables errors with "CompoundComposite cannot be cast to org.apache.cassandra.db.composites.CellName"

[Alex Petrov (JIRA)]

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

Alex Petrov resolved CASSANDRA-11672.
-
Resolution: Cannot Reproduce

> Upgradesstables errors with "CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName" 
> --
>
> Key: CASSANDRA-11672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11672
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Ashley
>Assignee: Alex Petrov
>
> Upgradesstables in C* 2.1 fails on thrift tables originally created on C*1.2 
> with the following error:
> {code}
> $ nodetool upgradesstables -a
> error: org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName
> -- StackTrace --
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName
>   at 
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:86)
>   at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
>   at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at 
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.hasNext(SSTableIdentityIterator.java:171)
>   at 
> org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:202)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at 
> org.apache.cassandra.db.ColumnIndex$Builder.buildForCompaction(ColumnIndex.java:166)
>   at 
> org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:121)
>   at 
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:193)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:126)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:197)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$4.execute(CompactionManager.java:376)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:304)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> This problem is not seen if the thrift table was originally created in C* 
> 2.0.x
> The suspicion is that this is related to the use of a CompositeType 
> comparator. 
> The following schema is an example of a cf that will cause this issue.
> {code}
> create column family cf1
>   with column_type = 'Standard'
>   and comparator = 
> 'CompositeType(org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.DateType),org.apache.cassandra.db.marshal.UUIDType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.UUIDType,org.apache.cassandra.db.marshal.UUIDType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType)'
>   and default_validation_class = 'UTF8Type'
>   and key_validation_class = 
> 'CompositeType(org.apache.cassandra.db.marshal.LongType,org.apache.cassandra.db.marshal.IntegerType)'
>   and read_repair_chance = 1.0
>   and dclocal_read_repair_chance = 0.0
>   and populate_io_cache_on_flush = false
>   and gc_grace = 259200
>   and min_compaction_threshold = 4
>   and max_compaction_threshold = 32
>   and replicate_on_write = true
>   and compaction_strategy = 
> 

[jira] [Comment Edited] (CASSANDRA-11672) Upgradesstables errors with "CompoundComposite cannot be cast to org.apache.cassandra.db.composites.CellName"

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-11672 at 11/7/16 12:58 PM:
---

I've tried reproducing it without success (multiple versions, including 1.2.19 
-> 2.0.9 -> 2.1.16). 
[~sashley] tried a different path (1.2.19 -> 2.0.14 -> 2.1.17) with the same 
result.

I was not able to track it down to the particular commit that fixes the issue. 
It also may as well have been in completely different code path from the stack 
trace.


was (Author: ifesdjeen):
I've tried reproducing it without success (upgrading 1.2.x -> 2.0.9 -> 2.1.16). 

I was not able to track it down to the particular commit that fixes the issue. 
It also may as well have been in completely different code path from the stack 
trace.

> Upgradesstables errors with "CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName" 
> --
>
> Key: CASSANDRA-11672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11672
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Ashley
>Assignee: Alex Petrov
>
> Upgradesstables in C* 2.1 fails on thrift tables originally created on C*1.2 
> with the following error:
> {code}
> $ nodetool upgradesstables -a
> error: org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName
> -- StackTrace --
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName
>   at 
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:86)
>   at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
>   at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at 
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.hasNext(SSTableIdentityIterator.java:171)
>   at 
> org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:202)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at 
> org.apache.cassandra.db.ColumnIndex$Builder.buildForCompaction(ColumnIndex.java:166)
>   at 
> org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:121)
>   at 
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:193)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:126)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:197)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$4.execute(CompactionManager.java:376)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:304)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> This problem is not seen if the thrift table was originally created in C* 
> 2.0.x
> The suspicion is that this is related to the use of a CompositeType 
> comparator. 
> The following schema is an example of a cf that will cause this issue.
> {code}
> create column family cf1
>   with column_type = 'Standard'
>   and comparator = 
> 

[jira] [Commented] (CASSANDRA-11672) Upgradesstables errors with "CompoundComposite cannot be cast to org.apache.cassandra.db.composites.CellName"

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-11672:
-

I've tried reproducing it without success (upgrading 1.2.x -> 2.0.9 -> 2.1.16). 

I was not able to track it down to the particular commit that fixes the issue. 
It also may as well have been in completely different code path from the stack 
trace.

> Upgradesstables errors with "CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName" 
> --
>
> Key: CASSANDRA-11672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11672
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Simon Ashley
>Assignee: Alex Petrov
>
> Upgradesstables in C* 2.1 fails on thrift tables originally created on C*1.2 
> with the following error:
> {code}
> $ nodetool upgradesstables -a
> error: org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName
> -- StackTrace --
> java.lang.ClassCastException: 
> org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
> org.apache.cassandra.db.composites.CellName
>   at 
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:86)
>   at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
>   at 
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at 
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.hasNext(SSTableIdentityIterator.java:171)
>   at 
> org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:202)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at 
> org.apache.cassandra.db.ColumnIndex$Builder.buildForCompaction(ColumnIndex.java:166)
>   at 
> org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:121)
>   at 
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:193)
>   at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:126)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:197)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>   at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>   at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$4.execute(CompactionManager.java:376)
>   at 
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:304)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> This problem is not seen if the thrift table was originally created in C* 
> 2.0.x
> The suspicion is that this is related to the use of a CompositeType 
> comparator. 
> The following schema is an example of a cf that will cause this issue.
> {code}
> create column family cf1
>   with column_type = 'Standard'
>   and comparator = 
> 'CompositeType(org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.DateType),org.apache.cassandra.db.marshal.UUIDType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.UUIDType,org.apache.cassandra.db.marshal.UUIDType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType)'
>   and default_validation_class = 'UTF8Type'
>   and key_validation_class = 
> 'CompositeType(org.apache.cassandra.db.marshal.LongType,org.apache.cassandra.db.marshal.IntegerType)'
>   and read_repair_chance = 1.0
>   and dclocal_read_repair_chance = 

[jira] [Commented] (CASSANDRA-8457) nio MessagingService

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-8457:
-

Alright, here's a new round of reviews:
* On {{MessageOutHandler}}:
** I'm a bit unclear on the benefits of the 
{{SwappingByteBufDataOutputStreamPlus}} (whose name I'd btw probably shorten 
given it's private), compared to the simple solution of just allocating a 
{{ByteBuf}} per-message. My analysis is this: if we have no coalescing (which 
may end up being the default back in 4.0, CASSANDRA-12676), then for any 
message smaller than {{bufferCapacity}}, we end up allocating more than needed 
since we flush for each message, so it's less optimal. For larger messages, we 
end up allocating multiple small buffers (instead of a larger), which may be 
better but not sure how much. With coalescing, I guess we do end up potentially 
packing multiple messages into a {{ByteBuf}}, but does that make such a big 
difference (I mean, even if we were to have one {{ByteBuf}} per message, we 
would still not flush on every message, which feel the most important)? So to 
sum up, I can buy that it's slightly better in some cases, but it seems also 
slightly less optimal in other and it's unclear how much it helps when it does, 
so in the absence of any benchmarking, I'm wondering if it's not premature 
optimization. Shouldn't we leave that to later and keep it simpler?
** If we do keep {{SwappingByteBufDataOutputStreamPlus}}, I'd at least inline 
{{WriteState}}. It creates a new indirection which doesn't seem to have much 
benefit, and I admit the naming confused me (a "state" is not the first place I 
looked to find the buffer).
* In {{OutboundMessagingConnection}}:
** In {{writeBacklogToChannel}}, we seem to be sending timeouted messages if 
those are retried: I don't think we want to do that (we should always drop a 
timeouted message).
** I'm not a fan of the use of the {{backlog}} queue for sending message. I'm 
no Netty expert but that doesn't seem to fit Netty's "spirit". Once we're in a 
stable state (the connection is created), I'd expect {{enqueue()}} (which might 
warrant a rename) to just do a {{ctx.write()}} so it's confusing to me it 
doesn't. We do need to handle connection creation and retries, but it feels we 
can handle that easily enough through the future on channel creation. To 
clarify, I'd expect something along the lines of (it's simplified, just to 
clarify what I have in mind):
   {noformat}
void enqueue(MessageOut msg, int id)
{
QueuedMessage qm = new QueuedMessage(msg, id);
if (state == State.READY)
{
channel.write(qm);
}
else
{
ChannelFuture connectionFuture = connect(); // <- connect would deal 
with concurrency.
connectionFuture.addListener(f -> f.channel().write(qm));
}
}
{noformat}
** I'm a bit unclear on the {{flush()}} strategy. The code seems to flush 
basically on every message (ok, once per emptying of the queue, but if we 
ignore connection creation, this can be very well on every message or very 
close to it), but this seems to defeat the coalescing handler since that 
handler will flush on flush (does that make sense?). I could be getting this 
wrong, but if I don't, it seems we shouldn't flush in 
{{OutboundMessagingConnection}} but delegate that task to the coalescing 
handler. But see next point for a more general remark on flush.
* In general, there is 2 important operations that I think could be better 
extracted (so it's cleaner when those happen): flushes and timeouting messages. 
Here my thinking:
** Flushes: it's my understanding that when you flush is pretty important to 
performance. So it would be great if we could centralize where we flush if at 
all possible. In particular, and as said above, I feel we should not flush in 
{{OutboundMessagingConnection}}. What I would do however is add a 
{{FlushingHandler}} for that task. That handler would mostly be the 
{{CoalescingMessageOutHandler}} renamed, but the point of the renaming is to 
make it clear that it's where the decision to flush happens.
** Timeouts: the patch currently look for timeouted message in different places 
and it would be great to consolidate that. In general, I think it's enough to 
check if a message is timeouted once in the pipeline: messages will rarely 
timeout on the sending time by design and if they do, it's likely because the 
channel is overwhelmed and the message has sit on the Netty event executor 
queue too long, and I believe we'd catch well enough with a simple 
{{MessageTimeoutingHandler}}.
* Regarding dropped messages, the current implementation was going through the 
{{MessagingService.incrementDroppedMessages()}} methods, which is still used by 
other parts of the code and is distinguishing between cross-node and local 
messages, but the new code seems to have its own separate 

[jira] [Updated] (CASSANDRA-12707) JVM out of memory when querying an extra-large partition with lots of tombstones

[nicolas ginder (JIRA)]

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

nicolas ginder updated CASSANDRA-12707:
---
Fix Version/s: (was: 2.2.x)
   (was: 2.1.x)

> JVM out of memory when querying an extra-large partition with lots of 
> tombstones
> 
>
> Key: CASSANDRA-12707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12707
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: nicolas ginder
>
> We have an extra large partition of 40 million cells where most of the cells 
> were deleted. When querying this partition with a slice query, Cassandra runs 
> out of memory as tombstones fill up the JVM heap. After debugging one of the 
> large SSTable we found that this part of the code loads all the tombstones.
> In org.apache.cassandra.db.filter.QueryFilter
> ...
> public static Iterator gatherTombstones(final ColumnFamily returnCF, 
> final Iterator iter)
> {
> ...
> while (iter.hasNext())
> {
> OnDiskAtom atom = iter.next();
> if (atom instanceof Cell)
> {
> next = (Cell)atom;
> break;
> }
> else
> {
> returnCF.addAtom(atom);
> }
> }
> ...



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

[jira] [Updated] (CASSANDRA-12707) JVM out of memory when querying an extra-large partition with lots of tombstones

[nicolas ginder (JIRA)]

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

nicolas ginder updated CASSANDRA-12707:
---
Since Version:   (was: 2.1.11)

> JVM out of memory when querying an extra-large partition with lots of 
> tombstones
> 
>
> Key: CASSANDRA-12707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12707
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: nicolas ginder
> Fix For: 2.1.x, 2.2.x
>
>
> We have an extra large partition of 40 million cells where most of the cells 
> were deleted. When querying this partition with a slice query, Cassandra runs 
> out of memory as tombstones fill up the JVM heap. After debugging one of the 
> large SSTable we found that this part of the code loads all the tombstones.
> In org.apache.cassandra.db.filter.QueryFilter
> ...
> public static Iterator gatherTombstones(final ColumnFamily returnCF, 
> final Iterator iter)
> {
> ...
> while (iter.hasNext())
> {
> OnDiskAtom atom = iter.next();
> if (atom instanceof Cell)
> {
> next = (Cell)atom;
> break;
> }
> else
> {
> returnCF.addAtom(atom);
> }
> }
> ...



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

[jira] [Issue Comment Deleted] (CASSANDRA-12707) JVM out of memory when querying an extra-large partition with lots of tombstones

[nicolas ginder (JIRA)]

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

nicolas ginder updated CASSANDRA-12707:
---
Comment: was deleted

(was: C* 3.0 is not impacted as this part of the code was completely 
refactored. )

> JVM out of memory when querying an extra-large partition with lots of 
> tombstones
> 
>
> Key: CASSANDRA-12707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12707
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: nicolas ginder
> Fix For: 2.1.x, 2.2.x
>
>
> We have an extra large partition of 40 million cells where most of the cells 
> were deleted. When querying this partition with a slice query, Cassandra runs 
> out of memory as tombstones fill up the JVM heap. After debugging one of the 
> large SSTable we found that this part of the code loads all the tombstones.
> In org.apache.cassandra.db.filter.QueryFilter
> ...
> public static Iterator gatherTombstones(final ColumnFamily returnCF, 
> final Iterator iter)
> {
> ...
> while (iter.hasNext())
> {
> OnDiskAtom atom = iter.next();
> if (atom instanceof Cell)
> {
> next = (Cell)atom;
> break;
> }
> else
> {
> returnCF.addAtom(atom);
> }
> }
> ...



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

[jira] [Commented] (CASSANDRA-12707) JVM out of memory when querying an extra-large partition with lots of tombstones

[nicolas ginder (JIRA)]

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

nicolas ginder commented on CASSANDRA-12707:


C* 3.0 is not impacted as this part of the code was completely refactored. 

> JVM out of memory when querying an extra-large partition with lots of 
> tombstones
> 
>
> Key: CASSANDRA-12707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12707
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: nicolas ginder
> Fix For: 2.1.x, 2.2.x
>
>
> We have an extra large partition of 40 million cells where most of the cells 
> were deleted. When querying this partition with a slice query, Cassandra runs 
> out of memory as tombstones fill up the JVM heap. After debugging one of the 
> large SSTable we found that this part of the code loads all the tombstones.
> In org.apache.cassandra.db.filter.QueryFilter
> ...
> public static Iterator gatherTombstones(final ColumnFamily returnCF, 
> final Iterator iter)
> {
> ...
> while (iter.hasNext())
> {
> OnDiskAtom atom = iter.next();
> if (atom instanceof Cell)
> {
> next = (Cell)atom;
> break;
> }
> else
> {
> returnCF.addAtom(atom);
> }
> }
> ...



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

[jira] [Commented] (CASSANDRA-12707) JVM out of memory when querying an extra-large partition with lots of tombstones

[nicolas ginder (JIRA)]

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

nicolas ginder commented on CASSANDRA-12707:


C* 3.0 is not impacted as this part of the code was completely refactored. 

> JVM out of memory when querying an extra-large partition with lots of 
> tombstones
> 
>
> Key: CASSANDRA-12707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12707
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: nicolas ginder
> Fix For: 2.1.x, 2.2.x
>
>
> We have an extra large partition of 40 million cells where most of the cells 
> were deleted. When querying this partition with a slice query, Cassandra runs 
> out of memory as tombstones fill up the JVM heap. After debugging one of the 
> large SSTable we found that this part of the code loads all the tombstones.
> In org.apache.cassandra.db.filter.QueryFilter
> ...
> public static Iterator gatherTombstones(final ColumnFamily returnCF, 
> final Iterator iter)
> {
> ...
> while (iter.hasNext())
> {
> OnDiskAtom atom = iter.next();
> if (atom instanceof Cell)
> {
> next = (Cell)atom;
> break;
> }
> else
> {
> returnCF.addAtom(atom);
> }
> }
> ...



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

[jira] [Updated] (CASSANDRA-12707) JVM out of memory when querying an extra-large partition with lots of tombstones

[nicolas ginder (JIRA)]

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

nicolas ginder updated CASSANDRA-12707:
---
Reproduced In: 2.1.x, 2.2.x  (was: 2.1.x)

> JVM out of memory when querying an extra-large partition with lots of 
> tombstones
> 
>
> Key: CASSANDRA-12707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12707
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: nicolas ginder
> Fix For: 2.1.x, 2.2.x
>
>
> We have an extra large partition of 40 million cells where most of the cells 
> were deleted. When querying this partition with a slice query, Cassandra runs 
> out of memory as tombstones fill up the JVM heap. After debugging one of the 
> large SSTable we found that this part of the code loads all the tombstones.
> In org.apache.cassandra.db.filter.QueryFilter
> ...
> public static Iterator gatherTombstones(final ColumnFamily returnCF, 
> final Iterator iter)
> {
> ...
> while (iter.hasNext())
> {
> OnDiskAtom atom = iter.next();
> if (atom instanceof Cell)
> {
> next = (Cell)atom;
> break;
> }
> else
> {
> returnCF.addAtom(atom);
> }
> }
> ...



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

[jira] [Updated] (CASSANDRA-12867) Batch with multiple conditional updates for the same partition causes AssertionError

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-12867:
---
Status: Ready to Commit  (was: Patch Available)

> Batch with multiple conditional updates for the same partition causes 
> AssertionError
> 
>
> Key: CASSANDRA-12867
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12867
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Kurt Greaves
>Assignee: Sylvain Lebresne
>Priority: Critical
> Fix For: 3.0.10, 3.10
>
> Attachments: 12867-3.0.patch
>
>
> Reproduced in 3.0.10 and 3.10. Used to work in 3.0.9 and earlier. Bug was 
> introduced in CASSANDRA-12060.
> The following causes an AssertionError:
> {code}
> CREATE KEYSPACE test WITH replication = { 'class' : 'SimpleStrategy', 
> 'replication_factor' : 1 };
> create table test.test (id int PRIMARY KEY, val text);
> BEGIN BATCH INSERT INTO test.test (id, val) VALUES (999, 'aaa') IF NOT 
> EXISTS; INSERT INTO test.test (id, val) VALUES (999, 'ccc') IF NOT EXISTS; 
> APPLY BATCH ;
> {code}
> Stack trace is as follows:
> {code}
> ERROR [Native-Transport-Requests-2] 2016-10-31 04:16:44,231 Message.java:622 
> - Unexpected exception during request; channel = [id: 0x176e1c04, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:59743]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.setConditionsForRow(CQL3CasRequest.java:138)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.addExistsCondition(CQL3CasRequest.java:104)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.addNotExist(CQL3CasRequest.java:84)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.IfNotExistsCondition.addConditionsTo(IfNotExistsCondition.java:28)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.addConditions(ModificationStatement.java:482)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.makeCasRequest(BatchStatement.java:434)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.executeWithConditions(BatchStatement.java:379)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:358)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:346)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:341)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:218)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:249) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:234) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:516)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:409)
>  [main/:na]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_102]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [main/:na]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102]
> {code}
> The problem is that previous will receive a value after the first statement 
> in the batch is evaluated in BatchStatement.makeCasRequest. I can't see any 
> reason why we have this assertion, it seems to me that it's unnecessary.
> Removing it fixes the problem (obviously) but I'm not sure if it breaks 
> something else, or if this is an intended failure case (in which case it 
> should be caught earlier on).
> Relevant code is as 

[jira] [Commented] (CASSANDRA-12867) Batch with multiple conditional updates for the same partition causes AssertionError

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-12867:


Thanks. +1

> Batch with multiple conditional updates for the same partition causes 
> AssertionError
> 
>
> Key: CASSANDRA-12867
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12867
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Kurt Greaves
>Assignee: Sylvain Lebresne
>Priority: Critical
> Fix For: 3.0.10, 3.10
>
> Attachments: 12867-3.0.patch
>
>
> Reproduced in 3.0.10 and 3.10. Used to work in 3.0.9 and earlier. Bug was 
> introduced in CASSANDRA-12060.
> The following causes an AssertionError:
> {code}
> CREATE KEYSPACE test WITH replication = { 'class' : 'SimpleStrategy', 
> 'replication_factor' : 1 };
> create table test.test (id int PRIMARY KEY, val text);
> BEGIN BATCH INSERT INTO test.test (id, val) VALUES (999, 'aaa') IF NOT 
> EXISTS; INSERT INTO test.test (id, val) VALUES (999, 'ccc') IF NOT EXISTS; 
> APPLY BATCH ;
> {code}
> Stack trace is as follows:
> {code}
> ERROR [Native-Transport-Requests-2] 2016-10-31 04:16:44,231 Message.java:622 
> - Unexpected exception during request; channel = [id: 0x176e1c04, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:59743]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.setConditionsForRow(CQL3CasRequest.java:138)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.addExistsCondition(CQL3CasRequest.java:104)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.CQL3CasRequest.addNotExist(CQL3CasRequest.java:84)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.IfNotExistsCondition.addConditionsTo(IfNotExistsCondition.java:28)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.addConditions(ModificationStatement.java:482)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.makeCasRequest(BatchStatement.java:434)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.executeWithConditions(BatchStatement.java:379)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:358)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:346)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.BatchStatement.execute(BatchStatement.java:341)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:218)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:249) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:234) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:516)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:409)
>  [main/:na]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_102]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [main/:na]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102]
> {code}
> The problem is that previous will receive a value after the first statement 
> in the batch is evaluated in BatchStatement.makeCasRequest. I can't see any 
> reason why we have this assertion, it seems to me that it's unnecessary.
> Removing it fixes the problem (obviously) but I'm not sure if it breaks 
> something else, or if this is an intended failure case (in which case it 
> should be caught earlier on).
> Relevant code is as 

[jira] [Commented] (CASSANDRA-12281) Gossip blocks on startup when another node is bootstrapping

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-12281:


bq. Byteman is available for tests on the 2.2 branch since CASSANDRA-12377

Nice, I wasn't aware about that. I've now included the test for the 2.2 patch 
as well.

bq. In the PendingRangeCalculatorService, I'm not sure we need to move the 
"Finished calculation for ..." log message to trace. Most Gossip/TokenMetadata 
state changes are logged at debug, especially when they reflect some detail 
about the aggregate state of an operation.

I don't think the message itself is very useful, as it will log the execution 
time for both cases, when an actual calculation took place and on early exit by 
{{calculatePendingRanges}} due to a lack of relevant state changes. As the last 
case is only covered with a trace message in {{calculatePendingRanges}}, I 
don't think we should use debug for the message in {{PendingRangeTask}} either, 
as it will only will tell you how long the task took to execute, compared to 
the debug message in {{calculatePendingRanges}}, which will tell you how long 
an actual calculation took. 

Otherwise I've addressed the mentioned points of yours and will restart tests 
once cassci is available again. I'll follow up with the results.


> Gossip blocks on startup when another node is bootstrapping
> ---
>
> Key: CASSANDRA-12281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12281
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Eric Evans
>Assignee: Stefan Podkowinski
> Attachments: 12281-2.2.patch, 12281-3.0.patch, 12281-trunk.patch, 
> restbase1015-a_jstack.txt
>
>
> In our cluster, normal node startup times (after a drain on shutdown) are 
> less than 1 minute.  However, when another node in the cluster is 
> bootstrapping, the same node startup takes nearly 30 minutes to complete, the 
> apparent result of gossip blocking on pending range calculations.
> {noformat}
> $ nodetool-a tpstats
> Pool NameActive   Pending  Completed   Blocked  All 
> time blocked
> MutationStage 0 0   1840 0
>  0
> ReadStage 0 0   2350 0
>  0
> RequestResponseStage  0 0 53 0
>  0
> ReadRepairStage   0 0  1 0
>  0
> CounterMutationStage  0 0  0 0
>  0
> HintedHandoff 0 0 44 0
>  0
> MiscStage 0 0  0 0
>  0
> CompactionExecutor3 3395 0
>  0
> MemtableReclaimMemory 0 0 30 0
>  0
> PendingRangeCalculator1 2 29 0
>  0
> GossipStage   1  5602164 0
>  0
> MigrationStage0 0  0 0
>  0
> MemtablePostFlush 0 0111 0
>  0
> ValidationExecutor0 0  0 0
>  0
> Sampler   0 0  0 0
>  0
> MemtableFlushWriter   0 0 30 0
>  0
> InternalResponseStage 0 0  0 0
>  0
> AntiEntropyStage  0 0  0 0
>  0
> CacheCleanupExecutor  0 0  0 0
>  0
> Message type   Dropped
> READ 0
> RANGE_SLICE  0
> _TRACE   0
> MUTATION 0
> COUNTER_MUTATION 0
> REQUEST_RESPONSE 0
> PAGED_RANGE  0
> READ_REPAIR  0
> {noformat}
> A full thread dump is attached, but the relevant bit seems to be here:
> {noformat}
> [ ... ]
> "GossipStage:1" #1801 daemon prio=5 os_prio=0 tid=0x7fe4cd54b000 
> nid=0xea9 waiting on condition [0x7fddcf883000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x0004c1e922c0> (a 
> java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> 

[jira] [Commented] (CASSANDRA-12649) Add BATCH metrics

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-12649:


[~appodictic] If you have some questions/concerns on some review feedbacks, you 
should not hesitate to write them down on the ticket.

I realize now that my feedback was may be not really helpfull. Sorry for that.

My main concern is the fact that the measurement of the mutation will be done 
on every mutation and that it involves going through the mutation, to sum up 
the size of the mutation. On nodes with heavy writes this might have a non 
neglectable CPU cost. It is true that we compute the data size when we 
serialize the data but, there, we do not have another choice.

Setting up a benchmark for that take some time and unfortunatly I do not have 
the time to do it myself.
If I have to do it, I will try to setup a JMH benchmark to check the throughput 
of the {{dataSize}} method of random data. It is too difficult to assess that 
type of stuff on a running Cassandra due to the JIT and the overall fluctuation 
in response time of the all database (the impact of the change might end up 
being lost in the noise).

Regarding,
{quote}
I am also not fully convinced by the usefullness of Logged / Unlogged 
Partitions per batch distribution. Could you explain in more details how it 
will be usefull for you?
{quote}
I just wanted to understand why such mettric will be usefull.

What I did not see was the end of [~KurtG] comment:
bq. We have seen a lot of users mistakenly batch against multiple partitions.

Then my question is: Is there not a better way of doing it? Should we not have 
a setting for rejecting batches against multi partition or a warning?

[~appodictic] My only concern is the quality of what goes into Cassandra. I am 
not trying to prevent anybody from contributing. If you do not understand my 
comments or do not agree with them will free to write it down on the ticket. My 
patches do not receive a better treatment (have a look at CASSANDRA-10707, 
which took me 8 months), they rarely go in on the first attempt.



 


 



> Add BATCH metrics
> -
>
> Key: CASSANDRA-12649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12649
> Project: Cassandra
>  Issue Type: Wish
>Reporter: Alwyn Davis
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 12649-3.x.patch, stress-batch-metrics.tar.gz, 
> stress-trunk.tar.gz, trunk-12649.txt
>
>
> To identify causes of load on a cluster, it would be useful to have some 
> additional metrics:
> * *Mutation size distribution:* I believe this would be relevant when 
> tracking the performance of unlogged batches.
> * *Logged / Unlogged Partitions per batch distribution:* This would also give 
> a count of batch types processed. Multiple distinct tables in batch would 
> just be considered as separate partitions.



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

[jira] [Updated] (CASSANDRA-12649) Add BATCH metrics

[Alwyn Davis (JIRA)]

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

Alwyn Davis updated CASSANDRA-12649:

Attachment: stress-batch-metrics.tar.gz
stress-trunk.tar.gz

> Add BATCH metrics
> -
>
> Key: CASSANDRA-12649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12649
> Project: Cassandra
>  Issue Type: Wish
>Reporter: Alwyn Davis
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 12649-3.x.patch, stress-batch-metrics.tar.gz, 
> stress-trunk.tar.gz, trunk-12649.txt
>
>
> To identify causes of load on a cluster, it would be useful to have some 
> additional metrics:
> * *Mutation size distribution:* I believe this would be relevant when 
> tracking the performance of unlogged batches.
> * *Logged / Unlogged Partitions per batch distribution:* This would also give 
> a count of batch types processed. Multiple distinct tables in batch would 
> just be considered as separate partitions.



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

[jira] [Commented] (CASSANDRA-12649) Add BATCH metrics

[Alwyn Davis (JIRA)]

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

Alwyn Davis commented on CASSANDRA-12649:
-

Sure.  I ran cassandra-stress on a separate EC2 instance against a 3-node 
cluster with trunk and then with the batch metrics patch.  The results summary 
is (I've also attached the full stress output):
TRUNK

LOGGED
Row rate: 13,965 row/s, 95th latency: 1.4ms
Row rate: 14,351 row/s, 95th latency: 1.3ms
Row rate: 14,359 row/s, 95th latency: 1.7ms

UNLOGGED
Row rate: 14,674 row/s, 95th latency: 1.3ms
Row rate: 14,168 row/s, 95th latency: 1.7ms
Row rate: 14,128 row/s, 95th latency: 1.7ms


BATCH METRICS

LOGGED
Row rate: 13,531 row/s, 95th latency: 1.9ms
Row rate: 13,943 row/s, 95th latency: 1.7ms
Row rate: 14,210 row/s, 95th latency: 1.7ms

UNLOGGED
Row rate: 14,552 row/s, 95th latency: 1.3ms
Row rate: 14,568 rwo/s, 95th latency: 1.3ms
Row rate: 14,627 row/s, 95th latency: 1.2ms


I also ran the BatchMetrics test class with the metrics patch and just trunk 
for comparison (10,000 iterations of single queries, logged, unlogged and CAS 
batches):
WITH BATCH METRICS
query: 378410 ms, loggedBatch: 31638 ms, unloggedBatch: 21466 ms, cas: 33880 ms
query: 392960 ms, loggedBatch: 26284 ms, unloggedBatch: 21114 ms, cas: 30566 ms
query: 386964 ms, loggedBatch: 28724 ms, unloggedBatch: 22257 ms, cas: 33323 ms

TRUNK
query: 395683 ms, loggedBatch: 29994 ms, unloggedBatch: 21638 ms, cas: 33096 ms
query: 379503 ms, loggedBatch: 29911 ms, unloggedBatch: 21346 ms, cas: 32364 ms
query: 396935 ms, loggedBatch: 42124 ms, unloggedBatch: 21679 ms, cas: 34353 ms


Regarding the usefulness of Logged / Unlogged Partitions per batch, I believe 
that it would allow correlation of batch size to performance.  Standard advice 
is to process a single partition per unlogged batch, so comparing the number of 
partitions per batch against throughput should highlight poor usage of batches.

> Add BATCH metrics
> -
>
> Key: CASSANDRA-12649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12649
> Project: Cassandra
>  Issue Type: Wish
>Reporter: Alwyn Davis
>Priority: Minor
> Fix For: 3.x
>
> Attachments: 12649-3.x.patch, stress-batch-metrics.tar.gz, 
> stress-trunk.tar.gz, trunk-12649.txt
>
>
> To identify causes of load on a cluster, it would be useful to have some 
> additional metrics:
> * *Mutation size distribution:* I believe this would be relevant when 
> tracking the performance of unlogged batches.
> * *Logged / Unlogged Partitions per batch distribution:* This would also give 
> a count of batch types processed. Multiple distinct tables in batch would 
> just be considered as separate partitions.



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

[jira] [Updated] (CASSANDRA-11672) Upgradesstables errors with "CompoundComposite cannot be cast to org.apache.cassandra.db.composites.CellName"

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-11672:

Description: 
Upgradesstables in C* 2.1 fails on thrift tables originally created on C*1.2 
with the following error:

{code}
$ nodetool upgradesstables -a
error: org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
org.apache.cassandra.db.composites.CellName
-- StackTrace --
java.lang.ClassCastException: 
org.apache.cassandra.db.composites.CompoundComposite cannot be cast to 
org.apache.cassandra.db.composites.CellName
at 
org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:86)
at 
org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
at 
org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
at 
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at 
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at 
org.apache.cassandra.io.sstable.SSTableIdentityIterator.hasNext(SSTableIdentityIterator.java:171)
at 
org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:202)
at 
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at 
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
at 
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at 
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at 
org.apache.cassandra.db.ColumnIndex$Builder.buildForCompaction(ColumnIndex.java:166)
at 
org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:121)
at 
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:193)
at 
org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:126)
at 
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:197)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at 
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
at 
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
at 
org.apache.cassandra.db.compaction.CompactionManager$4.execute(CompactionManager.java:376)
at 
org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:304)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}

This problem is not seen if the thrift table was originally created in C* 2.0.x

The suspicion is that this is related to the use of a CompositeType comparator. 

The following schema is an example of a cf that will cause this issue.

{code}

create column family cf1
  with column_type = 'Standard'
  and comparator = 
'CompositeType(org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.DateType),org.apache.cassandra.db.marshal.UUIDType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.UUIDType,org.apache.cassandra.db.marshal.UUIDType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType)'
  and default_validation_class = 'UTF8Type'
  and key_validation_class = 
'CompositeType(org.apache.cassandra.db.marshal.LongType,org.apache.cassandra.db.marshal.IntegerType)'
  and read_repair_chance = 1.0
  and dclocal_read_repair_chance = 0.0
  and populate_io_cache_on_flush = false
  and gc_grace = 259200
  and min_compaction_threshold = 4
  and max_compaction_threshold = 32
  and replicate_on_write = true
  and compaction_strategy = 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
  and caching = 'KEYS_ONLY'
  and compression_options = {'sstable_compression' : 
'org.apache.cassandra.io.compress.SnappyCompressor', 'chunk_length_kb' : '64'};
{code}

You can workaround this via the creation of a dummy table and update of 
schema_columnfamilies for each cf affected. The dummy cf can be deleted 
afterwards.

cassandra-cli

[default@unknown] use ks1;
[default@ks1] create column family foo;
[default@ks1] use system;
[default@system] set schema_columnfamilies['ks1']['cf1:is_dense']=01;
[default@system] use ks1;
[default@ks1] update column family foo with