date:20170721

[jira] [Comment Edited] (CASSANDRA-9988) Introduce leaf-only iterator

2017-07-21 Thread Jay Zhuang (JIRA)


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

Jay Zhuang edited comment on CASSANDRA-9988 at 7/22/17 5:18 AM:


I added tests for different cell size and 10K/100K b-tree size:
| branch | utest |
|[9988-trunk|https://github.com/cooldoger/cassandra/tree/9988-trunk]|[circleci#41|https://circleci.com/gh/cooldoger/cassandra/41]|
|[9988-nofix|https://github.com/cooldoger/cassandra/tree/9988-nofix]||
If the data could fit into one leaf node (<=32), the performance is 
significantly improved. Otherwise, there's almost no performance difference, 
regardless of the cell size.
!9988-data.png|data!
!9988-result.png|result!


was (Author: jay.zhuang):
I added tests for different cell size and 10K/100K b-tree size:
| branch | utest |
|[9988-trunk|https://github.com/cooldoger/cassandra/tree/9988-trunk]|[circleci#41|https://circleci.com/gh/cooldoger/cassandra/41]|
|[9988-nofix|https://github.com/cooldoger/cassandra/tree/9988-nofix]||
If the data could fit into one leaf node (<=32), the performance is 
significantly improved. Otherwise, there's no performance difference, 
regardless of the cell size.
!9988-data.png|data!
!9988-result.png|result!

> Introduce leaf-only iterator
> 
>
> Key: CASSANDRA-9988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9988
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: patch
> Fix For: 4.0
>
> Attachments: 9988-data.png, 9988-result.png, 9988-trunk-new.txt, 
> 9988-trunk-new-update.txt, trunk-9988.txt
>
>
> In many cases we have small btrees, small enough to fit in a single leaf 
> page. In this case it _may_ be more efficient to specialise our iterator.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-9988) Introduce leaf-only iterator

2017-07-21 Thread Jay Zhuang (JIRA)


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

Jay Zhuang edited comment on CASSANDRA-9988 at 7/22/17 5:14 AM:


I added tests for different cell size and 10K/100K b-tree size:
| branch | utest |
|[9988-trunk|https://github.com/cooldoger/cassandra/tree/9988-trunk]|[circleci#41|https://circleci.com/gh/cooldoger/cassandra/41]|
|[9988-nofix|https://github.com/cooldoger/cassandra/tree/9988-nofix]||
If the data could fit into one leaf node (<=32), the performance is 
significantly improved. Otherwise, there's no performance difference, 
regardless of the cell size.
!9988-data.png|data!
!9988-result.png|result!


was (Author: jay.zhuang):
I added tests for different cell size and 10K and 100K b-tree size:
| branch | utest |
|[9988-trunk|https://github.com/cooldoger/cassandra/tree/9988-trunk]|[circleci#41|https://circleci.com/gh/cooldoger/cassandra/41]|
|[9988-nofix|https://github.com/cooldoger/cassandra/tree/9988-nofix]||
If the data could fit into one leaf node (<=32), the performance is 
significantly improved. Otherwise, there's no performance difference, 
regardless of the cell size.
!9988-data.png|data!
!9988-result.png|result!

> Introduce leaf-only iterator
> 
>
> Key: CASSANDRA-9988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9988
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: patch
> Fix For: 4.0
>
> Attachments: 9988-data.png, 9988-result.png, 9988-trunk-new.txt, 
> 9988-trunk-new-update.txt, trunk-9988.txt
>
>
> In many cases we have small btrees, small enough to fit in a single leaf 
> page. In this case it _may_ be more efficient to specialise our iterator.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-9988) Introduce leaf-only iterator

2017-07-21 Thread Jay Zhuang (JIRA)


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

Jay Zhuang commented on CASSANDRA-9988:
---

I added tests for different cell size and 10K and 100K b-tree size:
| branch | utest |
|[9988-trunk|https://github.com/cooldoger/cassandra/tree/9988-trunk]|[circleci#41|https://circleci.com/gh/cooldoger/cassandra/41]|
|[9988-nofix|https://github.com/cooldoger/cassandra/tree/9988-nofix]||
If the data could fit into one leaf node (<=32), the performance is 
significantly improved. Otherwise, there's no performance difference, 
regardless of the cell size.
!9988-data.png|data!
!9988-result.png|result!

> Introduce leaf-only iterator
> 
>
> Key: CASSANDRA-9988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9988
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: patch
> Fix For: 4.0
>
> Attachments: 9988-data.png, 9988-result.png, 9988-trunk-new.txt, 
> 9988-trunk-new-update.txt, trunk-9988.txt
>
>
> In many cases we have small btrees, small enough to fit in a single leaf 
> page. In this case it _may_ be more efficient to specialise our iterator.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-9988) Introduce leaf-only iterator

2017-07-21 Thread Jay Zhuang (JIRA)


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

Jay Zhuang updated CASSANDRA-9988:
--
Attachment: 9988-result.png
9988-data.png

> Introduce leaf-only iterator
> 
>
> Key: CASSANDRA-9988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9988
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: patch
> Fix For: 4.0
>
> Attachments: 9988-data.png, 9988-result.png, 9988-trunk-new.txt, 
> 9988-trunk-new-update.txt, trunk-9988.txt
>
>
> In many cases we have small btrees, small enough to fit in a single leaf 
> page. In this case it _may_ be more efficient to specialise our iterator.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-9333) Edge case - Empty of blank password for JMX authentication not handled properly in nodetool commands

2017-07-21 Thread Varun Barala (JIRA)


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

Varun Barala updated CASSANDRA-9333:

Attachment: 2.1.2.png

> Edge case - Empty of blank password for JMX authentication not handled 
> properly in nodetool commands
> 
>
> Key: CASSANDRA-9333
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9333
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Apache Cassandra 2.1.2
>Reporter: Sumod Pawgi
>Priority: Minor
>  Labels: security
> Fix For: 2.1.x
>
> Attachments: 2.1.2.png
>
>
> While setting up JMX authentication for Apache Cassandra, if we set the 
> password blank (in the file - jmxremote.password), nodetool commands do not 
> work
> example creds are cassandra cassandra. In this case, for a secured cluster, 
> we run the nodetool command as - nodetool -u cassandra -pw cassandra status
> But if the password is kept as blank then we cannot execute nodetool command. 
> However, I believe that if a third party software used JMX authentication via 
> API, then they can use blank password for the operations. So this behavior 
> needs to be clarified and be consistent for this edge case scenario.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-9333) Edge case - Empty of blank password for JMX authentication not handled properly in nodetool commands

2017-07-21 Thread Varun Barala (JIRA)


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

Varun Barala commented on CASSANDRA-9333:
-

In this scenario, You can use nodetool command like:-
"$ bin/nodetool -u cassandra status"
then It'll ask for password If your password is empty then just hit enter.

Though nodetool should accept "$ bin/nodetool -u cassandra -pw  status". I'll 
go through the code.

> Edge case - Empty of blank password for JMX authentication not handled 
> properly in nodetool commands
> 
>
> Key: CASSANDRA-9333
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9333
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Apache Cassandra 2.1.2
>Reporter: Sumod Pawgi
>Priority: Minor
>  Labels: security
> Fix For: 2.1.x
>
>
> While setting up JMX authentication for Apache Cassandra, if we set the 
> password blank (in the file - jmxremote.password), nodetool commands do not 
> work
> example creds are cassandra cassandra. In this case, for a secured cluster, 
> we run the nodetool command as - nodetool -u cassandra -pw cassandra status
> But if the password is kept as blank then we cannot execute nodetool command. 
> However, I believe that if a third party software used JMX authentication via 
> API, then they can use blank password for the operations. So this behavior 
> needs to be clarified and be consistent for this edge case scenario.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-9333) Edge case - Empty of blank password for JMX authentication not handled properly in nodetool commands

2017-07-21 Thread Varun Barala (JIRA)


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

Varun Barala edited comment on CASSANDRA-9333 at 7/22/17 4:12 AM:
--

In this scenario, You can use nodetool command like:-
{{$ bin/nodetool -u cassandra status}}
then It'll ask for password If your password is empty then just hit enter.

Though nodetool should accept {{$ bin/nodetool -u cassandra -pw  status}}. I'll 
go through the code.


was (Author: varuna):
In this scenario, You can use nodetool command like:-
"$ bin/nodetool -u cassandra status"
then It'll ask for password If your password is empty then just hit enter.

Though nodetool should accept "$ bin/nodetool -u cassandra -pw  status". I'll 
go through the code.

> Edge case - Empty of blank password for JMX authentication not handled 
> properly in nodetool commands
> 
>
> Key: CASSANDRA-9333
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9333
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Apache Cassandra 2.1.2
>Reporter: Sumod Pawgi
>Priority: Minor
>  Labels: security
> Fix For: 2.1.x
>
>
> While setting up JMX authentication for Apache Cassandra, if we set the 
> password blank (in the file - jmxremote.password), nodetool commands do not 
> work
> example creds are cassandra cassandra. In this case, for a secured cluster, 
> we run the nodetool command as - nodetool -u cassandra -pw cassandra status
> But if the password is kept as blank then we cannot execute nodetool command. 
> However, I believe that if a third party software used JMX authentication via 
> API, then they can use blank password for the operations. So this behavior 
> needs to be clarified and be consistent for this edge case scenario.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-11483) Enhance sstablemetadata

2017-07-21 Thread Chris Lohfink (JIRA)


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

Chris Lohfink commented on CASSANDRA-11483:
---

pushed changes + a fix to prevent sstable leaks and their warning messages

> Enhance sstablemetadata
> ---
>
> Key: CASSANDRA-11483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11483
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Minor
> Fix For: 4.0
>
> Attachments: CASSANDRA-11483.txt, CASSANDRA-11483v2.txt, 
> CASSANDRA-11483v3.txt, CASSANDRA-11483v4.txt, CASSANDRA-11483v5.txt, Screen 
> Shot 2016-04-03 at 11.40.32 PM.png
>
>
> sstablemetadata provides quite a bit of useful information but theres a few 
> hiccups I would like to see addressed:
> * Does not use client mode
> * Units are not provided (or anything for that matter). There is data in 
> micros, millis, seconds as durations and timestamps from epoch. But there is 
> no way to tell what one is without a non-trival code dive
> * in general pretty frustrating to parse



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-12996) update slf4j dependency to 1.7.21

2017-07-21 Thread Michael Shuler (JIRA)


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

Michael Shuler commented on CASSANDRA-12996:


{{ohc-parent-0.6.1.pom}} still has 
{{1.7.12}}

Regardless, it would be good to know what type of system this is failing on, 
since the build works fine on several different variations of linux.

> update slf4j dependency to 1.7.21
> -
>
> Key: CASSANDRA-12996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12996
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Tomas Repik
>Assignee: Stefan Podkowinski
> Fix For: 4.0
>
> Attachments: cassandra-3.11.0-slf4j.patch, 
> jcl-over-slf4j-1.7.25.jar.asc, log4j-over-slf4j-1.7.25.jar.asc, 
> slf4j-api-1.7.25.jar.asc
>
>
> Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to 
> the sources we need to do in order to successfully build it. Cassandra 
> depends on slf4j 1.7.7, but In Fedora we have the latest upstream version 
> 1.7.21 It was released some time ago on April 6 2016. I attached a patch 
> updating Cassandra sources to depend on the newer slf4j sources. The only 
> actual change is the number of parameters accepted by SubstituteLogger class. 
> Please consider updating.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13694) sstabledump does not show full precision of timestamp columns

2017-07-21 Thread Varun Barala (JIRA)


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

Varun Barala edited comment on CASSANDRA-13694 at 7/22/17 2:59 AM:
---

In order to match with cqlsh input. I added one more date format in 
`*TimestampSerializer.java*`.

Previously default format was `-MM-dd HH:mmXX` which has minute level 
precision. In this patch I changed it to `-MM-dd HH:mm:ss.SSSXX`.

I appended at the end of *dateStringPatterns* array to make sure minimum 
changes.

Please do let me know If I didn;t consider any case. Thank you!!


was (Author: varuna):
In order to match with cqlsh input. I added one more date format in 
`*TimestampSerializer.java*`.

Previously default format was `-MM-dd HH:mmXX` which has minute level 
precision. In this patch I changed it to `-MM-dd HH:mm:ss.SSXX`.

I appended at the end of *dateStringPatterns* array to make sure minimum 
changes.

Please do let me know If I didn;t consider any case. Thank you!!

> sstabledump does not show full precision of timestamp columns
> -
>
> Key: CASSANDRA-13694
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13694
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Ubuntu 16.04 LTS
>Reporter: Tim Reeves
>  Labels: patch-available
> Fix For: 3.7
>
> Attachments: CASSANDRA-13694-after-review.patch, CASSANDRA-13694.patch
>
>
> Create a table:
> CREATE TABLE test_table (
> unit_no bigint,
> event_code text,
> active_time timestamp,
> ack_time timestamp,
> PRIMARY KEY ((unit_no, event_code), active_time)
> ) WITH CLUSTERING ORDER BY (active_time DESC)
> Insert a row:
> INSERT INTO test_table (unit_no, event_code, active_time, ack_time)
>   VALUES (1234, 'TEST EVENT', toTimestamp(now()), 
> toTimestamp(now()));
> Verify that it is in the database with a full timestamp:
> cqlsh:pentaho> select * from test_table;
>  unit_no | event_code | active_time | ack_time
> -++-+-
> 1234 | TEST EVENT | 2017-07-14 14:52:39.919000+ | 2017-07-14 
> 14:52:39.919000+
> (1 rows)
> Write file:
> nodetool flush
> nodetool compact pentaho
> Use sstabledump:
> treeves@ubuntu:~$ sstabledump 
> /var/lib/cassandra/data/pentaho/test_table-99ba228068a311e7ac30953b79ac2c3e/mb-2-big-Data.db
> [
>   {
> "partition" : {
>   "key" : [ "1234", "TEST EVENT" ],
>   "position" : 0
> },
> "rows" : [
>   {
> "type" : "row",
> "position" : 38,
> "clustering" : [ "2017-07-14 15:52+0100" ],
> "liveness_info" : { "tstamp" : "2017-07-14T14:52:39.888701Z" },
> "cells" : [
>   { "name" : "ack_time", "value" : "2017-07-14 15:52+0100" }
> ]
>   }
> ]
>   }
> ]
> treeves@ubuntu:~$ 
> The timestamp in the cluster key, and the regular column, are both truncated 
> to the minute.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-12996) update slf4j dependency to 1.7.21

