[jira] [Updated] (CASSANDRA-14689) Add developer docs for creating releases

2018-09-04 Thread mck (JIRA)


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

mck updated CASSANDRA-14689:

Reviewers: Michael Shuler, Stefan Podkowinski

> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Assignee: mck
>Priority: Minor
> Fix For: 4.x
>
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Assigned] (CASSANDRA-14689) Add developer docs for creating releases

2018-09-04 Thread mck (JIRA)


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

mck reassigned CASSANDRA-14689:
---

Assignee: mck

> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Assignee: mck
>Priority: Minor
> Fix For: 4.x
>
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (CASSANDRA-14689) Add developer docs for creating releases

2018-09-04 Thread mck (JIRA)


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

mck updated CASSANDRA-14689:

Fix Version/s: 4.x

> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Priority: Minor
> Fix For: 4.x
>
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (CASSANDRA-14689) Add developer docs for creating releases

2018-09-04 Thread mck (JIRA)


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

mck updated CASSANDRA-14689:

Description: 
Provide an initial outline on the steps Release Managers follow for creating, 
voting and publishing a release for Apache Cassandra.


ASF has the following guidelines:
 * `ASF Release Policy `_.
 * `ASF Release Distribution Policy 
`_.
 * `ASF Release Best Practices 
`_.

The project is still doing some things in an outdated manner, eg using 
people.apache.org URLs for staging artefacts. There is no urgent need to fix 
these things but by having the docs published it can improved incrementally 
over time.

fyi [~mshuler]

  was:

Provide an initial outline on the steps Release Managers follow for creating, 
voting and publishing a release for Apache Cassandra.


ASF has the following guidelines:
 * `ASF Release Policy `_.
 * `ASF Release Distribution Policy 
`_.
 * `ASF Release Best Practices 
`_.

The project is still doing some things in an outdated manner, eg using 
people.apache.org URLs for staging artefacts. There is no urgent need to fix 
these things but by having the docs published it can improved incrementally 
over time.


> Add developer docs for creating releases
> 
>
> Key: CASSANDRA-14689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: mck
>Priority: Minor
> Fix For: 4.x
>
>
> Provide an initial outline on the steps Release Managers follow for creating, 
> voting and publishing a release for Apache Cassandra.
> ASF has the following guidelines:
>  * `ASF Release Policy `_.
>  * `ASF Release Distribution Policy 
> `_.
>  * `ASF Release Best Practices 
> `_.
> The project is still doing some things in an outdated manner, eg using 
> people.apache.org URLs for staging artefacts. There is no urgent need to fix 
> these things but by having the docs published it can improved incrementally 
> over time.
> fyi [~mshuler]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (CASSANDRA-14689) Add developer docs for creating releases

2018-09-04 Thread mck (JIRA)
mck created CASSANDRA-14689:
---

 Summary: Add developer docs for creating releases
 Key: CASSANDRA-14689
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14689
 Project: Cassandra
  Issue Type: Task
  Components: Documentation and Website
Reporter: mck



Provide an initial outline on the steps Release Managers follow for creating, 
voting and publishing a release for Apache Cassandra.


ASF has the following guidelines:
 * `ASF Release Policy `_.
 * `ASF Release Distribution Policy 
`_.
 * `ASF Release Best Practices 
`_.

The project is still doing some things in an outdated manner, eg using 
people.apache.org URLs for staging artefacts. There is no urgent need to fix 
these things but by having the docs published it can improved incrementally 
over time.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (CASSANDRA-13262) Incorrect cqlsh results when selecting same columns multiple times

2018-09-04 Thread mck (JIRA)


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

mck commented on CASSANDRA-13262:
-

Committed to 2.2, 3.0 and 3.11, with 62e48c5f3f818d1e841178d7365d208435a63537

> Incorrect cqlsh results when selecting same columns multiple times
> --
>
> Key: CASSANDRA-13262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13262
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefan Podkowinski
>Assignee: Murukesh Mohanan
>Priority: Minor
>  Labels: lhf
> Fix For: 2.2.14, 3.0.18, 3.11.4, 4.0
>
> Attachments: 
> 0001-Fix-incorrect-cqlsh-results-when-selecting-same-colu.patch, 
> CASSANDRA-13262-v2.2.txt, CASSANDRA-13262-v3.0.txt, CASSANDRA-13262-v3.11.txt
>
>
> Just stumbled over this on trunk:
> {quote}
> cqlsh:test1> select a, b, c from table1;
>  a | b| c
> ---+--+-
>  1 |b |   2
>  2 | null | 2.2
> (2 rows)
> cqlsh:test1> select a, a, b, c from table1;
>  a | a| b   | c
> ---+--+-+--
>  1 |b |   2 | null
>  2 | null | 2.2 | null
> (2 rows)
> cqlsh:test1> select a, a, a, b, c from table1;
>  a | a| a | b| c
> ---+--+---+--+--
>  1 |b |   2.0 | null | null
>  2 | null | 2.2004768 | null | null
> {quote}
> My guess is that his is on the Python side, but haven't really looked into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (CASSANDRA-13262) Incorrect cqlsh results when selecting same columns multiple times

2018-09-04 Thread mck (JIRA)


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

mck updated CASSANDRA-13262:

Fix Version/s: 3.11.4
   3.0.18
   2.2.14

> Incorrect cqlsh results when selecting same columns multiple times
> --
>
> Key: CASSANDRA-13262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13262
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefan Podkowinski
>Assignee: Murukesh Mohanan
>Priority: Minor
>  Labels: lhf
> Fix For: 2.2.14, 3.0.18, 3.11.4, 4.0
>
> Attachments: 
> 0001-Fix-incorrect-cqlsh-results-when-selecting-same-colu.patch, 
> CASSANDRA-13262-v2.2.txt, CASSANDRA-13262-v3.0.txt, CASSANDRA-13262-v3.11.txt
>
>
> Just stumbled over this on trunk:
> {quote}
> cqlsh:test1> select a, b, c from table1;
>  a | b| c
> ---+--+-
>  1 |b |   2
>  2 | null | 2.2
> (2 rows)
> cqlsh:test1> select a, a, b, c from table1;
>  a | a| b   | c
> ---+--+-+--
>  1 |b |   2 | null
>  2 | null | 2.2 | null
> (2 rows)
> cqlsh:test1> select a, a, a, b, c from table1;
>  a | a| a | b| c
> ---+--+---+--+--
>  1 |b |   2.0 | null | null
>  2 | null | 2.2004768 | null | null
> {quote}
> My guess is that his is on the Python side, but haven't really looked into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



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

2018-09-04 Thread mck
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/744973e4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/744973e4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/744973e4

Branch: refs/heads/trunk
Commit: 744973e4cb659c774e817b4fc553c6361f1f05ec
Parents: d26f142 0aca1b9
Author: Mick Semb Wever 
Authored: Wed Sep 5 11:25:17 2018 +1000
Committer: Mick Semb Wever 
Committed: Wed Sep 5 11:25:17 2018 +1000

--

--



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



[jira] [Comment Edited] (CASSANDRA-13262) Incorrect cqlsh results when selecting same columns multiple times

2018-09-04 Thread mck (JIRA)


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

mck edited comment on CASSANDRA-13262 at 9/5/18 1:28 AM:
-

New dtests running…

|| branch || testall || dtest ||
| 
[cassandra-2.2_13262|https://github.com/thelastpickle/cassandra/tree/mck/cassandra-2.2_13262]
 | 
[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-2.2_13262.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-2.2_13262]
   | 
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/628/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/628/]
 |
| 
[cassandra-3.0_13262|https://github.com/thelastpickle/cassandra/tree/mck/cassandra-3.0_13262]
 | 
[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.0_13262.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.0_13262]
   | 
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/632/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/632/]
 |
| 
[cassandra-3.11_13262|https://github.com/thelastpickle/cassandra/tree/mck/cassandra-3.11_13262]
   | 
[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.11_13262.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.11_13262]
 | 
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/630/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/630/]
 |


EDIT: rebased branches.


was (Author: michaelsembwever):
New dtests running…

|| branch || testall || dtest ||
| 
[cassandra-2.2_13262|https://github.com/thelastpickle/cassandra/tree/mck/cassandra-2.2_13262]
 | 
[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-2.2_13262.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-2.2_13262]
   | 
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/628/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/628/]
 |
| 
[cassandra-3.0_13262|https://github.com/thelastpickle/cassandra/tree/mck/cassandra-3.0_13262]
 | 
[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.0_13262.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.0_13262]
   | 
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/629/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/629/]
 |
| 
[cassandra-3.11_13262|https://github.com/thelastpickle/cassandra/tree/mck/cassandra-3.11_13262]
   | 
[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.11_13262.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.11_13262]
 | 
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/630/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/630/]
 |


EDIT: rebased branches.

> Incorrect cqlsh results when selecting same columns multiple times
> --
>
> Key: CASSANDRA-13262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13262
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefan Podkowinski
>Assignee: Murukesh Mohanan
>Priority: Minor
>  Labels: lhf
> Fix For: 4.0
>
> Attachments: 
> 0001-Fix-incorrect-cqlsh-results-when-selecting-same-colu.patch, 
> CASSANDRA-13262-v2.2.txt, CASSANDRA-13262-v3.0.txt, CASSANDRA-13262-v3.11.txt
>
>
> Just stumbled over this on trunk:
> {quote}
> cqlsh:test1> select a, b, c from table1;
>  a | b| c
> ---+--+-
>  1 |b |   2
>  2 | null | 2.2
> (2 rows)
> cqlsh:test1> select a, a, b, c from table1;
>  a | a| b   | c
> ---+--+-+--
>  1 |b |   2 | null
>  2 | null | 2.2 | null
> (2 rows)
> cqlsh:test1> select a, a, a, b, c from table1;
>  a | a| a | b| c
> ---+--+---+--+--
>  1 |b |   2.0 | null | null
>  2 | null | 2.2004768 | null | null
> {quote}
> My guess is that his is on the Python side, but haven't really looked into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[03/10] cassandra git commit: Fix incorrect cqlsh results when selecting same columns multiple times