2017-07-21 Thread Michael Shuler (JIRA)


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

Michael Shuler commented on CASSANDRA-12996:


{{ohc-core}} and {{ohc-core-j8}} 0.4.4 might be the ones? After searching 
around in my freshly downloaded ~/.m2 cache.
{noformat}
(trunk)mshuler@hana:~/git/cassandra$ grep -r '1\.7\.12' ~/.m2/repository/
/home/mshuler/.m2/repository/org/slf4j/slf4j-parent/1.7.12/slf4j-parent-1.7.12.pom:
  1.7.12
/home/mshuler/.m2/repository/org/slf4j/slf4j-api/1.7.12/slf4j-api-1.7.12.pom:   
 1.7.12
/home/mshuler/.m2/repository/org/caffinitas/ohc/ohc-parent/0.4.4/ohc-parent-0.4.4.pom:
1.7.12

(trunk)mshuler@hana:~/git/cassandra$ grep ohc build.xml 
  
  




{noformat}

There are some other pom files that have dependencies for the other 2 slf4j 
versions we downloaded.

> update slf4j dependency to 1.7.21
> -
>
> Key: CASSANDRA-12996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12996
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Tomas Repik
>Assignee: Stefan Podkowinski
> Fix For: 4.0
>
> Attachments: cassandra-3.11.0-slf4j.patch, 
> jcl-over-slf4j-1.7.25.jar.asc, log4j-over-slf4j-1.7.25.jar.asc, 
> slf4j-api-1.7.25.jar.asc
>
>
> Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to 
> the sources we need to do in order to successfully build it. Cassandra 
> depends on slf4j 1.7.7, but In Fedora we have the latest upstream version 
> 1.7.21 It was released some time ago on April 6 2016. I attached a patch 
> updating Cassandra sources to depend on the newer slf4j sources. The only 
> actual change is the number of parameters accepted by SubstituteLogger class. 
> Please consider updating.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-12996) update slf4j dependency to 1.7.21

2017-07-21 Thread Michael Shuler (JIRA)


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

Michael Shuler commented on CASSANDRA-12996:


Bummer, that almost always works :)
Well, it looks like there are 3 different lower versions downloaded  that are 
sub-dependencies of other dependencies somewhere..

Removing all of {{~/.m2/repository/}}, a nice {{git clean -xdf}}, and fresh 
build of trunk saving the output off:

{noformat}
(trunk)mshuler@hana:~/git/cassandra$ egrep 'Downloading.*slf4j-api' 
/tmp/slf4j-jar-dep.txt 
[artifact:dependencies] Downloading: 
org/slf4j/slf4j-api/1.5.2/slf4j-api-1.5.2.pom from repository apache at 
http://repo.maven.apache.org/maven2
[artifact:dependencies] Downloading: 
org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.pom from repository apache at 
http://repo.maven.apache.org/maven2
[artifact:dependencies] Downloading: 
org/slf4j/slf4j-api/1.7.12/slf4j-api-1.7.12.pom from repository apache at 
http://repo.maven.apache.org/maven2
[artifact:dependencies] Downloading: 
org/slf4j/slf4j-api/1.7.12/slf4j-api-1.7.12.jar from repository apache at 
http://repo.maven.apache.org/maven2
[artifact:dependencies] Downloading: 
org/slf4j/slf4j-api/1.7.12/slf4j-api-1.7.12-sources.jar from repository central 
at http://repo1.maven.org/maven2
{noformat}