2018-09-04 Thread mck
Fix incorrect cqlsh results when selecting same columns multiple times

Patch by Anthony Grasso; reviewed by Mick Semb Wever for CASSANDRA-13262


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

Branch: refs/heads/cassandra-3.11
Commit: 62e48c5f3f818d1e841178d7365d208435a63537
Parents: 49adbe7
Author: Mick Semb Wever 
Authored: Wed Sep 5 11:13:49 2018 +1000
Committer: Mick Semb Wever 
Committed: Wed Sep 5 11:13:49 2018 +1000

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/62e48c5f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f3de388..71c57ea 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.14
+ * Fix incorrect cqlsh results when selecting same columns multiple times 
(CASSANDRA-13262)
  * Returns null instead of NaN or Infinity in JSON strings (CASSANDRA-14377)
 
 2.2.13

http://git-wip-us.apache.org/repos/asf/cassandra/blob/62e48c5f/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index e242d42..3d0e056 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -1313,7 +1313,7 @@ class Shell(cmd.Cmd):
 # print header only
 self.print_formatted_result(formatted_names, None)
 return
-formatted_values = [map(self.myformat_value, row.values()) for row in 
rows]
+formatted_values = [map(self.myformat_value, [row[column] for column 
in column_names]) for row in rows]
 
 if self.expand_enabled:
 self.print_formatted_result_vertically(formatted_names, 
formatted_values)


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



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

2018-09-04 Thread mck
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/0aca1b9d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0aca1b9d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0aca1b9d

Branch: refs/heads/trunk
Commit: 0aca1b9df8b594710e6fbe820bd54ed17dc3176e
Parents: d8b7630 21ec39a
Author: Mick Semb Wever 
Authored: Wed Sep 5 11:19:22 2018 +1000
Committer: Mick Semb Wever 
Committed: Wed Sep 5 11:20:12 2018 +1000

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0aca1b9d/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0aca1b9d/bin/cqlsh.py
--
diff --cc bin/cqlsh.py
index 801a8f7,1f1fa47..71f8491
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@@ -1116,14 -1374,7 +1116,14 @@@ class Shell(cmd.Cmd)
  # print header only
  self.print_formatted_result(formatted_names, None)
  return
 -formatted_values = [map(self.myformat_value, [row[column] for column 
in column_names]) for row in rows]
 +
 +cql_types = []
 +if result.column_types:
 +ks_name = table_meta.keyspace_name if table_meta else 
self.current_keyspace
 +ks_meta = self.conn.metadata.keyspaces.get(ks_name, None)
 +cql_types = [CqlType(cql_typename(t), ks_meta) for t in 
result.column_types]
 +
- formatted_values = [map(self.myformat_value, row.values(), cql_types) 
for row in result.current_rows]
++formatted_values = [map(self.myformat_value, [row[column] for column 
in column_names], cql_types) for row in result.current_rows]
  
  if self.expand_enabled:
  self.print_formatted_result_vertically(formatted_names, 
formatted_values)


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



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

2018-09-04 Thread mck
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/0aca1b9d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0aca1b9d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0aca1b9d

Branch: refs/heads/cassandra-3.11
Commit: 0aca1b9df8b594710e6fbe820bd54ed17dc3176e
Parents: d8b7630 21ec39a
Author: Mick Semb Wever 
Authored: Wed Sep 5 11:19:22 2018 +1000
Committer: Mick Semb Wever 
Committed: Wed Sep 5 11:20:12 2018 +1000

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0aca1b9d/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0aca1b9d/bin/cqlsh.py
--
diff --cc bin/cqlsh.py
index 801a8f7,1f1fa47..71f8491
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@@ -1116,14 -1374,7 +1116,14 @@@ class Shell(cmd.Cmd)
  # print header only
  self.print_formatted_result(formatted_names, None)
  return
 -formatted_values = [map(self.myformat_value, [row[column] for column 
in column_names]) for row in rows]
 +
 +cql_types = []
 +if result.column_types:
 +ks_name = table_meta.keyspace_name if table_meta else 
self.current_keyspace
 +ks_meta = self.conn.metadata.keyspaces.get(ks_name, None)
 +cql_types = [CqlType(cql_typename(t), ks_meta) for t in 
result.column_types]
 +
- formatted_values = [map(self.myformat_value, row.values(), cql_types) 
for row in result.current_rows]
++formatted_values = [map(self.myformat_value, [row[column] for column 
in column_names], cql_types) for row in result.current_rows]
  
  if self.expand_enabled:
  self.print_formatted_result_vertically(formatted_names, 
formatted_values)


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



[01/10] cassandra git commit: Fix incorrect cqlsh results when selecting same columns multiple times

2018-09-04 Thread mck
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 49adbe7e0 -> 62e48c5f3
  refs/heads/cassandra-3.0 d049c6b9b -> 21ec39a9d
  refs/heads/cassandra-3.11 d8b7630fe -> 0aca1b9df
  refs/heads/trunk d26f142b3 -> 744973e4c


Fix incorrect cqlsh results when selecting same columns multiple times

Patch by Anthony Grasso; reviewed by Mick Semb Wever for CASSANDRA-13262


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

Branch: refs/heads/cassandra-2.2
Commit: 62e48c5f3f818d1e841178d7365d208435a63537
Parents: 49adbe7
Author: Mick Semb Wever 
Authored: Wed Sep 5 11:13:49 2018 +1000
Committer: Mick Semb Wever 
Committed: Wed Sep 5 11:13:49 2018 +1000

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/62e48c5f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f3de388..71c57ea 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.14
+ * Fix incorrect cqlsh results when selecting same columns multiple times 
(CASSANDRA-13262)
  * Returns null instead of NaN or Infinity in JSON strings (CASSANDRA-14377)
 
 2.2.13

http://git-wip-us.apache.org/repos/asf/cassandra/blob/62e48c5f/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index e242d42..3d0e056 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -1313,7 +1313,7 @@ class Shell(cmd.Cmd):
 # print header only
 self.print_formatted_result(formatted_names, None)
 return
-formatted_values = [map(self.myformat_value, row.values()) for row in 
rows]
+formatted_values = [map(self.myformat_value, [row[column] for column 
in column_names]) for row in rows]
 
 if self.expand_enabled:
 self.print_formatted_result_vertically(formatted_names, 
formatted_values)


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



[04/10] cassandra git commit: Fix incorrect cqlsh results when selecting same columns multiple times

2018-09-04 Thread mck
Fix incorrect cqlsh results when selecting same columns multiple times

Patch by Anthony Grasso; reviewed by Mick Semb Wever for CASSANDRA-13262


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

Branch: refs/heads/trunk
Commit: 62e48c5f3f818d1e841178d7365d208435a63537
Parents: 49adbe7
Author: Mick Semb Wever 
Authored: Wed Sep 5 11:13:49 2018 +1000
Committer: Mick Semb Wever 
Committed: Wed Sep 5 11:13:49 2018 +1000

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/62e48c5f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f3de388..71c57ea 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.14
+ * Fix incorrect cqlsh results when selecting same columns multiple times 
(CASSANDRA-13262)
  * Returns null instead of NaN or Infinity in JSON strings (CASSANDRA-14377)
 
 2.2.13

http://git-wip-us.apache.org/repos/asf/cassandra/blob/62e48c5f/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index e242d42..3d0e056 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -1313,7 +1313,7 @@ class Shell(cmd.Cmd):
 # print header only
 self.print_formatted_result(formatted_names, None)
 return
-formatted_values = [map(self.myformat_value, row.values()) for row in 
rows]
+formatted_values = [map(self.myformat_value, [row[column] for column 
in column_names]) for row in rows]
 
 if self.expand_enabled:
 self.print_formatted_result_vertically(formatted_names, 
formatted_values)


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



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

2018-09-04 Thread mck
Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: 21ec39a9d66b66ce6ca814522eb047cdec0c454f
Parents: d049c6b 62e48c5
Author: Mick Semb Wever 
Authored: Wed Sep 5 11:15:47 2018 +1000
Committer: Mick Semb Wever 
Committed: Wed Sep 5 11:17:49 2018 +1000

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/21ec39a9/CHANGES.txt
--
diff --cc CHANGES.txt
index 7049180,71c57ea..d55ddb6
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,45 -1,8 +1,46 @@@
 -2.2.14
 +3.0.18
 + * Improve TokenMetaData cache populating performance avoid long locking 
(CASSANDRA-14660)
 + * Fix static column order for SELECT * wildcard queries (CASSANDRA-14638)
 + * sstableloader should use discovered broadcast address to connect 
intra-cluster (CASSANDRA-14522)
 + * Fix reading columns with non-UTF names from schema (CASSANDRA-14468)
 + Merged from 2.2:
+  * Fix incorrect cqlsh results when selecting same columns multiple times 
(CASSANDRA-13262)
   * Returns null instead of NaN or Infinity in JSON strings (CASSANDRA-14377)
  
 -2.2.13
 +
 +3.0.17
 + * Fix corrupted static collection deletions in 3.0 -> 2.{1,2} messages 
(CASSANDRA-14568)
 + * Fix potential IndexOutOfBoundsException with counters (CASSANDRA-14167)
 + * Restore resumable hints delivery, backport CASSANDRA-11960 
(CASSANDRA-14419)
 + * Always close RT markers returned by ReadCommand#executeLocally() 
(CASSANDRA-14515)
 + * Reverse order queries with range tombstones can cause data loss 
(CASSANDRA-14513)
 + * Fix regression of lagging commitlog flush log message (CASSANDRA-14451)
 + * Add Missing dependencies in pom-all (CASSANDRA-14422)
 + * Cleanup StartupClusterConnectivityChecker and PING Verb (CASSANDRA-14447)
 + * Fix deprecated repair error notifications from 3.x clusters to legacy JMX 
clients (CASSANDRA-13121)
 + * Cassandra not starting when using enhanced startup scripts in windows 
(CASSANDRA-14418)
 + * Fix progress stats and units in compactionstats (CASSANDRA-12244)
 + * Better handle missing partition columns in system_schema.columns 
(CASSANDRA-14379)
 + * Delay hints store excise by write timeout to avoid race with decommission 
(CASSANDRA-13740)
 + * Deprecate background repair and probablistic read_repair_chance table 
options
 +   (CASSANDRA-13910)
 + * Add missed CQL keywords to documentation (CASSANDRA-14359)
 + * Fix unbounded validation compactions on repair / revert CASSANDRA-13797 
(CASSANDRA-14332)
 + * Avoid deadlock when running nodetool refresh before node is fully up 
(CASSANDRA-14310)
 + * Handle all exceptions when opening sstables (CASSANDRA-14202)
 + * Handle incompletely written hint descriptors during startup 
(CASSANDRA-14080)
 + * Handle repeat open bound from SRP in read repair (CASSANDRA-14330)
 + * Respect max hint window when hinting for LWT (CASSANDRA-14215)
 + * Adding missing WriteType enum values to v3, v4, and v5 spec 
(CASSANDRA-13697)
 + * Don't regenerate bloomfilter and summaries on startup (CASSANDRA-11163)
 + * Fix NPE when performing comparison against a null frozen in LWT 
(CASSANDRA-14087)
 + * Log when SSTables are deleted (CASSANDRA-14302)
 + * Fix batch commitlog sync regression (CASSANDRA-14292)
 + * Write to pending endpoint when view replica is also base replica 
(CASSANDRA-14251)
 + * Chain commit log marker potential performance regression in batch commit 
mode (CASSANDRA-14194)
 + * Fully utilise specified compaction threads (CASSANDRA-14210)
 + * Pre-create deletion log records to finish compactions quicker 
(CASSANDRA-12763)
 +Merged from 2.2:
   * Fix bug that prevented compaction of SSTables after full repairs 
(CASSANDRA-14423)
   * Incorrect counting of pending messages in OutboundTcpConnection 
(CASSANDRA-11551)
   * Fix compaction failure caused by reading un-flushed data (CASSANDRA-12743)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/21ec39a9/bin/cqlsh.py
--


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



[02/10] cassandra git commit: Fix incorrect cqlsh results when selecting same columns multiple times

2018-09-04 Thread mck
Fix incorrect cqlsh results when selecting same columns multiple times

Patch by Anthony Grasso; reviewed by Mick Semb Wever for CASSANDRA-13262


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

Branch: refs/heads/cassandra-3.0
Commit: 62e48c5f3f818d1e841178d7365d208435a63537
Parents: 49adbe7
Author: Mick Semb Wever 
Authored: Wed Sep 5 11:13:49 2018 +1000
Committer: Mick Semb Wever 
Committed: Wed Sep 5 11:13:49 2018 +1000

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/62e48c5f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f3de388..71c57ea 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.14
+ * Fix incorrect cqlsh results when selecting same columns multiple times 
(CASSANDRA-13262)
  * Returns null instead of NaN or Infinity in JSON strings (CASSANDRA-14377)
 
 2.2.13

http://git-wip-us.apache.org/repos/asf/cassandra/blob/62e48c5f/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index e242d42..3d0e056 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -1313,7 +1313,7 @@ class Shell(cmd.Cmd):
 # print header only
 self.print_formatted_result(formatted_names, None)
 return
-formatted_values = [map(self.myformat_value, row.values()) for row in 
rows]
+formatted_values = [map(self.myformat_value, [row[column] for column 
in column_names]) for row in rows]
 
 if self.expand_enabled:
 self.print_formatted_result_vertically(formatted_names, 
formatted_values)


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



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

2018-09-04 Thread mck
Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.11
Commit: 21ec39a9d66b66ce6ca814522eb047cdec0c454f
Parents: d049c6b 62e48c5
Author: Mick Semb Wever 
Authored: Wed Sep 5 11:15:47 2018 +1000
Committer: Mick Semb Wever 
Committed: Wed Sep 5 11:17:49 2018 +1000

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/21ec39a9/CHANGES.txt
--
diff --cc CHANGES.txt
index 7049180,71c57ea..d55ddb6
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,45 -1,8 +1,46 @@@
 -2.2.14
 +3.0.18
 + * Improve TokenMetaData cache populating performance avoid long locking 
(CASSANDRA-14660)
 + * Fix static column order for SELECT * wildcard queries (CASSANDRA-14638)
 + * sstableloader should use discovered broadcast address to connect 
intra-cluster (CASSANDRA-14522)
 + * Fix reading columns with non-UTF names from schema (CASSANDRA-14468)
 + Merged from 2.2:
+  * Fix incorrect cqlsh results when selecting same columns multiple times 
(CASSANDRA-13262)
   * Returns null instead of NaN or Infinity in JSON strings (CASSANDRA-14377)
  
 -2.2.13
 +
 +3.0.17
 + * Fix corrupted static collection deletions in 3.0 -> 2.{1,2} messages 
(CASSANDRA-14568)
 + * Fix potential IndexOutOfBoundsException with counters (CASSANDRA-14167)
 + * Restore resumable hints delivery, backport CASSANDRA-11960 
(CASSANDRA-14419)
 + * Always close RT markers returned by ReadCommand#executeLocally() 
(CASSANDRA-14515)
 + * Reverse order queries with range tombstones can cause data loss 
(CASSANDRA-14513)
 + * Fix regression of lagging commitlog flush log message (CASSANDRA-14451)
 + * Add Missing dependencies in pom-all (CASSANDRA-14422)
 + * Cleanup StartupClusterConnectivityChecker and PING Verb (CASSANDRA-14447)
 + * Fix deprecated repair error notifications from 3.x clusters to legacy JMX 
clients (CASSANDRA-13121)
 + * Cassandra not starting when using enhanced startup scripts in windows 
(CASSANDRA-14418)
 + * Fix progress stats and units in compactionstats (CASSANDRA-12244)
 + * Better handle missing partition columns in system_schema.columns 
(CASSANDRA-14379)
 + * Delay hints store excise by write timeout to avoid race with decommission 
(CASSANDRA-13740)
 + * Deprecate background repair and probablistic read_repair_chance table 
options
 +   (CASSANDRA-13910)
 + * Add missed CQL keywords to documentation (CASSANDRA-14359)
 + * Fix unbounded validation compactions on repair / revert CASSANDRA-13797 
(CASSANDRA-14332)
 + * Avoid deadlock when running nodetool refresh before node is fully up 
(CASSANDRA-14310)
 + * Handle all exceptions when opening sstables (CASSANDRA-14202)
 + * Handle incompletely written hint descriptors during startup 
(CASSANDRA-14080)
 + * Handle repeat open bound from SRP in read repair (CASSANDRA-14330)
 + * Respect max hint window when hinting for LWT (CASSANDRA-14215)
 + * Adding missing WriteType enum values to v3, v4, and v5 spec 
(CASSANDRA-13697)
 + * Don't regenerate bloomfilter and summaries on startup (CASSANDRA-11163)
 + * Fix NPE when performing comparison against a null frozen in LWT 
(CASSANDRA-14087)
 + * Log when SSTables are deleted (CASSANDRA-14302)
 + * Fix batch commitlog sync regression (CASSANDRA-14292)
 + * Write to pending endpoint when view replica is also base replica 
(CASSANDRA-14251)
 + * Chain commit log marker potential performance regression in batch commit 
mode (CASSANDRA-14194)
 + * Fully utilise specified compaction threads (CASSANDRA-14210)
 + * Pre-create deletion log records to finish compactions quicker 
(CASSANDRA-12763)
 +Merged from 2.2:
   * Fix bug that prevented compaction of SSTables after full repairs 
(CASSANDRA-14423)
   * Incorrect counting of pending messages in OutboundTcpConnection 
(CASSANDRA-11551)
   * Fix compaction failure caused by reading un-flushed data (CASSANDRA-12743)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/21ec39a9/bin/cqlsh.py
--


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



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

2018-09-04 Thread mck
Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: 21ec39a9d66b66ce6ca814522eb047cdec0c454f
Parents: d049c6b 62e48c5
Author: Mick Semb Wever 
Authored: Wed Sep 5 11:15:47 2018 +1000
Committer: Mick Semb Wever 
Committed: Wed Sep 5 11:17:49 2018 +1000

--
 CHANGES.txt  | 1 +
 bin/cqlsh.py | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/21ec39a9/CHANGES.txt
--
diff --cc CHANGES.txt
index 7049180,71c57ea..d55ddb6
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,45 -1,8 +1,46 @@@
 -2.2.14
 +3.0.18
 + * Improve TokenMetaData cache populating performance avoid long locking 
(CASSANDRA-14660)
 + * Fix static column order for SELECT * wildcard queries (CASSANDRA-14638)
 + * sstableloader should use discovered broadcast address to connect 
intra-cluster (CASSANDRA-14522)
 + * Fix reading columns with non-UTF names from schema (CASSANDRA-14468)
 + Merged from 2.2:
+  * Fix incorrect cqlsh results when selecting same columns multiple times 
(CASSANDRA-13262)
   * Returns null instead of NaN or Infinity in JSON strings (CASSANDRA-14377)
  
 -2.2.13
 +
 +3.0.17
 + * Fix corrupted static collection deletions in 3.0 -> 2.{1,2} messages 
(CASSANDRA-14568)
 + * Fix potential IndexOutOfBoundsException with counters (CASSANDRA-14167)
 + * Restore resumable hints delivery, backport CASSANDRA-11960 
(CASSANDRA-14419)
 + * Always close RT markers returned by ReadCommand#executeLocally() 
(CASSANDRA-14515)
 + * Reverse order queries with range tombstones can cause data loss 
(CASSANDRA-14513)
 + * Fix regression of lagging commitlog flush log message (CASSANDRA-14451)
 + * Add Missing dependencies in pom-all (CASSANDRA-14422)
 + * Cleanup StartupClusterConnectivityChecker and PING Verb (CASSANDRA-14447)
 + * Fix deprecated repair error notifications from 3.x clusters to legacy JMX 