Yep, I do have 1.7.12 under {{build/lib/}}:
{noformat}
(trunk)mshuler@hana:~/git/cassandra$ find ./ -name slf4j-api*jar
./lib/slf4j-api-1.7.25.jar
./build/lib/sources/slf4j-api-1.7.12-sources.jar
./build/lib/jars/slf4j-api-1.7.12.jar
{noformat}

Not sure why I don't also have 1.5.2 and 1.7.7 in there, if they were 
downloaded from maven, nor which jars pulled all these in as dependencies.

> update slf4j dependency to 1.7.21
> -
>
> Key: CASSANDRA-12996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12996
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Tomas Repik
>Assignee: Stefan Podkowinski
> Fix For: 4.0
>
> Attachments: cassandra-3.11.0-slf4j.patch, 
> jcl-over-slf4j-1.7.25.jar.asc, log4j-over-slf4j-1.7.25.jar.asc, 
> slf4j-api-1.7.25.jar.asc
>
>
> Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to 
> the sources we need to do in order to successfully build it. Cassandra 
> depends on slf4j 1.7.7, but In Fedora we have the latest upstream version 
> 1.7.21 It was released some time ago on April 6 2016. I attached a patch 
> updating Cassandra sources to depend on the newer slf4j sources. The only 
> actual change is the number of parameters accepted by SubstituteLogger class. 
> Please consider updating.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13655) Range deletes in a CAS batch are ignored

2017-07-21 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa commented on CASSANDRA-13655:


For #1, it should be an easy change, but I'll check to see if it somehow 
complicates things. I sort of like it the way it is, in case they eventually 
diverge, but perhaps that's planning for a future that may never happen.

I'm not thrilled about #2, to be honest. I'd prefer to leave them as distinct 
checks. 


> Range deletes in a CAS batch are ignored
> 
>
> Key: CASSANDRA-13655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13655
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Critical
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Range deletes in a CAS batch are ignored 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

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

2017-07-21 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa commented on CASSANDRA-11995:


[~blambov] or [~aweisberg] - either of you interested in reviewing? I can 
rebase as needed.


> 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
>Assignee: Jeff Jirsa
>
> 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.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Resolved] (CASSANDRA-13313) Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0

2017-07-21 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa resolved CASSANDRA-13313.

Resolution: Won't Fix

Wont-fixing this. Patch isn't hard, but dtest is annoying, and it's awfully 
late in the 3.0 game to be worrying about this. Hate to add complexity to 
3.0.15, just to yank it out in 4.0. Simple workaround is simple - stop 
compactions, flush and drain during the upgrade, and chances of leftovers is 
pretty low.



> Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0
> --
>
> Key: CASSANDRA-13313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13313
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
>
> Before 3.0 we used sstable ancestors to figure out if an sstable was left 
> over after a compaction. In 3.0 the ancestors are ignored and instead we use 
> LogTransaction files to figure it out. 3.0 should still clean up 2.1/2.2 
> compaction leftovers using the on-disk sstable ancestors when available.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-12996) update slf4j dependency to 1.7.21

2017-07-21 Thread Jay Zhuang (JIRA)


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

Jay Zhuang commented on CASSANDRA-12996:


[~mshuler]
{quote}
{{ant realclean}}
{quote}
No, it doesn't help. I think the problem might be because there're 2 versions 
of slf4j-api in the classpatch:
{noformat}
$ ls build/lib/jars/slf4j-api-1.7.12.jar
build/lib/jars/slf4j-api-1.7.12.jar
$ ls lib/slf4j-api*
lib/slf4j-api-1.7.25.jar
{noformat}

> update slf4j dependency to 1.7.21
> -
>
> Key: CASSANDRA-12996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12996
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Tomas Repik
>Assignee: Stefan Podkowinski
> Fix For: 4.0
>
> Attachments: cassandra-3.11.0-slf4j.patch, 
> jcl-over-slf4j-1.7.25.jar.asc, log4j-over-slf4j-1.7.25.jar.asc, 
> slf4j-api-1.7.25.jar.asc
>
>
> Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to 
> the sources we need to do in order to successfully build it. Cassandra 
> depends on slf4j 1.7.7, but In Fedora we have the latest upstream version 
> 1.7.21 It was released some time ago on April 6 2016. I attached a patch 
> updating Cassandra sources to depend on the newer slf4j sources. The only 
> actual change is the number of parameters accepted by SubstituteLogger class. 
> Please consider updating.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13648) Upgrade metrics to 3.1.5

2017-07-21 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa commented on CASSANDRA-13648:


CHANGES was intentionally omitted because it always conflicts. The licenses 
weren't intentional. Changed that, kicked off new run here.

Also changed you to reviewer since you did most of the real work. 

Dtest @ 
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/146/


> Upgrade metrics to 3.1.5
> 
>
> Key: CASSANDRA-13648
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13648
> Project: Cassandra
>  Issue Type: Bug
>  Components: Libraries
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 4.x
>
> Attachments: metrics-core-3.1.5.jar.asc, metrics-jvm-3.1.5.jar.asc, 
> metrics-logback-3.1.5.jar.asc
>
>
> GH PR #123 indicates that metrics 3.1.5 will fix a reconnect bug:
> https://github.com/apache/cassandra/pull/123



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13648) Upgrade metrics to 3.1.5

2017-07-21 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa updated CASSANDRA-13648:
---
Reviewer: Stefan Podkowinski

> Upgrade metrics to 3.1.5
> 
>
> Key: CASSANDRA-13648
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13648
> Project: Cassandra
>  Issue Type: Bug
>  Components: Libraries
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 4.x
>
> Attachments: metrics-core-3.1.5.jar.asc, metrics-jvm-3.1.5.jar.asc, 
> metrics-logback-3.1.5.jar.asc
>
>
> GH PR #123 indicates that metrics 3.1.5 will fix a reconnect bug:
> https://github.com/apache/cassandra/pull/123



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13720) Clean up repair code

2017-07-21 Thread Simon Zhou (JIRA)


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

Simon Zhou commented on CASSANDRA-13720:


Not meant to be fixing something, but there are places that I want to make the 
code less confusing:

|4.0 |[patch | 
https://github.com/szhou1234/cassandra/commit/b9a410b74f42af7519010dff1fd03372ce38a412]|

[~spo...@gmail.com] Could you please review this patch? It's rebased on my 
patch for CASSANDRA-13387. Thank you.

> Clean up repair code
> 
>
> Key: CASSANDRA-13720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13720
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Simon Zhou
>Assignee: Simon Zhou
> Fix For: 4.0
>
>
> Lots of unused code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13720) Clean up repair code

2017-07-21 Thread Simon Zhou (JIRA)


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

Simon Zhou updated CASSANDRA-13720:
---
Status: Patch Available  (was: Open)

> Clean up repair code
> 
>
> Key: CASSANDRA-13720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13720
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Simon Zhou
>Assignee: Simon Zhou
> Fix For: 4.0
>
>
> Lots of unused code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13720) Clean up repair code

2017-07-21 Thread Simon Zhou (JIRA)

Simon Zhou created CASSANDRA-13720:
--

 Summary: Clean up repair code
 Key: CASSANDRA-13720
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13720
 Project: Cassandra
  Issue Type: Improvement
Reporter: Simon Zhou
Assignee: Simon Zhou
 Fix For: 4.0


Lots of unused code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13387) Metrics for repair

2017-07-21 Thread Simon Zhou (JIRA)


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

Simon Zhou commented on CASSANDRA-13387:


Just realized that's a public interface and I should keep it. Updated patch and 
rebased:

|4.0 |[patch | 
https://github.com/szhou1234/cassandra/commit/306ed07aa4a7a572d085c41fd0c1067719505262]|

Btw, repair code needs to be cleaned, e.g., there are some unused variables, 
etc. I'll open another ticket for this.

> Metrics for repair
> --
>
> Key: CASSANDRA-13387
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13387
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Simon Zhou
>Assignee: Simon Zhou
>Priority: Minor
>
> We're missing metrics for repair, especially for errors. From what I observed 
> now, the exception will be caught by UncaughtExceptionHandler set in 
> CassandraDaemon and is categorized as StorageMetrics.exceptions. This is one 
> example:
> {code}
> ERROR [AntiEntropyStage:1] 2017-03-27 18:17:08,385 CassandraDaemon.java:207 - 
> Exception in thread Thread[AntiEntropyStage:1,5,main]
> java.lang.RuntimeException: Parent repair session with id = 
> 8c85d260-1319-11e7-82a2-25090a89015f has failed.
> at 
> org.apache.cassandra.service.ActiveRepairService.getParentRepairSession(ActiveRepairService.java:377)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.service.ActiveRepairService.removeParentRepairSession(ActiveRepairService.java:392)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:172)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:67) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-12996) update slf4j dependency to 1.7.21

2017-07-21 Thread Michael Shuler (JIRA)


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

Michael Shuler commented on CASSANDRA-12996:


{{ant realclean}}

> update slf4j dependency to 1.7.21
> -
>
> Key: CASSANDRA-12996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12996
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Tomas Repik
>Assignee: Stefan Podkowinski
> Fix For: 4.0
>
> Attachments: cassandra-3.11.0-slf4j.patch, 
> jcl-over-slf4j-1.7.25.jar.asc, log4j-over-slf4j-1.7.25.jar.asc, 
> slf4j-api-1.7.25.jar.asc
>
>
> Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to 
> the sources we need to do in order to successfully build it. Cassandra 
> depends on slf4j 1.7.7, but In Fedora we have the latest upstream version 
> 1.7.21 It was released some time ago on April 6 2016. I attached a patch 
> updating Cassandra sources to depend on the newer slf4j sources. The only 
> actual change is the number of parameters accepted by SubstituteLogger class. 
> Please consider updating.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order

2017-07-21 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa commented on CASSANDRA-13717:


There are a bunch of cases in {{Tuples.java}} where we check {{instanceof 
TupleType}} that are probably wrong in the case that it's Reversed. I suspect 
we should be checking if the {{baseType}} (which is already public) of the 
{{ReversedType}} is a Tuple.


> INSERT statement fails when Tuple type is used as clustering column with 
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
> Attachments: example_queries.cql
>
>
> When a column family is created and a Tuple is used on clustering column with 
> default clustering order DESC, then the INSERT statement fails. 
> For example, the following table will make the INSERT statement fail with 
> error message "Invalid tuple type literal for tdemo of type 
> frozen>" , although the INSERT statement is correct 
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
>   id int,
>   tdemo tuple,
>   primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13703) Using min_compress_ratio <= 1 causes corruption

2017-07-21 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa updated CASSANDRA-13703:
---
Fix Version/s: 4.x

> Using min_compress_ratio <= 1 causes corruption
> ---
>
> Key: CASSANDRA-13703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13703
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Blocker
> Fix For: 4.x
>
> Attachments: patch
>
>
> This is because chunks written uncompressed end up below the compressed size 
> threshold. Demonstrated by applying the attached patch meant to improve the 
> testing of the 10520 changes, and running 
> {{CompressedSequentialWriterTest.testLZ4Writer}}.
> The default {{min_compress_ratio: 0}} is not affected as it never writes 
> uncompressed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13703) Using min_compress_ratio <= 1 causes corruption

2017-07-21 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa updated CASSANDRA-13703:
---
Priority: Blocker  (was: Major)

> Using min_compress_ratio <= 1 causes corruption
> ---
>
> Key: CASSANDRA-13703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13703
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Blocker
> Fix For: 4.x
>
> Attachments: patch
>
>
> This is because chunks written uncompressed end up below the compressed size 
> threshold. Demonstrated by applying the attached patch meant to improve the 
> testing of the 10520 changes, and running 
> {{CompressedSequentialWriterTest.testLZ4Writer}}.
> The default {{min_compress_ratio: 0}} is not affected as it never writes 
> uncompressed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-12996) update slf4j dependency to 1.7.21

2017-07-21 Thread Jay Zhuang (JIRA)


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

Jay Zhuang commented on CASSANDRA-12996:


Seems like there's jar hell while compile test:
{noformat}
build-test:
[javac] Compiling 522 source files to 
/Users/zjay/ws/cassandra/build/test/classes
[javac] 
/Users/zjay/ws/cassandra/test/unit/org/apache/cassandra/utils/NoSpamLoggerTest.java:42:
 error: constructor SubstituteLogger in class SubstituteLogger cannot be 
applied to given types;
[javac]Logger mock = new SubstituteLogger(null, null, true)
[javac]  ^
[javac]   required: String
[javac]   found: ,,boolean
[javac]   reason: actual and formal argument lists differ in length
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error
{noformat}
The classpath includes both {{slf4j-api-1.7.12.jar}} and 
{{slf4j-api-1.7.25.jar}}

> update slf4j dependency to 1.7.21
> -
>
> Key: CASSANDRA-12996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12996
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Libraries
>Reporter: Tomas Repik
>Assignee: Stefan Podkowinski
> Fix For: 4.0
>
> Attachments: cassandra-3.11.0-slf4j.patch, 
> jcl-over-slf4j-1.7.25.jar.asc, log4j-over-slf4j-1.7.25.jar.asc, 
> slf4j-api-1.7.25.jar.asc
>
>
> Cassandra 3.11.0 is about to be included in Fedora. There are some tweaks to 
> the sources we need to do in order to successfully build it. Cassandra 
> depends on slf4j 1.7.7, but In Fedora we have the latest upstream version 
> 1.7.21 It was released some time ago on April 6 2016. I attached a patch 
> updating Cassandra sources to depend on the newer slf4j sources. The only 
> actual change is the number of parameters accepted by SubstituteLogger class. 
> Please consider updating.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13715) Allow TRACE logging on upgrade dtests

2017-07-21 Thread Jason Brown (JIRA)


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

Jason Brown updated CASSANDRA-13715:

Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

commited as sha {{894bc92c9608103b3c5656d6dd0233e514a57848}}

> Allow TRACE logging on upgrade dtests
> -
>
> Key: CASSANDRA-13715
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13715
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

cassandra-dtest git commit: Allow TRACE logging on upgrade tests

2017-07-21 Thread jasobrown

Repository: cassandra-dtest
Updated Branches:
  refs/heads/master d040629b2 -> 894bc92c9


Allow TRACE logging on upgrade tests

patch by jasobrown, reviewed by mkjellman for CASSANDRA-13715


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

Branch: refs/heads/master
Commit: 894bc92c9608103b3c5656d6dd0233e514a57848
Parents: d040629
Author: Jason Brown 
Authored: Thu Jul 20 17:56:02 2017 -0700
Committer: Jason Brown 
Committed: Fri Jul 21 11:41:06 2017 -0700

--
 upgrade_tests/upgrade_base.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/894bc92c/upgrade_tests/upgrade_base.py
--
diff --git a/upgrade_tests/upgrade_base.py b/upgrade_tests/upgrade_base.py
index 6d37468..65957bd 100644
--- a/upgrade_tests/upgrade_base.py
+++ b/upgrade_tests/upgrade_base.py
@@ -7,7 +7,7 @@ from unittest import skipIf
 from ccmlib.common import get_version_from_build, is_win
 from tools.jmxutils import remove_perf_disable_shared_mem
 
-from dtest import CASSANDRA_VERSION_FROM_BUILD, DEBUG, Tester, debug, create_ks
+from dtest import CASSANDRA_VERSION_FROM_BUILD, TRACE, DEBUG, Tester, debug, 
create_ks
 
 
 def switch_jdks(major_version_int):
@@ -161,7 +161,7 @@ class UpgradeTester(Tester):
 if (new_version_from_build >= '3' and self.protocol_version is not 
None and self.protocol_version < 3):
 self.skip('Protocol version {} incompatible '
   'with Cassandra version 
{}'.format(self.protocol_version, new_version_from_build))
-node1.set_log_level("DEBUG" if DEBUG else "INFO")
+node1.set_log_level("DEBUG" if DEBUG else "TRACE" if TRACE else "INFO")
 node1.set_configuration_options(values={'internode_compression': 
'none'})
 
 if self.enable_for_jolokia:


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-11483) Enhance sstablemetadata

2017-07-21 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson commented on CASSANDRA-11483:
-

Pushed a code style fixup here: 
https://github.com/krummas/cassandra/commits/clohfink/11483

comments:
* the TimeUnit for printing out min/max timestamps are not guaranteed to be 
micros, maybe the user should be able to override the TimeUnit.MICROSECONDS 
from the command line?
* should we collect the 
{{widestPartitions}}/{{largestPartitions}}/{{mostTombstones}} during 
compaction/flush and always show them? Would be quite useful to not have to 
scan the sstable for this info. We should probably do that in a new ticket 
though
* {{SSTable min local deletion time}} and {{SSTable max local deletion time}} 
needs to special-case Long.MAX_VALUE I think - if we don't have a deletion, we 
should probably indicate that in the output instead of outputting "01/18/2038 
19:14:07"

> Enhance sstablemetadata
> ---
>
> Key: CASSANDRA-11483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11483
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Minor
> Fix For: 4.0
>
> Attachments: CASSANDRA-11483.txt, CASSANDRA-11483v2.txt, 
> CASSANDRA-11483v3.txt, CASSANDRA-11483v4.txt, CASSANDRA-11483v5.txt, Screen 
> Shot 2016-04-03 at 11.40.32 PM.png
>
>
> sstablemetadata provides quite a bit of useful information but theres a few 
> hiccups I would like to see addressed:
> * Does not use client mode
> * Units are not provided (or anything for that matter). There is data in 
> micros, millis, seconds as durations and timestamps from epoch. But there is 
> no way to tell what one is without a non-trival code dive
> * in general pretty frustrating to parse



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13719) Potential AssertionError during ReadRepair of range tombstone and partition deletions