clients (CASSANDRA-13121)
 + * Cassandra not starting when using enhanced startup scripts in windows 
(CASSANDRA-14418)
 + * Fix progress stats and units in compactionstats (CASSANDRA-12244)
 + * Better handle missing partition columns in system_schema.columns 
(CASSANDRA-14379)
 + * Delay hints store excise by write timeout to avoid race with decommission 
(CASSANDRA-13740)
 + * Deprecate background repair and probablistic read_repair_chance table 
options
 +   (CASSANDRA-13910)
 + * Add missed CQL keywords to documentation (CASSANDRA-14359)
 + * Fix unbounded validation compactions on repair / revert CASSANDRA-13797 
(CASSANDRA-14332)
 + * Avoid deadlock when running nodetool refresh before node is fully up 
(CASSANDRA-14310)
 + * Handle all exceptions when opening sstables (CASSANDRA-14202)
 + * Handle incompletely written hint descriptors during startup 
(CASSANDRA-14080)
 + * Handle repeat open bound from SRP in read repair (CASSANDRA-14330)
 + * Respect max hint window when hinting for LWT (CASSANDRA-14215)
 + * Adding missing WriteType enum values to v3, v4, and v5 spec 
(CASSANDRA-13697)
 + * Don't regenerate bloomfilter and summaries on startup (CASSANDRA-11163)
 + * Fix NPE when performing comparison against a null frozen in LWT 
(CASSANDRA-14087)
 + * Log when SSTables are deleted (CASSANDRA-14302)
 + * Fix batch commitlog sync regression (CASSANDRA-14292)
 + * Write to pending endpoint when view replica is also base replica 
(CASSANDRA-14251)
 + * Chain commit log marker potential performance regression in batch commit 
mode (CASSANDRA-14194)
 + * Fully utilise specified compaction threads (CASSANDRA-14210)
 + * Pre-create deletion log records to finish compactions quicker 
(CASSANDRA-12763)
 +Merged from 2.2:
   * Fix bug that prevented compaction of SSTables after full repairs 
(CASSANDRA-14423)
   * Incorrect counting of pending messages in OutboundTcpConnection 
(CASSANDRA-11551)
   * Fix compaction failure caused by reading un-flushed data (CASSANDRA-12743)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/21ec39a9/bin/cqlsh.py
--


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



[jira] [Commented] (CASSANDRA-14145) Detecting data resurrection during read

2018-09-04 Thread Sam Tunnicliffe (JIRA)


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

Sam Tunnicliffe commented on CASSANDRA-14145:
-