2017-07-21 Thread Joshua McKenzie (JIRA)


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

Joshua McKenzie updated CASSANDRA-13719:

Reviewer: Branimir Lambov

> Potential AssertionError during ReadRepair of range tombstone and partition 
> deletions
> -
>
> Key: CASSANDRA-13719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13719
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.11.x
>
>
> When reconciling range tombstones for read repair in 
> {{DataResolver.RepairMergeListener.MergeListener}}, when we check if there is 
> ongoing deletion repair for a source, we don't look for partition level 
> deletions which throw off the logic and can throw an AssertionError.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13715) Allow TRACE logging on upgrade dtests

2017-07-21 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa commented on CASSANDRA-13715:


Kjellman says +1

(I also say +1)



> Allow TRACE logging on upgrade dtests
> -
>
> Key: CASSANDRA-13715
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13715
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13715) Allow TRACE logging on upgrade dtests

2017-07-21 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa updated CASSANDRA-13715:
---
Reviewer: Jeff Jirsa  (was: Michael Kjellman)

> Allow TRACE logging on upgrade dtests
> -
>
> Key: CASSANDRA-13715
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13715
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13715) Allow TRACE logging on upgrade dtests

2017-07-21 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa updated CASSANDRA-13715:
---
Status: Ready to Commit  (was: Patch Available)

> Allow TRACE logging on upgrade dtests
> -
>
> Key: CASSANDRA-13715
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13715
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13715) Allow TRACE logging on upgrade dtests

2017-07-21 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa updated CASSANDRA-13715:
---
Reviewer: Michael Kjellman  (was: Jeff Jirsa)
  Status: Patch Available  (was: Open)

> Allow TRACE logging on upgrade dtests
> -
>
> Key: CASSANDRA-13715
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13715
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13719) Potential AssertionError during ReadRepair of range tombstone and partition deletions

2017-07-21 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne updated CASSANDRA-13719:
-
Fix Version/s: 3.11.x
   3.0.x

> Potential AssertionError during ReadRepair of range tombstone and partition 
> deletions
> -
>
> Key: CASSANDRA-13719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13719
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.11.x
>
>
> When reconciling range tombstones for read repair in 
> {{DataResolver.RepairMergeListener.MergeListener}}, when we check if there is 
> ongoing deletion repair for a source, we don't look for partition level 
> deletions which throw off the logic and can throw an AssertionError.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13719) Potential AssertionError during ReadRepair of range tombstone and partition deletions

2017-07-21 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne updated CASSANDRA-13719:
-
Status: Patch Available  (was: Open)

> Potential AssertionError during ReadRepair of range tombstone and partition 
> deletions
> -
>
> Key: CASSANDRA-13719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13719
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.11.x
>
>
> When reconciling range tombstones for read repair in 
> {{DataResolver.RepairMergeListener.MergeListener}}, when we check if there is 
> ongoing deletion repair for a source, we don't look for partition level 
> deletions which throw off the logic and can throw an AssertionError.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13719) Potential AssertionError during ReadRepair of range tombstone and partition deletions

2017-07-21 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-13719:
--

Pushed fix on the following branches:
| [3.0|https://github.com/pcmanus/cassandra/tree/13719-3.0] | 
[3.11|https://github.com/pcmanus/cassandra/tree/13719-3.11] | 
[trunk|https://github.com/pcmanus/cassandra/tree/13719-trunk]|

There is a first commit that basically only add additional logging when the 
assertion that this triggers happen. I used it to debug the problem but I think 
it would be wise to commit it because it's the 2nd time we get an assertion 
error triggered in that method (the first being CASSANDRA-13719) and I'd rather 
we have more info to debug if this happens a 3rd time (not that I hope it 
will). The additional logging doesn't do anything unless an AssertionError is 
triggered, so it's kind of safe to add, it's just a minor code pollution if 
this is never useful again, which isn't a big deal.

The 2nd commit is the real fix and includes a unit test

> Potential AssertionError during ReadRepair of range tombstone and partition 
> deletions
> -
>
> Key: CASSANDRA-13719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13719
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>
> When reconciling range tombstones for read repair in 
> {{DataResolver.RepairMergeListener.MergeListener}}, when we check if there is 
> ongoing deletion repair for a source, we don't look for partition level 
> deletions which throw off the logic and can throw an AssertionError.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13719) Potential AssertionError during ReadRepair of range tombstone and partition deletions

2017-07-21 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne updated CASSANDRA-13719:
-
Description: When reconciling range tombstones for read repair in 
{{DataResolver.RepairMergeListener.MergeListener}}, when we check if there is 
ongoing deletion repair for a source, we don't look for partition level 
deletions which throw off the logic and can throw an AssertionError.

> Potential AssertionError during ReadRepair of range tombstone and partition 
> deletions
> -
>
> Key: CASSANDRA-13719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13719
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>
> When reconciling range tombstones for read repair in 
> {{DataResolver.RepairMergeListener.MergeListener}}, when we check if there is 
> ongoing deletion repair for a source, we don't look for partition level 
> deletions which throw off the logic and can throw an AssertionError.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13719) Potential AssertionError during ReadRepair of range tombstone and partition deletions

2017-07-21 Thread Sylvain Lebresne (JIRA)

Sylvain Lebresne created CASSANDRA-13719:


 Summary: Potential AssertionError during ReadRepair of range 
tombstone and partition deletions
 Key: CASSANDRA-13719
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13719
 Project: Cassandra
  Issue Type: Bug
  Components: Coordination
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13718) ConcurrentModificationException in nodetool upgradesstables

2017-07-21 Thread JIRA


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

Hannu Kröger updated CASSANDRA-13718:
-
Description: 
When upgrading from 2.2.8 to Cassandra 3.11 we were able to upgrade all other 
sstables except 1 file on 3 nodes (out of 4). Those are related to 2 different 
tables.

Upgrading sstables fails with ConcurrentModificationException.

{code}
$ nodetool upgradesstables
error: null
-- StackTrace --
java.util.ConcurrentModificationException
at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1211)
at java.util.TreeMap$KeyIterator.next(TreeMap.java:1265)
at 
org.apache.cassandra.utils.StreamingHistogram.flushHistogram(StreamingHistogram.java:168)
at 
org.apache.cassandra.utils.StreamingHistogram.update(StreamingHistogram.java:124)
at 
org.apache.cassandra.utils.StreamingHistogram.update(StreamingHistogram.java:96)
at 
org.apache.cassandra.io.sstable.metadata.MetadataCollector.updateLocalDeletionTime(MetadataCollector.java:209)
at 
org.apache.cassandra.io.sstable.metadata.MetadataCollector.update(MetadataCollector.java:182)
at org.apache.cassandra.db.rows.Cells.collectStats(Cells.java:44)
at 
org.apache.cassandra.db.rows.Rows.lambda$collectStats$0(Rows.java:102)
at org.apache.cassandra.utils.btree.BTree.applyForwards(BTree.java:1242)
at org.apache.cassandra.utils.btree.BTree.apply(BTree.java:1197)
at org.apache.cassandra.db.rows.BTreeRow.apply(BTreeRow.java:172)
at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:97)
at 
org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:237)
at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:141)
at 
org.apache.cassandra.db.ColumnIndex.buildRowIndex(ColumnIndex.java:110)
at 
org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:173)
at 
org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:135)
at 
org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:65)
at 
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:141)
at 
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:201)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at 
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
at 
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
at 
org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:428)
at 
org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:315)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
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 
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
at java.lang.Thread.run(Thread.java:745)
{code}

  was:
When upgrading from 2.2.8 to Cassandra 3.11 we were able to upgrade all other 
sstables except 1 file on 3 nodes (out of 4). Those are related to 2 different 
tables.

Upgrading sstables fails with ConcurrentModificationException.

{code}
$ nodetool upgradesstables;date
error: null
-- StackTrace --
java.util.ConcurrentModificationException
at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1211)
at java.util.TreeMap$KeyIterator.next(TreeMap.java:1265)
at 
org.apache.cassandra.utils.StreamingHistogram.flushHistogram(StreamingHistogram.java:168)
at 
org.apache.cassandra.utils.StreamingHistogram.update(StreamingHistogram.java:124)
at 
org.apache.cassandra.utils.StreamingHistogram.update(StreamingHistogram.java:96)
at 
org.apache.cassandra.io.sstable.metadata.MetadataCollector.updateLocalDeletionTime(MetadataCollector.java:209)
at 
org.apache.cassandra.io.sstable.metadata.MetadataCollector.update(MetadataCollector.java:182)
at org.apache.cassandra.db.rows.Cells.collectStats(Cells.java:44)
at 
org.apache.cassandra.db.rows.Rows.lambda$collectStats$0(Rows.java:102)
at org.apache.cassandra.utils.btree.BTree.applyForwards(BTree.java:1242)
at org.apache.cassandra.utils.btree.BTree.apply(BTree.java:1197)
at org.apache.cassandra.db.rows.BTreeRow.apply(BTreeRow.java:172)
at