Current CI
||branch||trunk||
|[utests|https://circleci.com/gh/beobal/cassandra/422]|[utests|https://circleci.com/gh/beobal/cassandra/429]|
|[dtests-with-vnodes|https://circleci.com/gh/beobal/cassandra/423]|[dtests-with-vnodes|https://circleci.com/gh/beobal/cassandra/428]|
|[dtests-no-vnodes|https://circleci.com/gh/beobal/cassandra/424]|[dtests-no-vnodes|https://circleci.com/gh/beobal/cassandra/430]|


>  Detecting data resurrection during read
> 
>
> Key: CASSANDRA-14145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14145
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 4.x
>
>
> We have seen several bugs in which deleted data gets resurrected. We should 
> try to see if we can detect this on the read path and possibly fix it. Here 
> are a few examples which brought back data
> A replica lost an sstable on startup which caused one replica to lose the 
> tombstone and not the data. This tombstone was past gc grace which means this 
> could resurrect data. We can detect such invalid states by looking at other 
> replicas. 
> If we are running incremental repair, Cassandra will keep repaired and 
> non-repaired data separate. Every-time incremental repair will run, it will 
> move the data from non-repaired to repaired. Repaired data across all 
> replicas should be 100% consistent. 
> Here is an example of how we can detect and mitigate the issue in most cases. 
> Say we have 3 machines, A,B and C. All these machines will have data split 
> b/w repaired and non-repaired. 
> 1. Machine A due to some bug bring backs data D. This data D is in repaired 
> dataset. All other replicas will have data D and tombstone T 
> 2. Read for data D comes from application which involve replicas A and B. The 
> data being read involves data which is in repaired state.  A will respond 
> back to co-ordinator with data D and B will send nothing as tombstone is past 
> gc grace. This will cause digest mismatch. 
> 3. This patch will only kick in when there is a digest mismatch. Co-ordinator 
> will ask both replicas to send back all data like we do today but with this 
> patch, replicas will respond back what data it is returning is coming from 
> repaired vs non-repaired. If data coming from repaired does not match, we 
> know there is a something wrong!! At this time, co-ordinator cannot determine 
> if replica A has resurrected some data or replica B has lost some data. We 
> can still log error in the logs saying we hit an invalid state.
> 4. Besides the log, we can take this further and even correct the response to 
> the query. After logging an invalid state, we can ask replica A and B (and 
> also C if alive) to send back all data for this including gcable tombstones. 
> If any machine returns a tombstone which is after this data, we know we 
> cannot return this data. This way we can avoid returning data which has been 
> deleted. 
> Some Challenges with this 
> 1. When data will be moved from non-repaired to repaired, there could be a 
> race here. We can look at which incremental repairs have promoted things on 
> which replica to avoid false positives.  
> 2. If the third replica is down and live replica does not have any tombstone, 
> we wont be able to break the tie in deciding whether data was actually 
> deleted or resurrected. 
> 3. If the read is for latest data only, we wont be able to detect it as the 
> read will be served from non-repaired data. 
> 4. If the replica where we lose a tombstone is the last replica to compact 
> the tombstone, we wont be able to decide if data is coming back or rest of 
> the replicas has lost that data. But we will still detect something is wrong. 
> 5. We wont affect 99.9% of the read queries as we only do extra work during 
> digest mismatch.
> 6. CL.ONE reads will not be able to detect this. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (CASSANDRA-14647) Reading cardinality from Statistics.db failed

2018-09-04 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson updated CASSANDRA-14647:

Component/s: (was: Compaction)

> Reading cardinality from Statistics.db failed
> -
>
> Key: CASSANDRA-14647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14647
> Project: Cassandra
>  Issue Type: Bug
>  Components: Metrics
> Environment: Clients are doing only writes with Local One, cluster 
> consist of 3 regions with RF3.
> Storage is configured wth jbod/XFS on 10 x 1Tb disks
> IOPS limit for each disk 500 (total 5000 iops)
> Bandwith for each disk 60mb/s (600 total)
> OS is Debian linux.
>Reporter: Vitali Djatsuk
>Assignee: Marcus Eriksson
>Priority: Minor
> Fix For: 3.0.x
>
> Attachments: cassandra_compaction_pending_tasks_7days.png
>
>
> There is some issue with sstable metadata which is visible in system.log, the 
> messages says:
> {noformat}
> WARN  [Thread-6] 2018-07-25 07:12:47,928 SSTableReader.java:249 - Reading 
> cardinality from Statistics.db failed for 
> /opt/data/disk5/data/keyspace/table/mc-big-Data.db.{noformat}
> Although there is no such file. 
> The message has appeared after i've changed the compaction strategy from 
> SizeTiered to Leveled. Compaction strategy has been changed region by region 
> (total 3 regions) and it has coincided with the double client write traffic 
> increase.
>  I have tried to run nodetool scrub to rebuilt the sstable, but that does not 
> fix the issue.
> So very hard to define the steps to reproduce, probably it will be:
>  # run stress tool with write traffic
>  # under load change compaction strategy from SireTiered to Leveled for the 
> bunch of hosts
>  # add more write traffic
> Reading the code it is said that if this metadata is broken, then "estimating 
> the keys will be done using index summary". 
>  
> [https://github.com/apache/cassandra/blob/cassandra-3.0.17/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L247]
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (CASSANDRA-14647) Reading cardinality from Statistics.db failed

2018-09-04 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson updated CASSANDRA-14647:

Component/s: Metrics

> Reading cardinality from Statistics.db failed
> -
>
> Key: CASSANDRA-14647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14647
> Project: Cassandra
>  Issue Type: Bug
>  Components: Metrics
> Environment: Clients are doing only writes with Local One, cluster 
> consist of 3 regions with RF3.
> Storage is configured wth jbod/XFS on 10 x 1Tb disks
> IOPS limit for each disk 500 (total 5000 iops)
> Bandwith for each disk 60mb/s (600 total)
> OS is Debian linux.
>Reporter: Vitali Djatsuk
>Assignee: Marcus Eriksson
>Priority: Minor
> Fix For: 3.0.x
>
> Attachments: cassandra_compaction_pending_tasks_7days.png
>
>
> There is some issue with sstable metadata which is visible in system.log, the 
> messages says:
> {noformat}
> WARN  [Thread-6] 2018-07-25 07:12:47,928 SSTableReader.java:249 - Reading 
> cardinality from Statistics.db failed for 
> /opt/data/disk5/data/keyspace/table/mc-big-Data.db.{noformat}
> Although there is no such file. 
> The message has appeared after i've changed the compaction strategy from 
> SizeTiered to Leveled. Compaction strategy has been changed region by region 
> (total 3 regions) and it has coincided with the double client write traffic 
> increase.
>  I have tried to run nodetool scrub to rebuilt the sstable, but that does not 
> fix the issue.
> So very hard to define the steps to reproduce, probably it will be:
>  # run stress tool with write traffic
>  # under load change compaction strategy from SireTiered to Leveled for the 
> bunch of hosts
>  # add more write traffic
> Reading the code it is said that if this metadata is broken, then "estimating 
> the keys will be done using index summary". 
>  
> [https://github.com/apache/cassandra/blob/cassandra-3.0.17/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L247]
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (CASSANDRA-14647) Reading cardinality from Statistics.db failed

2018-09-04 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson commented on CASSANDRA-14647:
-

there is an alias for the metric called {{EstimatedRowCount}} which should also 
be disabled

I'll work on a fix

> Reading cardinality from Statistics.db failed
> -
>
> Key: CASSANDRA-14647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14647
> Project: Cassandra
>  Issue Type: Bug
>  Components: Metrics
> Environment: Clients are doing only writes with Local One, cluster 
> consist of 3 regions with RF3.
> Storage is configured wth jbod/XFS on 10 x 1Tb disks
> IOPS limit for each disk 500 (total 5000 iops)
> Bandwith for each disk 60mb/s (600 total)
> OS is Debian linux.
>Reporter: Vitali Djatsuk
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 3.0.x
>
> Attachments: cassandra_compaction_pending_tasks_7days.png
>
>
> There is some issue with sstable metadata which is visible in system.log, the 
> messages says:
> {noformat}
> WARN  [Thread-6] 2018-07-25 07:12:47,928 SSTableReader.java:249 - Reading 
> cardinality from Statistics.db failed for 
> /opt/data/disk5/data/keyspace/table/mc-big-Data.db.{noformat}
> Although there is no such file. 
> The message has appeared after i've changed the compaction strategy from 
> SizeTiered to Leveled. Compaction strategy has been changed region by region 
> (total 3 regions) and it has coincided with the double client write traffic 
> increase.
>  I have tried to run nodetool scrub to rebuilt the sstable, but that does not 
> fix the issue.
> So very hard to define the steps to reproduce, probably it will be:
>  # run stress tool with write traffic
>  # under load change compaction strategy from SireTiered to Leveled for the 
> bunch of hosts
>  # add more write traffic
> Reading the code it is said that if this metadata is broken, then "estimating 
> the keys will be done using index summary". 
>  
> [https://github.com/apache/cassandra/blob/cassandra-3.0.17/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L247]
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (CASSANDRA-14647) Reading cardinality from Statistics.db failed

2018-09-04 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson updated CASSANDRA-14647:

Priority: Minor  (was: Major)

> Reading cardinality from Statistics.db failed
> -
>
> Key: CASSANDRA-14647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14647
> Project: Cassandra
>  Issue Type: Bug
>  Components: Metrics
> Environment: Clients are doing only writes with Local One, cluster 
> consist of 3 regions with RF3.
> Storage is configured wth jbod/XFS on 10 x 1Tb disks
> IOPS limit for each disk 500 (total 5000 iops)
> Bandwith for each disk 60mb/s (600 total)
> OS is Debian linux.
>Reporter: Vitali Djatsuk
>Assignee: Marcus Eriksson
>Priority: Minor
> Fix For: 3.0.x
>
> Attachments: cassandra_compaction_pending_tasks_7days.png
>
>
> There is some issue with sstable metadata which is visible in system.log, the 
> messages says:
> {noformat}
> WARN  [Thread-6] 2018-07-25 07:12:47,928 SSTableReader.java:249 - Reading 
> cardinality from Statistics.db failed for 
> /opt/data/disk5/data/keyspace/table/mc-big-Data.db.{noformat}
> Although there is no such file. 
> The message has appeared after i've changed the compaction strategy from 
> SizeTiered to Leveled. Compaction strategy has been changed region by region 
> (total 3 regions) and it has coincided with the double client write traffic 
> increase.
>  I have tried to run nodetool scrub to rebuilt the sstable, but that does not 
> fix the issue.
> So very hard to define the steps to reproduce, probably it will be:
>  # run stress tool with write traffic
>  # under load change compaction strategy from SireTiered to Leveled for the 
> bunch of hosts
>  # add more write traffic
> Reading the code it is said that if this metadata is broken, then "estimating 
> the keys will be done using index summary". 
>  
> [https://github.com/apache/cassandra/blob/cassandra-3.0.17/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L247]
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Assigned] (CASSANDRA-14647) Reading cardinality from Statistics.db failed

2018-09-04 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson reassigned CASSANDRA-14647:
---

Assignee: Marcus Eriksson

> Reading cardinality from Statistics.db failed
> -
>
> Key: CASSANDRA-14647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14647
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: Clients are doing only writes with Local One, cluster 
> consist of 3 regions with RF3.
> Storage is configured wth jbod/XFS on 10 x 1Tb disks
> IOPS limit for each disk 500 (total 5000 iops)
> Bandwith for each disk 60mb/s (600 total)
> OS is Debian linux.
>Reporter: Vitali Djatsuk
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 3.0.x
>
> Attachments: cassandra_compaction_pending_tasks_7days.png
>
>
> There is some issue with sstable metadata which is visible in system.log, the 
> messages says:
> {noformat}
> WARN  [Thread-6] 2018-07-25 07:12:47,928 SSTableReader.java:249 - Reading 
> cardinality from Statistics.db failed for 
> /opt/data/disk5/data/keyspace/table/mc-big-Data.db.{noformat}
> Although there is no such file. 
> The message has appeared after i've changed the compaction strategy from 
> SizeTiered to Leveled. Compaction strategy has been changed region by region 
> (total 3 regions) and it has coincided with the double client write traffic 
> increase.
>  I have tried to run nodetool scrub to rebuilt the sstable, but that does not 
> fix the issue.
> So very hard to define the steps to reproduce, probably it will be:
>  # run stress tool with write traffic
>  # under load change compaction strategy from SireTiered to Leveled for the 
> bunch of hosts
>  # add more write traffic
> Reading the code it is said that if this metadata is broken, then "estimating 
> the keys will be done using index summary". 
>  
> [https://github.com/apache/cassandra/blob/cassandra-3.0.17/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L247]
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (CASSANDRA-14659) Disable old native protocol versions on demand

2018-09-04 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-14659:
--

Thanks, [~jasobrown]

> Disable old native protocol versions on demand
> --
>
> Key: CASSANDRA-14659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14659
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Major
>  Labels: usability
> Fix For: 4.0
>
>
> This patch allows the operators to disable older protocol versions on demand. 
> To use it, you can set {{native_transport_allow_older_protocols}} to false or 
> use nodetool disableolderprotocolversions. Cassandra will reject requests 
> from client coming in on any version except the current version. This will 
> help operators selectively reject connections from clients that do not 
> support the latest protoocol.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (CASSANDRA-14436) Add sampler for query time and expose with nodetool

2018-09-04 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-14436:
--

Thank you for committing this, [~iamaleksey]!

> Add sampler for query time and expose with nodetool
> ---
>
> Key: CASSANDRA-14436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14436
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Major
>  Labels: 4.0-feature-freeze-review-requested, 
> pull-request-available
> Fix For: 4.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Create a new {{nodetool profileload}} that functions just like toppartitions 
> but with more data, returning the slowest local reads and writes on the host 
> during a given duration and highest frequency touched partitions (same as 
> {{nodetool toppartitions}}). Refactor included to extend use of the sampler 
> for uses outside of top frequency (max instead of total sample values).
> Future work to this is to include top cpu and allocations by query and 
> possibly tasks/cpu/allocations by stage during time window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (CASSANDRA-14145) Detecting data resurrection during read

2018-09-04 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson commented on CASSANDRA-14145:
-

+1 on the latest changes

>  Detecting data resurrection during read
> 
>
> Key: CASSANDRA-14145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14145
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 4.x
>
>
> We have seen several bugs in which deleted data gets resurrected. We should 
> try to see if we can detect this on the read path and possibly fix it. Here 
> are a few examples which brought back data
> A replica lost an sstable on startup which caused one replica to lose the 
> tombstone and not the data. This tombstone was past gc grace which means this 
> could resurrect data. We can detect such invalid states by looking at other 
> replicas. 
> If we are running incremental repair, Cassandra will keep repaired and 
> non-repaired data separate. Every-time incremental repair will run, it will 
> move the data from non-repaired to repaired. Repaired data across all 
> replicas should be 100% consistent. 
> Here is an example of how we can detect and mitigate the issue in most cases. 
> Say we have 3 machines, A,B and C. All these machines will have data split 
> b/w repaired and non-repaired. 
> 1. Machine A due to some bug bring backs data D. This data D is in repaired 
> dataset. All other replicas will have data D and tombstone T 
> 2. Read for data D comes from application which involve replicas A and B. The 
> data being read involves data which is in repaired state.  A will respond 
> back to co-ordinator with data D and B will send nothing as tombstone is past 
> gc grace. This will cause digest mismatch. 
> 3. This patch will only kick in when there is a digest mismatch. Co-ordinator 
> will ask both replicas to send back all data like we do today but with this 
> patch, replicas will respond back what data it is returning is coming from 
> repaired vs non-repaired. If data coming from repaired does not match, we 
> know there is a something wrong!! At this time, co-ordinator cannot determine 
> if replica A has resurrected some data or replica B has lost some data. We 
> can still log error in the logs saying we hit an invalid state.
> 4. Besides the log, we can take this further and even correct the response to 
> the query. After logging an invalid state, we can ask replica A and B (and 
> also C if alive) to send back all data for this including gcable tombstones. 
> If any machine returns a tombstone which is after this data, we know we 
> cannot return this data. This way we can avoid returning data which has been 
> deleted. 
> Some Challenges with this 
> 1. When data will be moved from non-repaired to repaired, there could be a 
> race here. We can look at which incremental repairs have promoted things on 
> which replica to avoid false positives.  
> 2. If the third replica is down and live replica does not have any tombstone, 
> we wont be able to break the tie in deciding whether data was actually 
> deleted or resurrected. 
> 3. If the read is for latest data only, we wont be able to detect it as the 
> read will be served from non-repaired data. 
> 4. If the replica where we lose a tombstone is the last replica to compact 
> the tombstone, we wont be able to decide if data is coming back or rest of 
> the replicas has lost that data. But we will still detect something is wrong. 
> 5. We wont affect 99.9% of the read queries as we only do extra work during 
> digest mismatch.
> 6. CL.ONE reads will not be able to detect this. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (CASSANDRA-14647) Reading cardinality from Statistics.db failed

2018-09-04 Thread Romain Hardouin (JIRA)


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

Romain Hardouin commented on CASSANDRA-14647:
-

After removing {{EstimatedPartitionCount}} from Datadog's cassandra.yaml on one 
node, I don't see any warning for 4 days.

[~nezdali] can you double check that your change was effective (e.g. monitoring 
service restarted, etc.)? 

> Reading cardinality from Statistics.db failed
> -
>
> Key: CASSANDRA-14647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14647
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: Clients are doing only writes with Local One, cluster 
> consist of 3 regions with RF3.
> Storage is configured wth jbod/XFS on 10 x 1Tb disks
> IOPS limit for each disk 500 (total 5000 iops)
> Bandwith for each disk 60mb/s (600 total)
> OS is Debian linux.
>Reporter: Vitali Djatsuk
>Priority: Major
> Fix For: 3.0.x
>
> Attachments: cassandra_compaction_pending_tasks_7days.png
>
>
> There is some issue with sstable metadata which is visible in system.log, the 
> messages says:
> {noformat}
> WARN  [Thread-6] 2018-07-25 07:12:47,928 SSTableReader.java:249 - Reading 
> cardinality from Statistics.db failed for 
> /opt/data/disk5/data/keyspace/table/mc-big-Data.db.{noformat}
> Although there is no such file. 
> The message has appeared after i've changed the compaction strategy from 
> SizeTiered to Leveled. Compaction strategy has been changed region by region 
> (total 3 regions) and it has coincided with the double client write traffic 
> increase.
>  I have tried to run nodetool scrub to rebuilt the sstable, but that does not 
> fix the issue.
> So very hard to define the steps to reproduce, probably it will be:
>  # run stress tool with write traffic
>  # under load change compaction strategy from SireTiered to Leveled for the 
> bunch of hosts
>  # add more write traffic
> Reading the code it is said that if this metadata is broken, then "estimating 
> the keys will be done using index summary". 
>  
> [https://github.com/apache/cassandra/blob/cassandra-3.0.17/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L247]
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (CASSANDRA-14686) Jolokia agent not accepting requests during an operation

2018-09-04 Thread Cyril Scetbon (JIRA)


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

Cyril Scetbon resolved CASSANDRA-14686.
---
Resolution: Not A Problem
  Assignee: Cyril Scetbon

Looking in the cassandra core code, I didn't find any bridge code between the 
Jolokia agent and the JMX. I think the issue comes from the agent itself. I'm 
gonna look at it and try to find what's going on.

> Jolokia agent not accepting requests during an operation
> 
>
> Key: CASSANDRA-14686
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14686
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 3.11.2
> Ubuntu Xenial
> Jolokia 1.3.7
>Reporter: Cyril Scetbon
>Assignee: Cyril Scetbon
>Priority: Major
>
> I've noticed that when I run a long operation like a rebuild using Jolokia, I 
> can no longer query Jolokia and get a timeout error even when trying to read 
> a simple attribute like the Java version in use : 
> {code:java}
> jmx4perl http://cassandra-3.11.2:8778/jolokia read java.lang:type=Runtime 
> SpecVersion
> ERROR: Error while fetching http:// 
> cassandra-3.11.2:8778/jolokia/read/java.lang%3Atype%3DRuntime/SpecVersion :
> 408 Got timeout in 180s
> {code}
> I also removed the default flag 
> [-XX:+PerfDisableSharedMem|https://github.com/apache/cassandra/blob/cassandra-3.11/NEWS.txt#L769-L771]
>  but did not get more luck.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (CASSANDRA-13639) SSTableLoader always uses hostname to stream files from

2018-09-04 Thread Jon Haddad (JIRA)


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

Jon Haddad updated CASSANDRA-13639:
---
   Resolution: Not A Problem
Reproduced In: 3.0.15, 2.2.9  (was: 2.2.9, 3.0.15)
   Status: Resolved  (was: Patch Available)

No longer an issue as per [~Jan Karlsson].

> SSTableLoader always uses hostname to stream files from
> ---
>
> Key: CASSANDRA-13639
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13639
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Jan Karlsson
>Assignee: Jan Karlsson
>Priority: Major
> Attachments: 13639-trunk
>
>
> I stumbled upon an issue where SSTableLoader was ignoring our routing by 
> using the wrong interface to send the SSTables to the other nodes. Looking at 
> the code, it seems that we are using FBUtilities.getLocalAddress() to fetch 
> out the hostname, even if the yaml file specifies a different host. I am not 
> sure why we call this function instead of using the routing by leaving it 
> blank, perhaps someone could enlighten me.
> This behaviour comes from the fact that we use a default created 
> DatabaseDescriptor which does not set the values for listenAddress and 
> listenInterface. This causes the aforementioned function to retrieve the 
> hostname at all times, even if it is not the interface used in the yaml file.
> I propose we break out the function that handles listenAddress and 
> listenInterface and call it so that listenAddress or listenInterface is 
> getting populated in the DatabaseDescriptor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (CASSANDRA-14145) Detecting data resurrection during read

2018-09-04 Thread Sam Tunnicliffe (JIRA)


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

Sam Tunnicliffe commented on CASSANDRA-14145:
-

The changes required by transient replication were fairly minor and mostly 
confined to tests. The only real thing that needed updating in the main code 
was to discount responses from transient replicas in {{DataResolver}}. In light 
of that, I've also slightly changed the way tracking is requested, so that we 
only request tracking from full replicas.

I've pushed a dtest branch with a few specific tests for this and with tracking 
enabled for all tests here: 
[dtests|https://github.com/beobal/cassandra-dtest/tree/14145]
Although I have spot-checked a few fixtures, I haven't exhaustively verified 
this for everything yet. I'll update when CI runs are done


>  Detecting data resurrection during read
> 
>
> Key: CASSANDRA-14145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14145
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 4.x
>
>
> We have seen several bugs in which deleted data gets resurrected. We should 
> try to see if we can detect this on the read path and possibly fix it. Here 
> are a few examples which brought back data
> A replica lost an sstable on startup which caused one replica to lose the 
> tombstone and not the data. This tombstone was past gc grace which means this 
> could resurrect data. We can detect such invalid states by looking at other 
> replicas. 
> If we are running incremental repair, Cassandra will keep repaired and 
> non-repaired data separate. Every-time incremental repair will run, it will 
> move the data from non-repaired to repaired. Repaired data across all 
> replicas should be 100% consistent. 
> Here is an example of how we can detect and mitigate the issue in most cases. 
> Say we have 3 machines, A,B and C. All these machines will have data split 
> b/w repaired and non-repaired. 
> 1. Machine A due to some bug bring backs data D. This data D is in repaired 
> dataset. All other replicas will have data D and tombstone T 
> 2. Read for data D comes from application which involve replicas A and B. The 
> data being read involves data which is in repaired state.  A will respond 
> back to co-ordinator with data D and B will send nothing as tombstone is past 
> gc grace. This will cause digest mismatch. 
> 3. This patch will only kick in when there is a digest mismatch. Co-ordinator 
> will ask both replicas to send back all data like we do today but with this 
> patch, replicas will respond back what data it is returning is coming from 
> repaired vs non-repaired. If data coming from repaired does not match, we 
> know there is a something wrong!! At this time, co-ordinator cannot determine 
> if replica A has resurrected some data or replica B has lost some data. We 
> can still log error in the logs saying we hit an invalid state.
> 4. Besides the log, we can take this further and even correct the response to 
> the query. After logging an invalid state, we can ask replica A and B (and 
> also C if alive) to send back all data for this including gcable tombstones. 
> If any machine returns a tombstone which is after this data, we know we 
> cannot return this data. This way we can avoid returning data which has been 
> deleted. 
> Some Challenges with this 
> 1. When data will be moved from non-repaired to repaired, there could be a 
> race here. We can look at which incremental repairs have promoted things on 
> which replica to avoid false positives.  
> 2. If the third replica is down and live replica does not have any tombstone, 
> we wont be able to break the tie in deciding whether data was actually 
> deleted or resurrected. 
> 3. If the read is for latest data only, we wont be able to detect it as the 
> read will be served from non-repaired data. 
> 4. If the replica where we lose a tombstone is the last replica to compact 
> the tombstone, we wont be able to decide if data is coming back or rest of 
> the replicas has lost that data. But we will still detect something is wrong. 
> 5. We wont affect 99.9% of the read queries as we only do extra work during 
> digest mismatch.
> 6. CL.ONE reads will not be able to detect this. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (CASSANDRA-14409) Transient Replication: Support ring changes when transient replication is in use (add/remove node, change RF, add/remove DC)

2018-09-04 Thread Benedict (JIRA)


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

Benedict commented on CASSANDRA-14409:
--

Fixes:
# We need to include pending transient->full movements in order to ensure 
correctness on write
#* For now at least, pending transient replicas need to receive all writes for 
correctness when they come online; but reads should still not touch them.
#* As it happens, natural and pending are not read in isolation, so these 
conflicts could also occur through races 
#* We introduce some methods to detect conflicts between natural and pending, 
and to always prefer the isFull variant on write; reads continue to use only 
the natural replicas
# RangeStreamer.addRanges; was not correctly disabling for transient replicas 
# sorting bug, and sourceFilters bug when strictness impossible in 
RangeStreamer.calculateRangesToFetchWithPreferredEndpoints
# getOptimisedWorkMap was not properly disabled for transient replication (not 
caught by tests)

Nits:
# de/serializeReplicas: consistent method name, do not serialize endpoint for 
each replica

Follow-ups:
# consider if we need to maintain full->transient self-movements in pending 
ranges 
# bootstrap vs restarting an existing node vs repair (unlike regular repair, 
transient repair drops data - but in some cases we need to accumulate maybe?)
# corroborate nowhere is broken, and we have no negative availability 
implications through maintaining a transient<->full movement in pending (so 
that a single endpoint may be in both pending and natural)
# ring ownership movements can break consistency, in ways that are worse than 
for normal clusters - in lieu of other bugs, and with more full than transient 
replicas in your cluster, it’s probable this would be caught by digest 
mismatches - but this is far from offering our normal guarantees, and we need 
to consider this further

> Transient Replication: Support ring changes when transient replication is in 
> use (add/remove node, change RF, add/remove DC)
> 
>
> Key: CASSANDRA-14409
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14409
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Coordination, Core, Documentation and Website
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Major
> Fix For: 4.0
>
>
> The additional state transitions that transient replication introduces 
> require streaming and nodetool cleanup to behave differently. We already have 
> code that does the streaming, but in some cases we shouldn't stream any data 
> and in others when we stream to receive data we have to make sure we stream 
> from a full replica and not a transient replica.
> Transitioning from not replicated to transiently replicated means that a node 
> must stay pending until the next incremental repair completes at which point 
> the data for that range is known to be available at full replicas.
> Transitioning from transiently replicated to fully replicated requires 
> streaming from a full replica and is identical to how we stream from not 
> replicated to replicated. The transition must be managed so the transient 
> replica is not read from as a full replica until streaming completes. It can 
> be used immediately for a write quorum.
> Transitioning from fully replicated to transiently replicated requires 
> cleanup to remove repaired data from the transiently replicated range to 
> reclaim space. It can be used immediately for a write quorum.
> Transitioning from transiently replicated to not replicated requires cleanup 
> to be run to remove the formerly transiently replicated data.
> nodetool move, removenode, cleanup, decommission, and rebuild need to handle 
> these issues as does bootstrap.
> Update web site, documentation, NEWS.txt with a description of the steps for 
> doing common operations. Add/remove DC, Add/remove node(s), replace node, 
> change RF.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (CASSANDRA-13974) Bad prefix matching when figuring out data directory for an sstable

2018-09-04 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson updated CASSANDRA-13974:

Fix Version/s: 3.0.x

the isContained fix should probably be committed to 3.0 as well, adding 3.0 to 
fix versions

> Bad prefix matching when figuring out data directory for an sstable
> ---
>
> Key: CASSANDRA-13974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13974
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> We do a "startsWith" check when getting data directory for an sstable, we 
> should match including File.separator



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (CASSANDRA-13974) Bad prefix matching when figuring out data directory for an sstable

2018-09-04 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson edited comment on CASSANDRA-13974 at 9/4/18 11:59 AM:
--

seems I totally forgot about this, rebased branch: 
https://github.com/krummas/cassandra/commits/marcuse/13974-2

tests: https://circleci.com/gh/krummas/cassandra/tree/marcuse%2F13974-2

this version also fixes an existing issue with {{FileUtils.isContained}} as it 
also did prefix matching without a separator


was (Author: krummas):
seems I totally forgot about this, rebased branch: 
https://github.com/krummas/cassandra/commits/marcuse/13943-2

tests: https://circleci.com/gh/krummas/cassandra/tree/marcuse%2F13974-2

this version also fixes an existing issue with {{FileUtils.isContained}} as it 
also did prefix matching without a separator

> Bad prefix matching when figuring out data directory for an sstable
> ---
>
> Key: CASSANDRA-13974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13974
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 3.11.x, 4.x
>
>
> We do a "startsWith" check when getting data directory for an sstable, we 
> should match including File.separator



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (CASSANDRA-14407) Transient Replication: Add support for correct reads when transient replication is in use

2018-09-04 Thread Benedict (JIRA)


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

Benedict commented on CASSANDRA-14407:
--

Fixes:
# If a transient replica sorts first by snitch, we could have bad data requests 
(i.e. to transient replicas)
# Ring movement inconsistency can break read consistency more easily with 
transient replication, so we introduce an acceptsTransient property that can be 
used by recipient nodes to reject a query it cannot safely handle (this is 
limited in its power, as both nodes could be behind on gossip wrt a new node 
joining the ring that has bumped the recipient to a transient position from a 
full one, but it’s better than nothing).  This should also help prevent bugs 
like the above, where we request a full data request accidentally from a 
transient replica.
# removed unnecessary ForwardingReadRepair, as we cannot employ read-repair 
with transient replication
# speculating with only one untried node that was transient would have failed 
to speculate

Follow-ups:
# Digest mismatches are not handled well for transient replication - I guess 
ideally this would operate in repaired/unrepaired separately, as we will need 
anyway for monotonic reads


> Transient Replication: Add support for correct reads when transient 
> replication is in use
> -
>
> Key: CASSANDRA-14407
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14407
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Coordination
>Reporter: Ariel Weisberg
>Assignee: Blake Eggleston
>Priority: Major
> Fix For: 4.0
>
>
> Digest reads should never be sent to transient replicas.
> Mismatches with results from transient replicas shouldn't trigger read repair.
> Read repair should never attempt to repair a transient replica.
> Reads should always include at least one full replica. They should also 
> prefer transient replicas where possible.
> Range scans must ensure the entire scanned range performs replica selection 
> that satisfies the requirement that every range scanned includes one full 
> replica.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (CASSANDRA-13974) Bad prefix matching when figuring out data directory for an sstable

2018-09-04 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson updated CASSANDRA-13974:

Status: Patch Available  (was: Open)

seems I totally forgot about this, rebased branch: 
https://github.com/krummas/cassandra/commits/marcuse/13943-2

tests: https://circleci.com/gh/krummas/cassandra/tree/marcuse%2F13974-2

this version also fixes an existing issue with {{FileUtils.isContained}} as it 
also did prefix matching without a separator

> Bad prefix matching when figuring out data directory for an sstable
> ---
>
> Key: CASSANDRA-13974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13974
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 3.11.x, 4.x
>
>
> We do a "startsWith" check when getting data directory for an sstable, we 
> should match including File.separator



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (CASSANDRA-13974) Bad prefix matching when figuring out data directory for an sstable

2018-09-04 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson updated CASSANDRA-13974:

Status: Open  (was: Ready to Commit)

> Bad prefix matching when figuring out data directory for an sstable
> ---
>
> Key: CASSANDRA-13974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13974
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 3.11.x, 4.x
>
>
> We do a "startsWith" check when getting data directory for an sstable, we 
> should match including File.separator



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (CASSANDRA-14406) Transient Replication: Implement cheap quorum write optimizations

2018-09-04 Thread Benedict (JIRA)


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

Benedict commented on CASSANDRA-14406:
--

Fixes:
# StorageProxy.mutate would have attempted a standardWritePerformer 
maybeTryAdditionalReplicas for counters 
# assureSufficientLiveReplicas and blockFor were not transient replication (or 
pending replicas) aware
#* in the case of transient replication, this would mean we did not send enough 
initial writes, because we capped ourselves to blockFor recipients
# AbstractWriteResponseHandler
#* was sending to all remaining replicas in case of failure to meet 
consistency, not only those relevant for consistency
#* hasTransientResponse was racy - could have a transient response arrive after 
checking condition
#** Have introduced {{Accumulator.snapshot}} to make working with it safely 
more obvious
#** We take a snapshot, and look inside the list to decide if we have a 
transient response
# sendMessagesToNonLocalDC was asserting no transient replicas - simply removed 
the assertions, as logic is consistent
# Hints were not implemented, but mostly involved filtering them out; batch log 
will be less trivial when implemented, as currently must hint
# Introduced separate threshold for cheap quorum upgrades
# There was a rare possible race condition when removing transient replication 
from a keyspace, during which period we would not handle transient replicas 
correctly

Nits:
# StorageProxy.mutate used a HashMap, when a List would suffice

Follow-ups pre-4.0:
# We should rename speculative_write_threshold (I thought we agreed on 
transient_write_threshold)?

Follow-ups:
# EACH_QUORUM not implemented for transient replication; must either error or 
implement before release
# we don’t limit our cheap quorum upgrade to the minimum number of additional 
transient replicas, so a single missing response will result in all DCs 
receiving an extra full write mutation, doubling cross-dc traffic for that write
# maybeTryAdditionalReplicas / sendMessagesToNonLocalDC are not DC aware in 
their interactions, so transient writes incur more cross-DC traffic (ideally, 
the proxies would be able to coordinate upgrading to a transient write) 
# we don’t expose metrics around success/failure of cheap quorum
# transient write count isn’t incremented when we perform a non-additional 
write (i.e. due to down full node)

> Transient Replication: Implement cheap quorum write optimizations
> -
>
> Key: CASSANDRA-14406
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14406
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Coordination
>Reporter: Ariel Weisberg
>Assignee: Blake Eggleston
>Priority: Major
> Fix For: 4.0
>
>
> Writes should never be sent to transient replicas unless necessary to satisfy 
> the requested consistency level. Such as RF not being sufficient for strong 
> consistency or not enough full replicas marked as alive.
> If a write doesn't receive sufficient responses in time additional replicas 
> should be sent the write similar to Rapid Read Protection.
> Hints should never be written for a transient replica.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (CASSANDRA-14687) Revert parameterization of AuthCacheMBean interface

2018-09-04 Thread Sam Tunnicliffe (JIRA)


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

Sam Tunnicliffe updated CASSANDRA-14687:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Thanks [~KurtG], committed to trunk in 
{{d26f142b34681d047fe010c8ec9097add0b44d2a}}

> Revert parameterization of AuthCacheMBean interface
> ---
>
> Key: CASSANDRA-14687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14687
> Project: Cassandra
>  Issue Type: Bug
>  Components: Auth
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Major
> Fix For: 4.0
>
>
> In CASSANDRA-14662, a type parameter {{}} and {{invalidate}} method 
> were added to {{AuthCacheMBean}} with the intention that this would 
> automatically expose via JMX the {{invalidate}} method from {{AuthCache}} 
> itself. Actually, this is not the case, as type erasure obscures the actual 
> type of the parameter and so JMX clients like jconsole and jmc disable access 
> to the method. 
> Only {{PasswordAuthenticator.CredentialsCache}} provided method like this 
> previously, via {{CredentialsCacheMBean extends AuthCacheMBean}}, so the most 
> straightforward fix is to just revert the change to {{AuthCacheMBean}}. 
> Future/alternative cache implementations can continue to specify their own 
> MBean interfaces to add specialised methods as before.
> I should've caught this before committing the CASSANDRA-14662 as it broke a 
> couple of dtests in AuthTest, mea culpa.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



cassandra git commit: Remove type parameter from AuthCacheMBean interface

2018-09-04 Thread samt
Repository: cassandra
Updated Branches:
  refs/heads/trunk 65fb17a88 -> d26f142b3


Remove type parameter from AuthCacheMBean interface

Patch by Sam Tunnicliffe; reviewed by Kurt Greaves for CASSANDRA-14687


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

Branch: refs/heads/trunk
Commit: d26f142b34681d047fe010c8ec9097add0b44d2a
Parents: 65fb17a
Author: Sam Tunnicliffe 
Authored: Mon Sep 3 19:36:19 2018 +0100
Committer: Sam Tunnicliffe 
Committed: Tue Sep 4 12:32:35 2018 +0100

--
 src/java/org/apache/cassandra/auth/AuthCache.java | 2 +-
 src/java/org/apache/cassandra/auth/AuthCacheMBean.java| 4 +---
 src/java/org/apache/cassandra/auth/NetworkAuthCache.java  | 1 -
 src/java/org/apache/cassandra/auth/PasswordAuthenticator.java | 2 +-
 4 files changed, 3 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d26f142b/src/java/org/apache/cassandra/auth/AuthCache.java
--
diff --git a/src/java/org/apache/cassandra/auth/AuthCache.java 
b/src/java/org/apache/cassandra/auth/AuthCache.java
index 4f36a63..3adf914 100644
--- a/src/java/org/apache/cassandra/auth/AuthCache.java
+++ b/src/java/org/apache/cassandra/auth/AuthCache.java
@@ -37,7 +37,7 @@ import org.slf4j.LoggerFactory;
 
 import static com.google.common.base.Preconditions.checkNotNull;
 
-public class AuthCache implements AuthCacheMBean
+public class AuthCache implements AuthCacheMBean
 {
 private static final Logger logger = 
LoggerFactory.getLogger(AuthCache.class);
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d26f142b/src/java/org/apache/cassandra/auth/AuthCacheMBean.java
--
diff --git a/src/java/org/apache/cassandra/auth/AuthCacheMBean.java 
b/src/java/org/apache/cassandra/auth/AuthCacheMBean.java
index 1416044..43fb88e 100644
--- a/src/java/org/apache/cassandra/auth/AuthCacheMBean.java
+++ b/src/java/org/apache/cassandra/auth/AuthCacheMBean.java
@@ -18,12 +18,10 @@
 
 package org.apache.cassandra.auth;
 
-public interface AuthCacheMBean
+public interface AuthCacheMBean
 {
 public void invalidate();
 
-public void invalidate(T t);
-
 public void setValidity(int validityPeriod);
 
 public int getValidity();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d26f142b/src/java/org/apache/cassandra/auth/NetworkAuthCache.java
--
diff --git a/src/java/org/apache/cassandra/auth/NetworkAuthCache.java 
b/src/java/org/apache/cassandra/auth/NetworkAuthCache.java
index 0991889..6b3c74e 100644
--- a/src/java/org/apache/cassandra/auth/NetworkAuthCache.java
+++ b/src/java/org/apache/cassandra/auth/NetworkAuthCache.java
@@ -34,5 +34,4 @@ public class NetworkAuthCache extends AuthCache
   authorizer::authorize,
   () -> 
DatabaseDescriptor.getAuthenticator().requireAuthentication());
 }
-
 }

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d26f142b/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
--
diff --git a/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java 
b/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
index b10136e..27a68a0 100644
--- a/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
+++ b/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
@@ -228,7 +228,7 @@ public class PasswordAuthenticator implements IAuthenticator
 }
 }
 
-private static class CredentialsCache extends AuthCache
+private static class CredentialsCache extends AuthCache 
implements CredentialsCacheMBean
 {
 private CredentialsCache(PasswordAuthenticator authenticator)
 {


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



[jira] [Commented] (CASSANDRA-10540) RangeAwareCompaction

2018-09-04 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson commented on CASSANDRA-10540:
-

this patch also needs to handle transient replication (CASSANDRA-14404) - we 
should split transient ranges evenly over all disks to avoid unbalance

> RangeAwareCompaction
> 
>
> Key: CASSANDRA-10540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10540
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
>  Labels: 4.0-feature-freeze-review-requested, compaction, lcs, 
> vnodes
> Fix For: 4.x
>
>
> Broken out from CASSANDRA-6696, we should split sstables based on ranges 
> during compaction.
> Requirements;
> * dont create tiny sstables - keep them bunched together until a single vnode 
> is big enough (configurable how big that is)
> * make it possible to run existing compaction strategies on the per-range 
> sstables
> We should probably add a global compaction strategy parameter that states 
> whether this should be enabled or not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (CASSANDRA-14687) Revert parameterization of AuthCacheMBean interface

2018-09-04 Thread Kurt Greaves (JIRA)


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

Kurt Greaves commented on CASSANDRA-14687:
--

+1. My bad, should have checked that.

> Revert parameterization of AuthCacheMBean interface
> ---
>
> Key: CASSANDRA-14687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14687
> Project: Cassandra
>  Issue Type: Bug
>  Components: Auth
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Major
> Fix For: 4.0
>
>
> In CASSANDRA-14662, a type parameter {{}} and {{invalidate}} method 
> were added to {{AuthCacheMBean}} with the intention that this would 
> automatically expose via JMX the {{invalidate}} method from {{AuthCache}} 
> itself. Actually, this is not the case, as type erasure obscures the actual 
> type of the parameter and so JMX clients like jconsole and jmc disable access 
> to the method. 
> Only {{PasswordAuthenticator.CredentialsCache}} provided method like this 
> previously, via {{CredentialsCacheMBean extends AuthCacheMBean}}, so the most 
> straightforward fix is to just revert the change to {{AuthCacheMBean}}. 
> Future/alternative cache implementations can continue to specify their own 
> MBean interfaces to add specialised methods as before.
> I should've caught this before committing the CASSANDRA-14662 as it broke a 
> couple of dtests in AuthTest, mea culpa.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (CASSANDRA-13262) Incorrect cqlsh results when selecting same columns multiple times

2018-09-04 Thread Benjamin Lerer (JIRA)


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

Benjamin Lerer commented on CASSANDRA-13262:


+1 for me. The patches look good. 
@mck Thanks for your efforts.

> Incorrect cqlsh results when selecting same columns multiple times
> --
>
> Key: CASSANDRA-13262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13262
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefan Podkowinski
>Assignee: Murukesh Mohanan
>Priority: Minor
>  Labels: lhf
> Fix For: 4.0
>
> Attachments: 
> 0001-Fix-incorrect-cqlsh-results-when-selecting-same-colu.patch, 
> CASSANDRA-13262-v2.2.txt, CASSANDRA-13262-v3.0.txt, CASSANDRA-13262-v3.11.txt
>
>
> Just stumbled over this on trunk:
> {quote}
> cqlsh:test1> select a, b, c from table1;
>  a | b| c
> ---+--+-
>  1 |b |   2
>  2 | null | 2.2
> (2 rows)
> cqlsh:test1> select a, a, b, c from table1;
>  a | a| b   | c
> ---+--+-+--
>  1 |b |   2 | null
>  2 | null | 2.2 | null
> (2 rows)
> cqlsh:test1> select a, a, a, b, c from table1;
>  a | a| a | b| c
> ---+--+---+--+--
>  1 |b |   2.0 | null | null
>  2 | null | 2.2004768 | null | null
> {quote}
> My guess is that his is on the Python side, but haven't really looked into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (CASSANDRA-13262) Incorrect cqlsh results when selecting same columns multiple times

2018-09-04 Thread Benjamin Lerer (JIRA)


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

Benjamin Lerer edited comment on CASSANDRA-13262 at 9/4/18 8:04 AM:


+1 for me. The patches look good. 
[~michaelsembwever] Thanks for your efforts.


was (Author: blerer):
+1 for me. The patches look good. 
@mck Thanks for your efforts.

> Incorrect cqlsh results when selecting same columns multiple times
> --
>
> Key: CASSANDRA-13262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13262
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefan Podkowinski
>Assignee: Murukesh Mohanan
>Priority: Minor
>  Labels: lhf
> Fix For: 4.0
>
> Attachments: 
> 0001-Fix-incorrect-cqlsh-results-when-selecting-same-colu.patch, 
> CASSANDRA-13262-v2.2.txt, CASSANDRA-13262-v3.0.txt, CASSANDRA-13262-v3.11.txt
>
>
> Just stumbled over this on trunk:
> {quote}
> cqlsh:test1> select a, b, c from table1;
>  a | b| c
> ---+--+-
>  1 |b |   2
>  2 | null | 2.2
> (2 rows)
> cqlsh:test1> select a, a, b, c from table1;
>  a | a| b   | c
> ---+--+-+--
>  1 |b |   2 | null
>  2 | null | 2.2 | null
> (2 rows)
> cqlsh:test1> select a, a, a, b, c from table1;
>  a | a| a | b| c
> ---+--+---+--+--
>  1 |b |   2.0 | null | null
>  2 | null | 2.2004768 | null | null
> {quote}
> My guess is that his is on the Python side, but haven't really looked into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (CASSANDRA-14688) Update protocol spec and class level doc with protocol checksumming details

2018-09-04 Thread Sam Tunnicliffe (JIRA)
Sam Tunnicliffe created CASSANDRA-14688:
---

 Summary: Update protocol spec and class level doc with protocol 
checksumming details
 Key: CASSANDRA-14688
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14688
 Project: Cassandra
  Issue Type: Task
  Components: Documentation and Website
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
 Fix For: 4.0


CASSANDRA-13304 provides an option to add checksumming to the frame body of 
native protocol messages. The native protocol spec needs to be updated to 
reflect this ASAP. We should also verify that the javadoc comments describing 
the on-wire format in 
{{o.a.c.transport.frame.checksum.ChecksummingTransformer}} are up to date.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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