[jira] [Created] (CASSANDRA-13718) ConcurrentModificationException in nodetool upgradesstables

2017-07-21 Thread JIRA

Hannu Kröger created CASSANDRA-13718:


 Summary: ConcurrentModificationException in nodetool 
upgradesstables
 Key: CASSANDRA-13718
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13718
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 3.11 on Linux
Reporter: Hannu Kröger


When upgrading from 2.2.8 to Cassandra 3.11 we were able to upgrade all other 
sstables except 1 file on 3 nodes (out of 4). Those are related to 2 different 
tables.

Upgrading sstables fails with ConcurrentModificationException.

{code}
$ nodetool upgradesstables;date
error: null
-- StackTrace --
java.util.ConcurrentModificationException
at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1211)
at java.util.TreeMap$KeyIterator.next(TreeMap.java:1265)
at 
org.apache.cassandra.utils.StreamingHistogram.flushHistogram(StreamingHistogram.java:168)
at 
org.apache.cassandra.utils.StreamingHistogram.update(StreamingHistogram.java:124)
at 
org.apache.cassandra.utils.StreamingHistogram.update(StreamingHistogram.java:96)
at 
org.apache.cassandra.io.sstable.metadata.MetadataCollector.updateLocalDeletionTime(MetadataCollector.java:209)
at 
org.apache.cassandra.io.sstable.metadata.MetadataCollector.update(MetadataCollector.java:182)
at org.apache.cassandra.db.rows.Cells.collectStats(Cells.java:44)
at 
org.apache.cassandra.db.rows.Rows.lambda$collectStats$0(Rows.java:102)
at org.apache.cassandra.utils.btree.BTree.applyForwards(BTree.java:1242)
at org.apache.cassandra.utils.btree.BTree.apply(BTree.java:1197)
at org.apache.cassandra.db.rows.BTreeRow.apply(BTreeRow.java:172)
at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:97)
at 
org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:237)
at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:141)
at 
org.apache.cassandra.db.ColumnIndex.buildRowIndex(ColumnIndex.java:110)
at 
org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:173)
at 
org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:135)
at 
org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:65)
at 
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:141)
at 
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:201)
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at 
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
at 
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
at 
org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:428)
at 
org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:315)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
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 
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
at java.lang.Thread.run(Thread.java:745)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order

2017-07-21 Thread Anastasios Kichidis (JIRA)


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

Anastasios Kichidis commented on CASSANDRA-13717:
-

After some quick debugging I saw that this error is thrown because of the tuple 
validation on Tuples.java:

{noformat}
if (!(receiver.type instanceof TupleType))
throw invalidRequest("Invalid tuple type literal for %s of type 
%s", receiver.name, receiver.type.asCQL3Type());
{noformat}

When the default ordering on tuple is DESC, the *receiver.type* is instance of 
type *ReversedType* and not *TupleType* . However, I don't have the expertise 
to know the cause of this.


> INSERT statement fails when Tuple type is used as clustering column with 
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
> Attachments: example_queries.cql
>
>
> When a column family is created and a Tuple is used on clustering column with 
> default clustering order DESC, then the INSERT statement fails. 
> For example, the following table will make the INSERT statement fail with 
> error message "Invalid tuple type literal for tdemo of type 
> frozen>" , although the INSERT statement is correct 
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
>   id int,
>   tdemo tuple,
>   primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order

2017-07-21 Thread Anastasios Kichidis (JIRA)

Anastasios Kichidis created CASSANDRA-13717:
---

 Summary: INSERT statement fails when Tuple type is used as 
clustering column with default DESC order
 Key: CASSANDRA-13717
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 3.11
Reporter: Anastasios Kichidis
 Attachments: example_queries.cql

When a column family is created and a Tuple is used on clustering column with 
default clustering order DESC, then the INSERT statement fails. 

For example, the following table will make the INSERT statement fail with error 
message "Invalid tuple type literal for tdemo of type frozen>" , although the INSERT statement is correct (works as expected when the 
default order is ASC)

{noformat}
create table test_table (
id int,
tdemo tuple,
primary key (id, tdemo)
) with clustering order by (tdemo desc);
{noformat}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13329) max_hints_delivery_threads does not work

2017-07-21 Thread Alex Petrov (JIRA)


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

Alex Petrov commented on CASSANDRA-13329:
-

Committed the backport to 3.0 with 
[b337c690d321f2e4d7e0a1b8a90f986d21e9|https://github.com/apache/cassandra/commit/b337c690d321f2e4d7e0a1b8a90f986d21e9],
 merged up to 
[3.11|https://github.com/apache/cassandra/commit/bf0a4b9cd6324e9c5adfe8cdd72ecb1c3a70568a]
 and 
[trunk|https://github.com/apache/cassandra/commit/8d2fa65f8a7abbc27b0c3ff0820af2945fcf7496].
 I've also taken a chance to make call syntax consistent across the branches 
(1-arg call instead of passing same var twice).

> max_hints_delivery_threads does not work
> 
>
> Key: CASSANDRA-13329
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13329
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Fuud
>Assignee: Aleksandr Sorokoumov
>  Labels: lhf
> Fix For: 3.11.0, 4.0
>
>
> HintsDispatchExecutor creates JMXEnabledThreadPoolExecutor with corePoolSize  
> == 1 and maxPoolSize==max_hints_delivery_threads and unbounded 
> LinkedBlockingQueue.
> In this configuration additional threads will not be created.
> Same problem with PerSSTableIndexWriter.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[1/6] cassandra git commit: Backport CASSANDRA-13329: Use JMXEnabledThreadPoolExecutor with corePoolSize equal to maxPoolSize

2017-07-21 Thread ifesdjeen

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 00a777ec8 -> b337c690d
  refs/heads/cassandra-3.11 478d54db4 -> bf0a4b9cd
  refs/heads/trunk 948fdfc67 -> 8d2fa65f8


Backport CASSANDRA-13329: Use JMXEnabledThreadPoolExecutor with corePoolSize 
equal to maxPoolSize

Patch by Aleksandr Sorokoumov; reviewed by Alex Petrov for CASSANDRA-13329

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

Branch: refs/heads/cassandra-3.0
Commit: b337c690d321f2e4d7e0a1b8a90f986d21e9
Parents: 00a777e
Author: Aleksandr Sorokoumov 
Authored: Mon Apr 10 21:46:23 2017 +0200
Committer: Alex Petrov 
Committed: Fri Jul 21 11:30:16 2017 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java | 5 +
 2 files changed, 2 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b337c690/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 9962f4b..efa57b3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.15
+ * JMXEnabledThreadPoolExecutor with corePoolSize equal to maxPoolSize 
(Backport CASSANDRA-13329)
  * Purge tombstones created by expired cells (CASSANDRA-13643)
  * Make concat work with iterators that have different subsets of columns 
(CASSANDRA-13482)
  * Set test.runners based on cores and memory size (CASSANDRA-13078)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b337c690/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
--
diff --git a/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java 
b/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
index 58b30bd..c9e69f5 100644
--- a/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
+++ b/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
@@ -56,10 +56,7 @@ final class HintsDispatchExecutor
 this.isPaused = isPaused;
 
 scheduledDispatches = new ConcurrentHashMap<>();
-executor = new JMXEnabledThreadPoolExecutor(1,
-maxThreads,
-1,
-TimeUnit.MINUTES,
+executor = new JMXEnabledThreadPoolExecutor(maxThreads, 1, 
TimeUnit.MINUTES,
 new 
LinkedBlockingQueue<>(),
 new 
NamedThreadFactory("HintsDispatcher", Thread.MIN_PRIORITY),
 "internal");


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

2017-07-21 Thread ifesdjeen

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/cassandra-3.11
Commit: bf0a4b9cd6324e9c5adfe8cdd72ecb1c3a70568a
Parents: 478d54d b337c69
Author: Alex Petrov 
Authored: Fri Jul 21 11:35:37 2017 +0200
Committer: Alex Petrov 
Committed: Fri Jul 21 11:35:37 2017 +0200

--
 src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bf0a4b9c/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
--
diff --cc src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
index 66835ef,c9e69f5..d6c28d4
--- a/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
+++ b/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
@@@ -57,10 -54,9 +57,10 @@@ final class HintsDispatchExecuto
  {
  this.hintsDirectory = hintsDirectory;
  this.isPaused = isPaused;
 +this.isAlive = isAlive;
  
  scheduledDispatches = new ConcurrentHashMap<>();
- executor = new JMXEnabledThreadPoolExecutor(maxThreads, maxThreads,1, 
TimeUnit.MINUTES,
+ executor = new JMXEnabledThreadPoolExecutor(maxThreads, 1, 
TimeUnit.MINUTES,
  new 
LinkedBlockingQueue<>(),
  new 
NamedThreadFactory("HintsDispatcher", Thread.MIN_PRIORITY),
  "internal");


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[2/6] cassandra git commit: Backport CASSANDRA-13329: Use JMXEnabledThreadPoolExecutor with corePoolSize equal to maxPoolSize

2017-07-21 Thread ifesdjeen

Backport CASSANDRA-13329: Use JMXEnabledThreadPoolExecutor with corePoolSize 
equal to maxPoolSize

Patch by Aleksandr Sorokoumov; reviewed by Alex Petrov for CASSANDRA-13329

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

Branch: refs/heads/cassandra-3.11
Commit: b337c690d321f2e4d7e0a1b8a90f986d21e9
Parents: 00a777e
Author: Aleksandr Sorokoumov 
Authored: Mon Apr 10 21:46:23 2017 +0200
Committer: Alex Petrov 
Committed: Fri Jul 21 11:30:16 2017 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java | 5 +
 2 files changed, 2 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b337c690/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 9962f4b..efa57b3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.15
+ * JMXEnabledThreadPoolExecutor with corePoolSize equal to maxPoolSize 
(Backport CASSANDRA-13329)
  * Purge tombstones created by expired cells (CASSANDRA-13643)
  * Make concat work with iterators that have different subsets of columns 
(CASSANDRA-13482)
  * Set test.runners based on cores and memory size (CASSANDRA-13078)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b337c690/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
--
diff --git a/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java 
b/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
index 58b30bd..c9e69f5 100644
--- a/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
+++ b/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
@@ -56,10 +56,7 @@ final class HintsDispatchExecutor
 this.isPaused = isPaused;
 
 scheduledDispatches = new ConcurrentHashMap<>();
-executor = new JMXEnabledThreadPoolExecutor(1,
-maxThreads,
-1,
-TimeUnit.MINUTES,
+executor = new JMXEnabledThreadPoolExecutor(maxThreads, 1, 
TimeUnit.MINUTES,
 new 
LinkedBlockingQueue<>(),
 new 
NamedThreadFactory("HintsDispatcher", Thread.MIN_PRIORITY),
 "internal");


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[6/6] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

2017-07-21 Thread ifesdjeen

Merge branch 'cassandra-3.11' into trunk


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

Branch: refs/heads/trunk
Commit: 8d2fa65f8a7abbc27b0c3ff0820af2945fcf7496
Parents: 948fdfc bf0a4b9
Author: Alex Petrov 
Authored: Fri Jul 21 11:36:00 2017 +0200
Committer: Alex Petrov 
Committed: Fri Jul 21 11:36:00 2017 +0200

--
 src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/8d2fa65f/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
--


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[3/6] cassandra git commit: Backport CASSANDRA-13329: Use JMXEnabledThreadPoolExecutor with corePoolSize equal to maxPoolSize

2017-07-21 Thread ifesdjeen

Backport CASSANDRA-13329: Use JMXEnabledThreadPoolExecutor with corePoolSize 
equal to maxPoolSize

Patch by Aleksandr Sorokoumov; reviewed by Alex Petrov for CASSANDRA-13329

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

Branch: refs/heads/trunk
Commit: b337c690d321f2e4d7e0a1b8a90f986d21e9
Parents: 00a777e
Author: Aleksandr Sorokoumov 
Authored: Mon Apr 10 21:46:23 2017 +0200
Committer: Alex Petrov 
Committed: Fri Jul 21 11:30:16 2017 +0200

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java | 5 +
 2 files changed, 2 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b337c690/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 9962f4b..efa57b3 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.15
+ * JMXEnabledThreadPoolExecutor with corePoolSize equal to maxPoolSize 
(Backport CASSANDRA-13329)
  * Purge tombstones created by expired cells (CASSANDRA-13643)
  * Make concat work with iterators that have different subsets of columns 
(CASSANDRA-13482)
  * Set test.runners based on cores and memory size (CASSANDRA-13078)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b337c690/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
--
diff --git a/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java 
b/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
index 58b30bd..c9e69f5 100644
--- a/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
+++ b/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
@@ -56,10 +56,7 @@ final class HintsDispatchExecutor
 this.isPaused = isPaused;
 
 scheduledDispatches = new ConcurrentHashMap<>();
-executor = new JMXEnabledThreadPoolExecutor(1,
-maxThreads,
-1,
-TimeUnit.MINUTES,
+executor = new JMXEnabledThreadPoolExecutor(maxThreads, 1, 
TimeUnit.MINUTES,
 new 
LinkedBlockingQueue<>(),
 new 
NamedThreadFactory("HintsDispatcher", Thread.MIN_PRIORITY),
 "internal");


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

2017-07-21 Thread ifesdjeen

Merge branch 'cassandra-3.0' into cassandra-3.11


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

Branch: refs/heads/trunk
Commit: bf0a4b9cd6324e9c5adfe8cdd72ecb1c3a70568a
Parents: 478d54d b337c69
Author: Alex Petrov 
Authored: Fri Jul 21 11:35:37 2017 +0200
Committer: Alex Petrov 
Committed: Fri Jul 21 11:35:37 2017 +0200

--
 src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/bf0a4b9c/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
--
diff --cc src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
index 66835ef,c9e69f5..d6c28d4
--- a/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
+++ b/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java
@@@ -57,10 -54,9 +57,10 @@@ final class HintsDispatchExecuto
  {
  this.hintsDirectory = hintsDirectory;
  this.isPaused = isPaused;
 +this.isAlive = isAlive;
  
  scheduledDispatches = new ConcurrentHashMap<>();
- executor = new JMXEnabledThreadPoolExecutor(maxThreads, maxThreads,1, 
TimeUnit.MINUTES,
+ executor = new JMXEnabledThreadPoolExecutor(maxThreads, 1, 
TimeUnit.MINUTES,
  new 
LinkedBlockingQueue<>(),
  new 
NamedThreadFactory("HintsDispatcher", Thread.MIN_PRIORITY),
  "internal");


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13703) Using min_compress_ratio <= 1 causes corruption

2017-07-21 Thread Branimir Lambov (JIRA)


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

Branimir Lambov updated CASSANDRA-13703:

Reviewer: T Jake Luciani  (was: Alex Petrov)

> Using min_compress_ratio <= 1 causes corruption
> ---
>
> Key: CASSANDRA-13703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13703
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
> Attachments: patch
>
>
> This is because chunks written uncompressed end up below the compressed size 
> threshold. Demonstrated by applying the attached patch meant to improve the 
> testing of the 10520 changes, and running 
> {{CompressedSequentialWriterTest.testLZ4Writer}}.
> The default {{min_compress_ratio: 0}} is not affected as it never writes 
> uncompressed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13703) Using min_compress_ratio <= 1 causes corruption

2017-07-21 Thread Branimir Lambov (JIRA)


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

Branimir Lambov updated CASSANDRA-13703:

Reviewer: Alex Petrov
  Status: Patch Available  (was: In Progress)

Patch [here|https://github.com/blambov/cassandra/tree/13703].

Changes the max size threshold to be non-inclusive so that 
{{min_compress_ratio: 1}} can work (this would be a breaking change, but 
CASSANRDA-10520 is not part of any release yet), and adds an error for values 
between 0 and 1 exclusive.

Unit tests are clean, dtests have two failures that appear to be flaky on trunk:
{{repair_tests.incremental_repair_test.TestIncRepair.multiple_repair_test}}
{{bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test}}

> Using min_compress_ratio <= 1 causes corruption
> ---
>
> Key: CASSANDRA-13703
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13703
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
> Attachments: patch
>
>
> This is because chunks written uncompressed end up below the compressed size 
> threshold. Demonstrated by applying the attached patch meant to improve the 
> testing of the 10520 changes, and running 
> {{CompressedSequentialWriterTest.testLZ4Writer}}.
> The default {{min_compress_ratio: 0}} is not affected as it never writes 
> uncompressed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-9988) Introduce leaf-only iterator

2017-07-21 Thread Jay Zhuang (JIRA)


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

Jay Zhuang commented on CASSANDRA-9988:
---

[~Anthony Grasso] Thank you for the review. I updated branch 
[9988-trunk|https://github.com/cooldoger/cassandra/tree/9988-trunk], will share 
the test result later.

> Introduce leaf-only iterator
> 
>
> Key: CASSANDRA-9988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9988
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
>  Labels: patch
> Fix For: 4.0
>
> Attachments: 9988-trunk-new.txt, 9988-trunk-new-update.txt, 
> trunk-9988.txt
>
>
> In many cases we have small btrees, small enough to fit in a single leaf 
> page. In this case it _may_ be more efficient to specialise our iterator.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13526) nodetool cleanup on KS with no replicas should remove old data, not silently complete

2017-07-21 Thread ZhaoYang (JIRA)


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

ZhaoYang edited comment on CASSANDRA-13526 at 7/21/17 6:10 AM:
---

| branch | unit | 
[dtest|https://github.com/jasonstack/cassandra-dtest/commits/CASSANDRA-13526] |
| [trunk|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526] |  
[pass|https://circleci.com/gh/jasonstack/cassandra/182] | 
bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test
 known |
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526-3.11]|  
[pass|https://circleci.com/gh/jasonstack/cassandra/186] | pass |
| [3.0|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526-3.0]|  
[pass|https://circleci.com/gh/jasonstack/cassandra/181] | 
offline_tools_test.TestOfflineTools.sstableofflinerelevel_test  
auth_test.TestAuth.system_auth_ks_is_alterable_test |
| [2.2|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526-2.2]|  
[pass|https://circleci.com/gh/jasonstack/cassandra/185] |  
repair_tests.incremental_repair_test.TestIncRepair.multiple_repair_test  
ttl_test.TestTTL.collection_list_ttl_test |

unit test all padded, some irrelevant dtests failed.

when no local range && node has joined token ring,  clean up will remove all 
base local sstables.  


was (Author: jasonstack):
| branch | unit | 
[dtest|https://github.com/jasonstack/cassandra-dtest/commits/CASSANDRA-13526] |
| [trunk|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526] |  
[pass|https://circleci.com/gh/jasonstack/cassandra/182] | 
bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test
 known |
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526-3.11]|  
[running|https://circleci.com/gh/jasonstack/cassandra/186] | running |
| [3.0|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526-3.0]|  
[pass|https://circleci.com/gh/jasonstack/cassandra/181] | running |
| [2.2|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526-2.2]|  
[pass|https://circleci.com/gh/jasonstack/cassandra/185] | running |


when no local range && node has joined token ring,  clean up will remove all 
base local sstables.  

> nodetool cleanup on KS with no replicas should remove old data, not silently 
> complete
> -
>
> Key: CASSANDRA-13526
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13526
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jeff Jirsa
>Assignee: ZhaoYang
>  Labels: usability
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> From the user list:
> https://lists.apache.org/thread.html/5d49cc6bbc6fd2e5f8b12f2308a3e24212a55afbb441af5cb8cd4167@%3Cuser.cassandra.apache.org%3E
> If you have a multi-dc cluster, but some keyspaces not replicated to a given 
> DC, you'll be unable to run cleanup on those keyspaces in that DC, because 
> [the cleanup code will see no ranges and exit 
> early|https://github.com/apache/cassandra/blob/4cfaf85/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L427-L441]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13526) nodetool cleanup on KS with no replicas should remove old data, not silently complete

2017-07-21 Thread ZhaoYang (JIRA)


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

ZhaoYang edited comment on CASSANDRA-13526 at 7/21/17 6:10 AM:
---

| branch | unit | 
[dtest|https://github.com/jasonstack/cassandra-dtest/commits/CASSANDRA-13526] |
| [trunk|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526] |  
[pass|https://circleci.com/gh/jasonstack/cassandra/182] | 
bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test
 known |
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526-3.11]|  
[pass|https://circleci.com/gh/jasonstack/cassandra/186] | pass |
| [3.0|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526-3.0]|  
[pass|https://circleci.com/gh/jasonstack/cassandra/181] | 
offline_tools_test.TestOfflineTools.sstableofflinerelevel_test  
auth_test.TestAuth.system_auth_ks_is_alterable_test |
| [2.2|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526-2.2]|  
[pass|https://circleci.com/gh/jasonstack/cassandra/185] |  
repair_tests.incremental_repair_test.TestIncRepair.multiple_repair_test  
ttl_test.TestTTL.collection_list_ttl_test |

unit test all passed, some irrelevant dtests failed.

when no local range && node has joined token ring,  clean up will remove all 
base local sstables.  


was (Author: jasonstack):
| branch | unit | 
[dtest|https://github.com/jasonstack/cassandra-dtest/commits/CASSANDRA-13526] |
| [trunk|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526] |  
[pass|https://circleci.com/gh/jasonstack/cassandra/182] | 
bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test
 known |
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526-3.11]|  
[pass|https://circleci.com/gh/jasonstack/cassandra/186] | pass |
| [3.0|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526-3.0]|  
[pass|https://circleci.com/gh/jasonstack/cassandra/181] | 
offline_tools_test.TestOfflineTools.sstableofflinerelevel_test  
auth_test.TestAuth.system_auth_ks_is_alterable_test |
| [2.2|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13526-2.2]|  
[pass|https://circleci.com/gh/jasonstack/cassandra/185] |  
repair_tests.incremental_repair_test.TestIncRepair.multiple_repair_test  
ttl_test.TestTTL.collection_list_ttl_test |

unit test all padded, some irrelevant dtests failed.

when no local range && node has joined token ring,  clean up will remove all 
base local sstables.  

> nodetool cleanup on KS with no replicas should remove old data, not silently 
> complete
> -
>
> Key: CASSANDRA-13526
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13526
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jeff Jirsa
>Assignee: ZhaoYang
>  Labels: usability
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> From the user list:
> https://lists.apache.org/thread.html/5d49cc6bbc6fd2e5f8b12f2308a3e24212a55afbb441af5cb8cd4167@%3Cuser.cassandra.apache.org%3E
> If you have a multi-dc cluster, but some keyspaces not replicated to a given 
> DC, you'll be unable to run cleanup on those keyspaces in that DC, because 
> [the cleanup code will see no ranges and exit 
> early|https://github.com/apache/cassandra/blob/4cfaf85/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L427-L441]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-11223) Queries with LIMIT filtering on clustering columns can return less rows than expected

2017-07-21 Thread Stefania (JIRA)


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

Stefania edited comment on CASSANDRA-11223 at 7/21/17 6:03 AM:
---

The problem does not affect 2.2 because NamesQueryFilter.getLiveCount() is 
unchanged, and in any case GroupByPrefix will count 1 live row if toGroup is 
zero, which would be the case for the GroupByPrefix used by 
NamesQueryFilter.columnCounter(). The queries on this type of tables will never 
use SliceQueryFilter.

For 3.0+, it's a bit of a pain to revert, so I have created the follow-up 
[patch|https://github.com/apache/cassandra/compare/trunk...stef1927:11223-3.0]. 
CI is currently running. 

The patch ensures that static rows are always counted for static compact tables 
(which is sufficient to fix the problem) but also assumes that a 
NamesQueryFilter is selecting the entire partition if it has no clustering 
values. This second part is not necessary but I think it's more correct because 
in this case NamesQueryFilter is not restricting anything, and prior usages of 
selectsAllPartition are limited to check if the filter restricts anything, in 
order to create CQL string representations of a query.

Benjamin should be back in 1 week,  but I can find a reviewer sooner if 
required.


was (Author: stefania):
The problem does not affect 2.2 because NamesQueryFilter.getLiveCount() is 
unchanged, and in any case GroupByPrefix will count 1 live row if toGroup is 
zero, which would be the case for the GroupByPrefix used by 
NamesQueryFilter.columnCounter(). The queries on this type of tables will never 
use SliceQueryFilter.

For 3.0+, it's a bit of a pain to revert, so I have created the follow-up 
[patch|https://github.com/apache/cassandra/compare/trunk...stef1927:11223-3.0]. 
CI is currently running. 

The patch ensures that static rows are always counted for static compact tables 
(which is sufficient to fix the problem) but also assumes that a 
NamesQueryFilter is selecting the entire partition if it has no clustering 
values. This second part is not necessary but I think it's more correct because 
in this case NamesQueryFilter is not restricting anything, and existing usages 
of selectsAllPartition where limited to check if the filter restricts anything, 
in order to create CQL string representations of a query.

Benjamin should be back in 1 week,  but I can find a reviewer sooner if 
required.

> Queries with LIMIT filtering on clustering columns can return less rows than 
> expected
> -
>
> Key: CASSANDRA-11223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11223
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 2.2.11, 3.0.15, 3.11.1, 4.0
>
>
> A query like {{SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW FILTERING}} can 
> return less row than expected if the table has some static columns and some 
> of the partition have no rows matching b = 1.
> The problem can be reproduced with the following unit test:
> {code}
> public void testFilteringOnClusteringColumnsWithLimitAndStaticColumns() 
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, s int static, c int, 
> primary key (a, b))");
> for (int i = 0; i < 3; i++)
> {
> execute("INSERT INTO %s (a, s) VALUES (?, ?)", i, i);
> for (int j = 0; j < 3; j++)
> if (!(i == 0 && j == 1))
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)", 
> i, j, i + j);
> }
> assertRows(execute("SELECT * FROM %s"),
>    row(1, 0, 1, 1),
>    row(1, 1, 1, 2),
>    row(1, 2, 1, 3),
>    row(0, 0, 0, 0),
>    row(0, 2, 0, 2),
>    row(2, 0, 2, 2),
>    row(2, 1, 2, 3),
>    row(2, 2, 2, 4));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 ALLOW FILTERING"),
>    row(1, 1, 1, 2),
>    row(2, 1, 2, 3));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW 
> FILTERING"),
>    row(1, 1, 1, 2),
>    row(2, 1, 2, 3)); // < FAIL It returns only one 
> row because the static row of partition 0 is counted and filtered out in 
> SELECT statement
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

57 matches

Mail list logo