[jira] [Updated] (CASSANDRA-15666) Race condition when completing stream sessions

[ZhaoYang (Jira)]

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

ZhaoYang updated CASSANDRA-15666:
-
Test and Documentation Plan: 
Added interceptor to verify stream messages and state transition.

 CI: [https://circleci.com/workflow-run/4d524604-99f8-4c74-b24a-b31e63bce063]

  dtest failure "repair_test.py" is fixed in 
[https://github.com/apache/cassandra-dtest/pull/63]
  
 

  was:
Added interceptor to verify stream messages and state transition.

 CI: [https://circleci.com/workflow-run/6e78ca49-9680-45d9-9016-fc85112a1dde]

  dtest failure "repair_test.py" is fixed in 
[https://github.com/apache/cassandra-dtest/pull/63]
  


> Race condition when completing stream sessions
> --
>
> Key: CASSANDRA-15666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15666
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: ZhaoYang
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{StreamSession#prepareAsync()}} executes, as the name implies, 
> asynchronously from the IO thread: this opens up for race conditions between 
> the sending of the {{PrepareSynAckMessage}} and the call to 
> {{StreamSession#maybeCompleted()}}. I.e., the following could happen:
> 1) Node A sends {{PrepareSynAckMessage}} from the {{prepareAsync()}} thread.
> 2) Node B receives it and starts streaming.
> 3) Node A receives the streamed file and sends {{ReceivedMessage}}.
> 4) At this point, if this was the only file to stream, both nodes are ready 
> to close the session via {{maybeCompleted()}}, but:
> a) Node A will call it twice from both the IO thread and the thread at #1, 
> closing the session and its channels.
> b) Node B will attempt to send a {{CompleteMessage}}, but will fail because 
> the session has been closed in the meantime.
> There are other subtle variations of the pattern above, depending on the 
> order of concurrently sent/received messages.
> I believe the best fix would be to modify the message exchange so that:
> 1) Only the "follower" is allowed to send the {{CompleteMessage}}.
> 2) Only the "initiator" is allowed to close the session and its channels 
> after receiving the {{CompleteMessage}}.
> By doing so, the message exchange logic would be easier to reason about, 
> which is overall a win anyway.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-14747) Evaluate 200 node, compression=none, encryption=none, coalescing=off

[Benjamin Lerer (Jira)]

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

Benjamin Lerer commented on CASSANDRA-14747:


[~vinaykumarcse], [~jolynch] It might make sense for you to wait for 
CASSANDRA-15700 as it might have an impact on your test results.

> Evaluate 200 node, compression=none, encryption=none, coalescing=off 
> -
>
> Key: CASSANDRA-14747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14747
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Legacy/Testing
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: 3.0.17-QPS.png, 4.0.1-QPS.png, 
> 4.0.11-after-jolynch-tweaks.svg, 4.0.12-after-unconditional-flush.svg, 
> 4.0.15-after-sndbuf-fix.svg, 4.0.7-before-my-changes.svg, 
> 4.0_errors_showing_heap_pressure.txt, 
> 4.0_heap_histogram_showing_many_MessageOuts.txt, 
> i-0ed2acd2dfacab7c1-after-looping-fixes.svg, 
> trunk_14503_v2_cpuflamegraph.svg, trunk_vs_3.0.17_latency_under_load.png, 
> ttop_NettyOutbound-Thread_spinning.txt, 
> useast1c-i-0e1ddfe8b2f769060-mutation-flame.svg, 
> useast1e-i-08635fa1631601538_flamegraph_96node.svg, 
> useast1e-i-08635fa1631601538_ttop_netty_outbound_threads_96nodes, 
> useast1e-i-08635fa1631601538_uninlinedcpuflamegraph.0_96node_60sec_profile.svg
>
>
> Tracks evaluating a 200 node cluster with all internode settings off (no 
> compression, no encryption, no coalescing).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-14747) Test Messaging Refactor with: 200 node, compression=none, encryption=none, coalescing=off

[Benjamin Lerer (Jira)]

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

Benjamin Lerer updated CASSANDRA-14747:
---
Summary: Test Messaging Refactor with: 200 node, compression=none, 
encryption=none, coalescing=off   (was: Evaluate 200 node, compression=none, 
encryption=none, coalescing=off )

> Test Messaging Refactor with: 200 node, compression=none, encryption=none, 
> coalescing=off 
> --
>
> Key: CASSANDRA-14747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14747
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Legacy/Testing
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: 3.0.17-QPS.png, 4.0.1-QPS.png, 
> 4.0.11-after-jolynch-tweaks.svg, 4.0.12-after-unconditional-flush.svg, 
> 4.0.15-after-sndbuf-fix.svg, 4.0.7-before-my-changes.svg, 
> 4.0_errors_showing_heap_pressure.txt, 
> 4.0_heap_histogram_showing_many_MessageOuts.txt, 
> i-0ed2acd2dfacab7c1-after-looping-fixes.svg, 
> trunk_14503_v2_cpuflamegraph.svg, trunk_vs_3.0.17_latency_under_load.png, 
> ttop_NettyOutbound-Thread_spinning.txt, 
> useast1c-i-0e1ddfe8b2f769060-mutation-flame.svg, 
> useast1e-i-08635fa1631601538_flamegraph_96node.svg, 
> useast1e-i-08635fa1631601538_ttop_netty_outbound_threads_96nodes, 
> useast1e-i-08635fa1631601538_uninlinedcpuflamegraph.0_96node_60sec_profile.svg
>
>
> Tracks evaluating a 200 node cluster with all internode settings off (no 
> compression, no encryption, no coalescing).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-14747) Test Messaging Refactor with: 200 node, compression=none, encryption=none, coalescing=off

[Benjamin Lerer (Jira)]

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

Benjamin Lerer updated CASSANDRA-14747:
---
Fix Version/s: (was: 4.0-beta)
   4.0-rc

> Test Messaging Refactor with: 200 node, compression=none, encryption=none, 
> coalescing=off 
> --
>
> Key: CASSANDRA-14747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14747
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Legacy/Testing
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: 3.0.17-QPS.png, 4.0.1-QPS.png, 
> 4.0.11-after-jolynch-tweaks.svg, 4.0.12-after-unconditional-flush.svg, 
> 4.0.15-after-sndbuf-fix.svg, 4.0.7-before-my-changes.svg, 
> 4.0_errors_showing_heap_pressure.txt, 
> 4.0_heap_histogram_showing_many_MessageOuts.txt, 
> i-0ed2acd2dfacab7c1-after-looping-fixes.svg, 
> trunk_14503_v2_cpuflamegraph.svg, trunk_vs_3.0.17_latency_under_load.png, 
> ttop_NettyOutbound-Thread_spinning.txt, 
> useast1c-i-0e1ddfe8b2f769060-mutation-flame.svg, 
> useast1e-i-08635fa1631601538_flamegraph_96node.svg, 
> useast1e-i-08635fa1631601538_ttop_netty_outbound_threads_96nodes, 
> useast1e-i-08635fa1631601538_uninlinedcpuflamegraph.0_96node_60sec_profile.svg
>
>
> Tracks evaluating a 200 node cluster with all internode settings off (no 
> compression, no encryption, no coalescing).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-14747) Test Messaging Refactor with: 200 node, compression=none, encryption=none, coalescing=off

[Benjamin Lerer (Jira)]

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

Benjamin Lerer commented on CASSANDRA-14747:


I moved the ticket to 4.0-GA to give your more time to run the tests. Feel free 
to change it back if needed.

> Test Messaging Refactor with: 200 node, compression=none, encryption=none, 
> coalescing=off 
> --
>
> Key: CASSANDRA-14747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14747
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Legacy/Testing
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: 3.0.17-QPS.png, 4.0.1-QPS.png, 
> 4.0.11-after-jolynch-tweaks.svg, 4.0.12-after-unconditional-flush.svg, 
> 4.0.15-after-sndbuf-fix.svg, 4.0.7-before-my-changes.svg, 
> 4.0_errors_showing_heap_pressure.txt, 
> 4.0_heap_histogram_showing_many_MessageOuts.txt, 
> i-0ed2acd2dfacab7c1-after-looping-fixes.svg, 
> trunk_14503_v2_cpuflamegraph.svg, trunk_vs_3.0.17_latency_under_load.png, 
> ttop_NettyOutbound-Thread_spinning.txt, 
> useast1c-i-0e1ddfe8b2f769060-mutation-flame.svg, 
> useast1e-i-08635fa1631601538_flamegraph_96node.svg, 
> useast1e-i-08635fa1631601538_ttop_netty_outbound_threads_96nodes, 
> useast1e-i-08635fa1631601538_uninlinedcpuflamegraph.0_96node_60sec_profile.svg
>
>
> Tracks evaluating a 200 node cluster with all internode settings off (no 
> compression, no encryption, no coalescing).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-14747) Test Messaging Refactor with: 200 node, compression=none, encryption=none, coalescing=off

[Benjamin Lerer (Jira)]

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

Benjamin Lerer edited comment on CASSANDRA-14747 at 4/24/20, 8:36 AM:
--

I moved the ticket to 4.0-GA to give your more time to run the tests. Feel free 
to change it back if needed. :-)


was (Author: blerer):
I moved the ticket to 4.0-GA to give your more time to run the tests. Feel free 
to change it back if needed.

> Test Messaging Refactor with: 200 node, compression=none, encryption=none, 
> coalescing=off 
> --
>
> Key: CASSANDRA-14747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14747
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Legacy/Testing
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: 3.0.17-QPS.png, 4.0.1-QPS.png, 
> 4.0.11-after-jolynch-tweaks.svg, 4.0.12-after-unconditional-flush.svg, 
> 4.0.15-after-sndbuf-fix.svg, 4.0.7-before-my-changes.svg, 
> 4.0_errors_showing_heap_pressure.txt, 
> 4.0_heap_histogram_showing_many_MessageOuts.txt, 
> i-0ed2acd2dfacab7c1-after-looping-fixes.svg, 
> trunk_14503_v2_cpuflamegraph.svg, trunk_vs_3.0.17_latency_under_load.png, 
> ttop_NettyOutbound-Thread_spinning.txt, 
> useast1c-i-0e1ddfe8b2f769060-mutation-flame.svg, 
> useast1e-i-08635fa1631601538_flamegraph_96node.svg, 
> useast1e-i-08635fa1631601538_ttop_netty_outbound_threads_96nodes, 
> useast1e-i-08635fa1631601538_uninlinedcpuflamegraph.0_96node_60sec_profile.svg
>
>
> Tracks evaluating a 200 node cluster with all internode settings off (no 
> compression, no encryption, no coalescing).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-13666) Secondary index query on partition key columns might not return partitions with only static data

[Berenguer Blasi (Jira)]

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

Berenguer Blasi commented on CASSANDRA-13666:
-

CI runs in PRs:
- [cassandra 3.0|https://github.com/apache/cassandra/pull/559]
- [cassandra 3.11|https://github.com/apache/cassandra/pull/564]
- [cassandra trunk|https://github.com/apache/cassandra/pull/565]

> Secondary index query on partition key columns might not return partitions 
> with only static data
> 
>
> Key: CASSANDRA-13666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13666
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/2i Index
>Reporter: Benjamin Lerer
>Assignee: Berenguer Blasi
>Priority: Normal
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The problem can be reproduced with the following test in {{3.0}}:
> {code}
>@Test
> public void testIndexOnPartitionKeyWithPartitionWithoutRows() throws 
> Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, s int static, 
> v int, PRIMARY KEY((pk1, pk2), c))");
> createIndex("CREATE INDEX ON %s (pk2)");
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)", 
> 1, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)", 
> 1, 1, 2, 9, 2);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)", 
> 3, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)", 
> 4, 1, 1, 9, 1);
> flush();
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, 1, 9, 1),
>row(4, 1, 1, 9, 1));
> execute("DELETE FROM %s WHERE pk1 = ? AND pk2 = ? AND c = ?", 3, 1, 
> 1);
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, null, 9, null),  // This row will not be returned
>row(4, 1, 1, 9, 1));
> }
> {code}
> The problem seems to be that the index entries for the static data are 
> inserted with an empty clustering key. When the first {{SELECT}} is executed 
> those entries are removed by {{CompositesSearcher::filterStaleEntries}} which 
> consider that those entries are stales. When the second {{SELECT}} is 
> executed the index ignore the (3, 1) partition as there is not entry for it 
> anymore.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-13666) Secondary index query on partition key columns might not return partitions with only static data

[Berenguer Blasi (Jira)]

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

Berenguer Blasi updated CASSANDRA-13666:

Test and Documentation Plan: Attched to PRs
 Status: Patch Available  (was: In Progress)

> Secondary index query on partition key columns might not return partitions 
> with only static data
> 
>
> Key: CASSANDRA-13666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13666
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/2i Index
>Reporter: Benjamin Lerer
>Assignee: Berenguer Blasi
>Priority: Normal
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The problem can be reproduced with the following test in {{3.0}}:
> {code}
>@Test
> public void testIndexOnPartitionKeyWithPartitionWithoutRows() throws 
> Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, s int static, 
> v int, PRIMARY KEY((pk1, pk2), c))");
> createIndex("CREATE INDEX ON %s (pk2)");
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)", 
> 1, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)", 
> 1, 1, 2, 9, 2);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)", 
> 3, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)", 
> 4, 1, 1, 9, 1);
> flush();
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, 1, 9, 1),
>row(4, 1, 1, 9, 1));
> execute("DELETE FROM %s WHERE pk1 = ? AND pk2 = ? AND c = ?", 3, 1, 
> 1);
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, null, 9, null),  // This row will not be returned
>row(4, 1, 1, 9, 1));
> }
> {code}
> The problem seems to be that the index entries for the static data are 
> inserted with an empty clustering key. When the first {{SELECT}} is executed 
> those entries are removed by {{CompositesSearcher::filterStaleEntries}} which 
> consider that those entries are stales. When the second {{SELECT}} is 
> executed the index ignore the (3, 1) partition as there is not entry for it 
> anymore.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra-dtest] branch master updated: Ignore EOF error log for repair_test.py::TestRepair::test_dead_sync_participant

[blerer]

This is an automated email from the ASF dual-hosted git repository.

blerer pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git


The following commit(s) were added to refs/heads/master by this push:
 new fdc800c  Ignore EOF error log for 
repair_test.py::TestRepair::test_dead_sync_participant
fdc800c is described below

commit fdc800cc716b465a335b10230481866cf598110a
Author: Zhao Yang 
AuthorDate: Mon Apr 13 00:44:28 2020 +0800

Ignore EOF error log for 
repair_test.py::TestRepair::test_dead_sync_participant

patch by ZhaoYang; reviewed by Sergio Bossa and Benjamin Lerer for
CASSANDRA-15666
---
 repair_tests/repair_test.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/repair_tests/repair_test.py b/repair_tests/repair_test.py
index b28ec49..83eed8d 100644
--- a/repair_tests/repair_test.py
+++ b/repair_tests/repair_test.py
@@ -1171,6 +1171,12 @@ class TestRepair(BaseRepairTest):
 "failed to send a stream message/data to peer"
 ]
 
+# stream session will be closed upon EOF, see CASSANDRA-15666
+if cluster.version() >= '4.0':
+self.ignore_log_patterns.append("Socket closed before session 
completion")
+self.ignore_log_patterns.append("is finished with state FAILED")
+self.ignore_log_patterns.append("stream has been closed")
+
 # Disable hinted handoff and set batch commit log so this doesn't
 # interfere with the test (this must be after the populate)
 cluster.set_configuration_options(values={'hinted_handoff_enabled': 
False})


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

[cassandra] branch trunk updated: Avoid race condition when completing stream sessions

[blerer]

This is an automated email from the ASF dual-hosted git repository.

blerer pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/trunk by this push:
 new 9f6fcc3  Avoid race condition when completing stream sessions
9f6fcc3 is described below

commit 9f6fcc340d89eecc000765f6ab93e862f53a02d9
Author: Zhao Yang 
AuthorDate: Fri Mar 20 15:56:53 2020 +0800

Avoid race condition when completing stream sessions

patch by ZhaoYang; reviewed by Sergio Bossa and Benjamin Lerer for
CASSANDRA-15666
---
 .circleci/config.yml   | 174 +-
 CHANGES.txt|   1 +
 .../streaming/CassandraCompressedStreamWriter.java |   2 +-
 .../db/streaming/CassandraStreamWriter.java|   2 +-
 .../org/apache/cassandra/io/util/ChannelProxy.java |  10 +
 .../apache/cassandra/net/OutboundConnection.java   |   4 +-
 .../org/apache/cassandra/service/QueryState.java   |   2 +-
 .../cassandra/streaming/StreamCoordinator.java |  15 +-
 .../apache/cassandra/streaming/StreamManager.java  |  28 +-
 .../org/apache/cassandra/streaming/StreamPlan.java |   4 +-
 .../cassandra/streaming/StreamResultFuture.java|  31 +-
 .../apache/cassandra/streaming/StreamSession.java  | 352 +++--
 .../async/NettyStreamingMessageSender.java |  60 +++-
 .../streaming/async/StreamingInboundHandler.java   |  17 +-
 .../streaming/messages/CompleteMessage.java|   2 +-
 .../streaming/messages/IncomingStreamMessage.java  |   4 +-
 .../streaming/messages/KeepAliveMessage.java   |   2 +-
 .../streaming/messages/OutgoingStreamMessage.java  |   2 +-
 .../streaming/messages/PrepareAckMessage.java  |   2 +-
 .../streaming/messages/PrepareSynAckMessage.java   |   2 +-
 .../streaming/messages/PrepareSynMessage.java  |   2 +-
 .../streaming/messages/ReceivedMessage.java|   2 +-
 .../streaming/messages/SessionFailedMessage.java   |   2 +-
 .../streaming/messages/StreamInitMessage.java  |   2 +-
 .../streaming/messages/StreamMessage.java  |   6 +-
 .../org/apache/cassandra/utils/FBUtilities.java|  75 +
 .../cassandra/distributed/test/StreamingTest.java  | 107 +++
 .../microbench/ZeroCopyStreamingBenchmark.java |   4 +-
 .../CassandraEntireSSTableStreamWriterTest.java|   4 +-
 .../db/streaming/CassandraStreamManagerTest.java   |   1 +
 .../apache/cassandra/dht/StreamStateStoreTest.java |   4 +-
 ...ntireSSTableStreamingCorrectFilesCountTest.java |   9 +-
 .../streaming/StreamTransferTaskTest.java  |  10 +-
 .../async/NettyStreamingMessageSenderTest.java |   6 +-
 .../async/StreamingInboundHandlerTest.java |   6 +-
 35 files changed, 673 insertions(+), 283 deletions(-)

diff --git a/.circleci/config.yml b/.circleci/config.yml
index 7f6c93b..7231d67 100644
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@ -3,7 +3,7 @@ jobs:
   j8_jvm_upgrade_dtests:
 docker:
 - image: nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200406
-resource_class: medium
+resource_class: xlarge
 working_directory: ~/
 shell: /bin/bash -eo pipefail -l
 parallelism: 1
@@ -85,8 +85,8 @@ jobs:
 - CASS_DRIVER_NO_EXTENSIONS: true
 - CASS_DRIVER_NO_CYTHON: true
 - CASSANDRA_SKIP_SYNC: true
-- DTEST_REPO: git://github.com/apache/cassandra-dtest.git
-- DTEST_BRANCH: master
+- DTEST_REPO: git://github.com/jasonstack/cassandra-dtest.git
+- DTEST_BRANCH: CASSANDRA-15666
 - CCM_MAX_HEAP_SIZE: 1024M
 - CCM_HEAP_NEWSIZE: 256M
 - JAVA_HOME: /usr/lib/jvm/java-8-openjdk-amd64
@@ -94,7 +94,7 @@ jobs:
   j8_cqlsh-dtests-py2-with-vnodes:
 docker:
 - image: nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200406
-resource_class: medium
+resource_class: xlarge
 working_directory: ~/
 shell: /bin/bash -eo pipefail -l
 parallelism: 4
@@ -162,8 +162,8 @@ jobs:
 - CASS_DRIVER_NO_EXTENSIONS: true
 - CASS_DRIVER_NO_CYTHON: true
 - CASSANDRA_SKIP_SYNC: true
-- DTEST_REPO: git://github.com/apache/cassandra-dtest.git
-- DTEST_BRANCH: master
+- DTEST_REPO: git://github.com/jasonstack/cassandra-dtest.git
+- DTEST_BRANCH: CASSANDRA-15666
 - CCM_MAX_HEAP_SIZE: 1024M
 - CCM_HEAP_NEWSIZE: 256M
 - JAVA_HOME: /usr/lib/jvm/java-8-openjdk-amd64
@@ -171,7 +171,7 @@ jobs:
   j11_unit_tests:
 docker:
 - image: nastra/cassandra-testing-ubuntu1910-java11:20200406
-resource_class: medium
+resource_class: xlarge
 working_directory: ~/
 shell: /bin/bash -eo pipefail -l
 parallelism: 4
@@ -253,8 +253,8 @@ jobs:
 - CASS_DRIVER_NO_EXTENSIONS: true
 - CASS_DRIVER_NO_CYTHON: true
 - CASSANDRA_SKIP_SYNC: true
-- DTEST_REPO: git://github.com/apache/cassandra-dtest.git
-- DTEST_BRANCH: master
+- DTEST_REPO: git://github.com/jasonstack/cassandra-dtest.git
+- 

[jira] [Updated] (CASSANDRA-15666) Race condition when completing stream sessions

[Benjamin Lerer (Jira)]

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

Benjamin Lerer updated CASSANDRA-15666:
---
  Fix Version/s: (was: 4.0)
 4.0-alpha
  Since Version: 4.0-alpha
Source Control Link: 
[patch|https://github.com/apache/cassandra/commit/9f6fcc340d89eecc000765f6ab93e862f53a02d9],
 
[dtest|https://github.com/apache/cassandra-dtest/commit/fdc800cc716b465a335b10230481866cf598110a]
  (was: [patch|https://github.com/apache/cassandra/pull/497], 
[dtest|https://github.com/apache/cassandra-dtest/pull/63])
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Patch committed into trunk at 9f6fcc340d89eecc000765f6ab93e862f53a02d9
DTest committed into master at fdc800cc716b465a335b10230481866cf598110a

> Race condition when completing stream sessions
> --
>
> Key: CASSANDRA-15666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15666
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: ZhaoYang
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-alpha
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{StreamSession#prepareAsync()}} executes, as the name implies, 
> asynchronously from the IO thread: this opens up for race conditions between 
> the sending of the {{PrepareSynAckMessage}} and the call to 
> {{StreamSession#maybeCompleted()}}. I.e., the following could happen:
> 1) Node A sends {{PrepareSynAckMessage}} from the {{prepareAsync()}} thread.
> 2) Node B receives it and starts streaming.
> 3) Node A receives the streamed file and sends {{ReceivedMessage}}.
> 4) At this point, if this was the only file to stream, both nodes are ready 
> to close the session via {{maybeCompleted()}}, but:
> a) Node A will call it twice from both the IO thread and the thread at #1, 
> closing the session and its channels.
> b) Node B will attempt to send a {{CompleteMessage}}, but will fail because 
> the session has been closed in the meantime.
> There are other subtle variations of the pattern above, depending on the 
> order of concurrently sent/received messages.
> I believe the best fix would be to modify the message exchange so that:
> 1) Only the "follower" is allowed to send the {{CompleteMessage}}.
> 2) Only the "initiator" is allowed to close the session and its channels 
> after receiving the {{CompleteMessage}}.
> By doing so, the message exchange logic would be easier to reason about, 
> which is overall a win anyway.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15666) Race condition when completing stream sessions

[ZhaoYang (Jira)]

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

ZhaoYang commented on CASSANDRA-15666:
--

thanks for the review and feedback~

> Race condition when completing stream sessions
> --
>
> Key: CASSANDRA-15666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15666
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: ZhaoYang
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0-alpha
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {{StreamSession#prepareAsync()}} executes, as the name implies, 
> asynchronously from the IO thread: this opens up for race conditions between 
> the sending of the {{PrepareSynAckMessage}} and the call to 
> {{StreamSession#maybeCompleted()}}. I.e., the following could happen:
> 1) Node A sends {{PrepareSynAckMessage}} from the {{prepareAsync()}} thread.
> 2) Node B receives it and starts streaming.
> 3) Node A receives the streamed file and sends {{ReceivedMessage}}.
> 4) At this point, if this was the only file to stream, both nodes are ready 
> to close the session via {{maybeCompleted()}}, but:
> a) Node A will call it twice from both the IO thread and the thread at #1, 
> closing the session and its channels.
> b) Node B will attempt to send a {{CompleteMessage}}, but will fail because 
> the session has been closed in the meantime.
> There are other subtle variations of the pattern above, depending on the 
> order of concurrently sent/received messages.
> I believe the best fix would be to modify the message exchange so that:
> 1) Only the "follower" is allowed to send the {{CompleteMessage}}.
> 2) Only the "initiator" is allowed to close the session and its channels 
> after receiving the {{CompleteMessage}}.
> By doing so, the message exchange logic would be easier to reason about, 
> which is overall a win anyway.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

svn commit: r39087 - /dev/cassandra/4.0-alpha4/ /release/cassandra/4.0-alpha4/

[mck]

Author: mck
Date: Fri Apr 24 10:00:07 2020
New Revision: 39087

Log:
Apache Cassandra 4.0-alpha4 release

Added:
release/cassandra/4.0-alpha4/
  - copied from r39086, dev/cassandra/4.0-alpha4/
Removed:
dev/cassandra/4.0-alpha4/


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

[cassandra] annotated tag cassandra-4.0-alpha4 created (now 12d8b41)

[mck]

This is an automated email from the ASF dual-hosted git repository.

mck pushed a change to annotated tag cassandra-4.0-alpha4
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


  at 12d8b41  (tag)
 tagging d00c004cc10986fc41c2070f9c5d0007e03a45c3 (commit)
 replaces cassandra-4.0-alpha3
  by Mick Semb Wever
  on Fri Apr 24 11:55:30 2020 +0200

- Log -
Apache Cassandra 4.0-alpha4 release
---

No new revisions were added by this update.


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

[cassandra] tag 4.0-alpha4-tentative deleted (was d00c004)

[mck]

This is an automated email from the ASF dual-hosted git repository.

mck pushed a change to tag 4.0-alpha4-tentative
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


*** WARNING: tag 4.0-alpha4-tentative was deleted! ***

 was d00c004  Prepare debian changelog for 4.0-alpha4

The revisions that were on this tag are still contained in
other references; therefore, this change does not discard any commits
from the repository.


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

[jira] [Updated] (CASSANDRA-14242) Indexed static column returns inconsistent results

[Benjamin Lerer (Jira)]

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

Benjamin Lerer updated CASSANDRA-14242:
---
Reviewers: Benjamin Lerer, Benjamin Lerer  (was: Benjamin Lerer)
   Benjamin Lerer, Benjamin Lerer  (was: Benjamin Lerer)
   Status: Review In Progress  (was: Patch Available)

> Indexed static column returns inconsistent results
> --
>
> Key: CASSANDRA-14242
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14242
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/2i Index
> Environment: Cassandra 3.11.2
> Java driver 3.4.0
> Ubuntu - 4.4.0-112-generic
>Reporter: Ross Black
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I am using Cassandra 3.11.2, and the Java driver 3.4.0
> I have a table that has a static column, where the static column has a 
> secondary index.
> When querying the table I get incomplete or duplicated results, depending on 
> the fetch size.
> e.g.
> {code:java}
> CREATE KEYSPACE hack WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> CREATE TABLE hack.stuff (id int, kind text, chunk int static, val1 int, 
> PRIMARY KEY (id, kind));
> CREATE INDEX stuff_chunk_index ON hack.stuff (chunk);{code}
> -- repeat with thousands of values for id =>
> {code:java}
>   INSERT INTO hack.stuff (id, chunk, kind, val1 ) VALUES (${id}, 777, 'A', 
> 123);{code}
> Querying from Java:
> {code:java}
>     final SimpleStatement statement = new SimpleStatement("SELECT id, kind, 
> val1 FROM hack.stuff WHERE chunk = " + chunk); 
>     statement.setFetchSize(fetchSize);
>     statement.setConsistencyLevel(ConsistencyLevel.ALL);
>     final ResultSet resultSet = connection.getSession().execute(statement);
>     for (Row row : resultSet) {
>     final int id = row.getInt("id");
>     }{code}
> *The number of results returned depends on the fetch-size.*
> e.g. For 30k values inserted, I get the following:
> ||fetch-size||result-size||
> |4|3|
> |2|30001|
> |5000|30006|
> |100|30303|
> In production, I have a much larger table where the correct result size for a 
> specific chunk is 20019, but some fetch sizes will return _significantly 
> fewer_ results.
> ||fetch-size||result-size|| ||
> |25000|20019| |
> |5000||*<== this one is has far fewer results*|
> |5001|20026| |
> (so far been unable to reproduce this with the simpler test table)
> Thanks,
> Ross



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15665) StreamManager should clearly differentiate between "initiator" and "receiver" sessions

[ZhaoYang (Jira)]

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

ZhaoYang updated CASSANDRA-15665:
-
Test and Documentation Plan: CI pending: 
[https://circleci.com/workflow-run/e2e5bf69-58a9-45e7-aed7-a05ebf022c2e]  (was: 
CI pending: 
[https://circleci.com/workflow-run/bd115daa-88d4-49f6-b710-fe8a38315cc8])

> StreamManager should clearly differentiate between "initiator" and "receiver" 
> sessions
> --
>
> Key: CASSANDRA-15665
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15665
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0
>
>
> {{StreamManager}} does currently a suboptimal job in differentiating between 
> stream sessions (in form of {{StreamResultFuture}}) which have been either 
> initiated or "received", for the following reasons:
> 1) Naming is IMO confusing: a "receiver" session could actually both send and 
> receive files, so technically an initiator is also a receiver.
> 2) {{StreamManager#findSession()}}  assumes we should first looking into 
> "initiator" sessions, then into "receiver" ones: this is a dangerous 
> assumptions, in particular for test environments where the same process could 
> work as both an initiator and a receiver.
> I would recommend the following changes:
> 1) Rename "receiver" with "follower" everywhere the former is used.
> 2) Introduce a new flag into {{StreamMessageHeader}} to signal if the message 
> comes from an initiator or follower session, in order to correctly 
> differentiate and look for sessions in {{StreamManager}}.
> While my arguments above might seem trivial, I believe they will improve 
> clarity and save from potential bugs/headaches at testing time, and doing 
> such changes now that we're revamping streaming for 4.0 seems the right time.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

svn commit: r39088 - in /release/cassandra: 4.0-alpha4/debian/pool/main/c/cassandra/cassandra-tools_4.0~alpha4_all.deb debian/pool/main/c/cassandra/cassandra-tools_4.0~alpha4_all.deb

[mck]

Author: mck
Date: Fri Apr 24 11:27:33 2020
New Revision: 39088

Log:
Apache Cassandra 4.0-alpha4 debian artifact cassandra-tools_4.0~alpha4_all.deb

Added:

release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_4.0~alpha4_all.deb
  - copied unchanged from r39087, 
release/cassandra/4.0-alpha4/debian/pool/main/c/cassandra/cassandra-tools_4.0~alpha4_all.deb
Removed:

release/cassandra/4.0-alpha4/debian/pool/main/c/cassandra/cassandra-tools_4.0~alpha4_all.deb


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

svn commit: r39089 - in /release/cassandra: 4.0-alpha4/debian/pool/main/c/cassandra/cassandra_4.0~alpha4.dsc debian/pool/main/c/cassandra/cassandra_4.0~alpha4.dsc

[mck]

Author: mck
Date: Fri Apr 24 11:27:37 2020
New Revision: 39089

Log:
Apache Cassandra 4.0-alpha4 debian artifact cassandra_4.0~alpha4.dsc

Added:
release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0~alpha4.dsc
  - copied unchanged from r39088, 
release/cassandra/4.0-alpha4/debian/pool/main/c/cassandra/cassandra_4.0~alpha4.dsc
Removed:

release/cassandra/4.0-alpha4/debian/pool/main/c/cassandra/cassandra_4.0~alpha4.dsc


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

svn commit: r39095 - in /release/cassandra: 4.0-alpha4/redhat/ redhat/40x/

[mck]

Author: mck
Date: Fri Apr 24 11:28:02 2020
New Revision: 39095

Log:
Apache Cassandra 4.0-alpha4 redhat artifacts

Added:
release/cassandra/redhat/40x/
  - copied from r39094, release/cassandra/4.0-alpha4/redhat/
Removed:
release/cassandra/4.0-alpha4/redhat/


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

svn commit: r39090 - in /release/cassandra: 4.0-alpha4/debian/pool/main/c/cassandra/cassandra_4.0~alpha4.tar.gz debian/pool/main/c/cassandra/cassandra_4.0~alpha4.tar.gz

[mck]

Author: mck
Date: Fri Apr 24 11:27:43 2020
New Revision: 39090

Log:
Apache Cassandra 4.0-alpha4 debian artifact cassandra_4.0~alpha4.tar.gz

Added:
release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0~alpha4.tar.gz
  - copied unchanged from r39089, 
release/cassandra/4.0-alpha4/debian/pool/main/c/cassandra/cassandra_4.0~alpha4.tar.gz
Removed:

release/cassandra/4.0-alpha4/debian/pool/main/c/cassandra/cassandra_4.0~alpha4.tar.gz


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

svn commit: r39091 - in /release/cassandra: 4.0-alpha4/debian/pool/main/c/cassandra/cassandra_4.0~alpha4_all.deb debian/pool/main/c/cassandra/cassandra_4.0~alpha4_all.deb

[mck]

Author: mck
Date: Fri Apr 24 11:27:49 2020
New Revision: 39091

Log:
Apache Cassandra 4.0-alpha4 debian artifact cassandra_4.0~alpha4_all.deb

Added:
release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0~alpha4_all.deb
  - copied unchanged from r39090, 
release/cassandra/4.0-alpha4/debian/pool/main/c/cassandra/cassandra_4.0~alpha4_all.deb
Removed:

release/cassandra/4.0-alpha4/debian/pool/main/c/cassandra/cassandra_4.0~alpha4_all.deb


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

svn commit: r39093 - in /release/cassandra: 4.0-alpha4/debian/dists/40x/ debian/dists/40x/

[mck]

Author: mck
Date: Fri Apr 24 11:27:56 2020
New Revision: 39093

Log:
Apache Cassandra 4.0-alpha4 debian artifacts

Added:
release/cassandra/debian/dists/40x/
  - copied from r39092, release/cassandra/4.0-alpha4/debian/dists/40x/
Removed:
release/cassandra/4.0-alpha4/debian/dists/40x/


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

svn commit: r39094 - /release/cassandra/redhat/40x/

[mck]

Author: mck
Date: Fri Apr 24 11:27:59 2020
New Revision: 39094

Log:
Apache Cassandra 4.0-alpha4 redhat artifacts

Removed:
release/cassandra/redhat/40x/


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

svn commit: r39092 - /release/cassandra/debian/dists/40x/

[mck]

Author: mck
Date: Fri Apr 24 11:27:51 2020
New Revision: 39092

Log:
Apache Cassandra 4.0-alpha4 debian artifacts

Removed:
release/cassandra/debian/dists/40x/


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

[jira] [Commented] (CASSANDRA-15718) Improve BatchMetricsTest

[Stephen Mallette (Jira)]

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

Stephen Mallette commented on CASSANDRA-15718:
--

I've applied that patch so that it is viewable in the branch diff for review. 
Thanks. 

I can squash all those commits to tidy up, when folks are happy with what's 
there. 

> Improve BatchMetricsTest 
> -
>
> Key: CASSANDRA-15718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15718
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
> Attachments: CASSANDRA-15582-test-cleanup.patch
>
>
> As noted in CASSANDRA-15582 {{BatchMetricsTest}} should test 
> {{BatchStatement.Type.COUNTER}} to cover all the {{BatchMetrics}}.  Some 
> changes were introduced to make this improvement at:
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics
> and the following suggestions were made in review (in addition to the 
> suggestion that a separate JIRA be created for this change) by [~dcapwell]:
> {quote}
> * I like the usage of BatchStatement.Type for the tests
> * honestly feel quick theories is better than random, but glad you added the 
> seed to all asserts =). Would still be better as a quick theories test since 
> you basically wrote a property anyways!
> * 
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R131
>  feel you should rename to expectedPartitionsPerLoggedBatch 
> {Count,Logged,Unlogged}
> * . pre is what the value is, post is what the value is expected to be 
> (rather than what it is).
> * 
> * 
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R150
>  this doesn't look correct. the batch has distinctPartitions mutations, so 
> shouldn't max reflect that? I ran the current test in a debugger and see that 
> that is the case (aka current test is wrong).
> most of the comments are nit picks, but the last one looks like a test bug to 
> me
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

svn commit: r39098 - /release/cassandra/4.0-alpha4/debian/dists/

[mck]

Author: mck
Date: Fri Apr 24 12:00:08 2020
New Revision: 39098

Log:
Apache Cassandra 4.0-alpha4 debian artifacts

Removed:
release/cassandra/4.0-alpha4/debian/dists/


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

svn commit: r39099 - /release/cassandra/4.0-alpha4/debian/pool/

[mck]

Author: mck
Date: Fri Apr 24 12:01:38 2020
New Revision: 39099

Log:
Apache Cassandra 4.0-alpha4 debian artifacts

Removed:
release/cassandra/4.0-alpha4/debian/pool/


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

[jira] [Commented] (CASSANDRA-15667) StreamResultFuture check for completeness is inconsistent, leading to races

[Benjamin Lerer (Jira)]

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

Benjamin Lerer commented on CASSANDRA-15667:


Jenkin CI | 
[[4.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/74/]|[3.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/75/]|[3.11|https://ci-cassandra.apache.org/job/Cassandra-devbranch/76/]|

> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0
>
> Attachments: log_bootstrap_resumable
>
>
> {{StreamResultFuture#maybeComplete()}} uses 
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are 
> completed, but then accesses each session state via 
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the 
> former relies on the actual {{StreamSession}} state, while the latter on the 
> {{SessionInfo}} state, and the two are concurrently updated with no 
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as 
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc 
> [~e.dimitrova].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15667) StreamResultFuture check for completeness is inconsistent, leading to races

[Benjamin Lerer (Jira)]

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

Benjamin Lerer edited comment on CASSANDRA-15667 at 4/24/20, 12:07 PM:
---

Jenkin CI 
|[4.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/74/]|[3.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/75/]|[3.11|https://ci-cassandra.apache.org/job/Cassandra-devbranch/76/]|


was (Author: blerer):
Jenkin CI | 
[[4.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/74/]|[3.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/75/]|[3.11|https://ci-cassandra.apache.org/job/Cassandra-devbranch/76/]|

> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0
>
> Attachments: log_bootstrap_resumable
>
>
> {{StreamResultFuture#maybeComplete()}} uses 
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are 
> completed, but then accesses each session state via 
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the 
> former relies on the actual {{StreamSession}} state, while the latter on the 
> {{SessionInfo}} state, and the two are concurrently updated with no 
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as 
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc 
> [~e.dimitrova].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15667) StreamResultFuture check for completeness is inconsistent, leading to races

[Benjamin Lerer (Jira)]

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

Benjamin Lerer edited comment on CASSANDRA-15667 at 4/24/20, 12:08 PM:
---

Jenkins CI runs:
|[4.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/74/]|[3.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/75/]|[3.11|https://ci-cassandra.apache.org/job/Cassandra-devbranch/76/]|


was (Author: blerer):
Jenkin CI 
|[4.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/74/]|[3.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/75/]|[3.11|https://ci-cassandra.apache.org/job/Cassandra-devbranch/76/]|

> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0
>
> Attachments: log_bootstrap_resumable
>
>
> {{StreamResultFuture#maybeComplete()}} uses 
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are 
> completed, but then accesses each session state via 
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the 
> former relies on the actual {{StreamSession}} state, while the latter on the 
> {{SessionInfo}} state, and the two are concurrently updated with no 
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as 
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc 
> [~e.dimitrova].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

svn commit: r39100 - in /release/cassandra: 4.0-alpha3/ debian/pool/main/c/cassandra/cassandra_4.0~alpha3.dsc debian/pool/main/c/cassandra/cassandra_4.0~alpha3.tar.gz debian/pool/main/c/cassandra/cass

[mck]

Author: mck
Date: Fri Apr 24 12:15:51 2020
New Revision: 39100

Log:
Remove old version 4.0~alpha3

Removed:
release/cassandra/4.0-alpha3/
release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0~alpha3.dsc
release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0~alpha3.tar.gz
release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0~alpha3_all.deb


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

[cassandra] branch trunk updated: Increment version to 4.0-alpha5

[mck]

This is an automated email from the ASF dual-hosted git repository.

mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/trunk by this push:
 new b6f1fe6  Increment version to 4.0-alpha5
b6f1fe6 is described below

commit b6f1fe6f9d4be46a2234b07edcbbe144017ae30a
Author: Mick Semb Wever 
AuthorDate: Fri Apr 24 14:28:32 2020 +0200

Increment version to 4.0-alpha5
---
 CHANGES.txt | 10 +-
 build.xml   |  2 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index cfc1f4c..929dd70 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,4 @@
-4.0-alpha4
+4.0-alpha5
  * Avoid race condition when completing stream sessions (CASSANDRA-15666)
  * Flush with fast compressors by default (CASSANDRA-15379)
  * Fix CqlInputFormat regression from the switch to system.size_estimates 
(CASSANDRA-15637)
@@ -14,6 +14,14 @@
  * Do not check cdc_raw_directory filesystem space if CDC disabled 
(CASSANDRA-15688)
  * Replace array iterators with get by index (CASSANDRA-15394)
  * Minimize BTree iterator allocations (CASSANDRA-15389)
+Merged from 3.11:
+Merged from 3.0:
+ * cqlsh return non-zero status when STDIN CQL fails (CASSANDRA-15623)
+ * Don't skip sstables in slice queries based only on local min/max/deletion 
timestamp (CASSANDRA-15690)
+Merged from 2.2:
+ * Duplicate results with DISTINCT queries in mixed mode (CASSANDRA-15501)
+
+4.0-alpha4
  * Add client request size server metrics (CASSANDRA-15704)
  * Add additional logging around FileUtils and compaction leftover cleanup 
(CASSANDRA-15705)
  * Mark system_views/system_virtual_schema as non-alterable keyspaces in cqlsh 
(CASSANDRA-15711)
diff --git a/build.xml b/build.xml
index 5752b2d..318947a 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 https://gitbox.apache.org/repos/asf/cassandra.git"/>
 https://gitbox.apache.org/repos/asf/cassandra.git"/>
 https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/>


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

[jira] [Commented] (CASSANDRA-14242) Indexed static column returns inconsistent results

[Benjamin Lerer (Jira)]

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

Benjamin Lerer commented on CASSANDRA-14242:


The patch looks good to me.

> Indexed static column returns inconsistent results
> --
>
> Key: CASSANDRA-14242
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14242
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/2i Index
> Environment: Cassandra 3.11.2
> Java driver 3.4.0
> Ubuntu - 4.4.0-112-generic
>Reporter: Ross Black
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I am using Cassandra 3.11.2, and the Java driver 3.4.0
> I have a table that has a static column, where the static column has a 
> secondary index.
> When querying the table I get incomplete or duplicated results, depending on 
> the fetch size.
> e.g.
> {code:java}
> CREATE KEYSPACE hack WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> CREATE TABLE hack.stuff (id int, kind text, chunk int static, val1 int, 
> PRIMARY KEY (id, kind));
> CREATE INDEX stuff_chunk_index ON hack.stuff (chunk);{code}
> -- repeat with thousands of values for id =>
> {code:java}
>   INSERT INTO hack.stuff (id, chunk, kind, val1 ) VALUES (${id}, 777, 'A', 
> 123);{code}
> Querying from Java:
> {code:java}
>     final SimpleStatement statement = new SimpleStatement("SELECT id, kind, 
> val1 FROM hack.stuff WHERE chunk = " + chunk); 
>     statement.setFetchSize(fetchSize);
>     statement.setConsistencyLevel(ConsistencyLevel.ALL);
>     final ResultSet resultSet = connection.getSession().execute(statement);
>     for (Row row : resultSet) {
>     final int id = row.getInt("id");
>     }{code}
> *The number of results returned depends on the fetch-size.*
> e.g. For 30k values inserted, I get the following:
> ||fetch-size||result-size||
> |4|3|
> |2|30001|
> |5000|30006|
> |100|30303|
> In production, I have a much larger table where the correct result size for a 
> specific chunk is 20019, but some fetch sizes will return _significantly 
> fewer_ results.
> ||fetch-size||result-size|| ||
> |25000|20019| |
> |5000||*<== this one is has far fewer results*|
> |5001|20026| |
> (so far been unable to reproduce this with the simpler test table)
> Thanks,
> Ross



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-14242) Indexed static column returns inconsistent results

[Benjamin Lerer (Jira)]

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

Benjamin Lerer updated CASSANDRA-14242:
---
Status: Ready to Commit  (was: Review In Progress)

> Indexed static column returns inconsistent results
> --
>
> Key: CASSANDRA-14242
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14242
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/2i Index
> Environment: Cassandra 3.11.2
> Java driver 3.4.0
> Ubuntu - 4.4.0-112-generic
>Reporter: Ross Black
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I am using Cassandra 3.11.2, and the Java driver 3.4.0
> I have a table that has a static column, where the static column has a 
> secondary index.
> When querying the table I get incomplete or duplicated results, depending on 
> the fetch size.
> e.g.
> {code:java}
> CREATE KEYSPACE hack WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> CREATE TABLE hack.stuff (id int, kind text, chunk int static, val1 int, 
> PRIMARY KEY (id, kind));
> CREATE INDEX stuff_chunk_index ON hack.stuff (chunk);{code}
> -- repeat with thousands of values for id =>
> {code:java}
>   INSERT INTO hack.stuff (id, chunk, kind, val1 ) VALUES (${id}, 777, 'A', 
> 123);{code}
> Querying from Java:
> {code:java}
>     final SimpleStatement statement = new SimpleStatement("SELECT id, kind, 
> val1 FROM hack.stuff WHERE chunk = " + chunk); 
>     statement.setFetchSize(fetchSize);
>     statement.setConsistencyLevel(ConsistencyLevel.ALL);
>     final ResultSet resultSet = connection.getSession().execute(statement);
>     for (Row row : resultSet) {
>     final int id = row.getInt("id");
>     }{code}
> *The number of results returned depends on the fetch-size.*
> e.g. For 30k values inserted, I get the following:
> ||fetch-size||result-size||
> |4|3|
> |2|30001|
> |5000|30006|
> |100|30303|
> In production, I have a much larger table where the correct result size for a 
> specific chunk is 20019, but some fetch sizes will return _significantly 
> fewer_ results.
> ||fetch-size||result-size|| ||
> |25000|20019| |
> |5000||*<== this one is has far fewer results*|
> |5001|20026| |
> (so far been unable to reproduce this with the simpler test table)
> Thanks,
> Ross



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15533) Don't allocate unneeded MergeIterator in OnDiskToken#iterator

[Benjamin Lerer (Jira)]

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

Benjamin Lerer updated CASSANDRA-15533:
---
Reviewers: Benjamin Lerer, Berenguer Blasi, Benjamin Lerer  (was: Benjamin 
Lerer, Berenguer Blasi)
   Benjamin Lerer, Berenguer Blasi, Benjamin Lerer  (was: Benjamin 
Lerer, Berenguer Blasi)
   Status: Review In Progress  (was: Patch Available)

> Don't allocate unneeded MergeIterator in OnDiskToken#iterator 
> --
>
> Key: CASSANDRA-15533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15533
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/SASI
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> When reviewing CASSANDRA-15392 it became apparent that the MergeIterator 
> allocated by OnDiskToken#iterator is rarely necessary and so we should avoid 
> allocating one when not needed and skip the MergeIterator pool when needed 
> because its unlikely to be sized correctly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15533) Don't allocate unneeded MergeIterator in OnDiskToken#iterator

[Benjamin Lerer (Jira)]

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

Benjamin Lerer commented on CASSANDRA-15533:


The patch looks good to me.

> Don't allocate unneeded MergeIterator in OnDiskToken#iterator 
> --
>
> Key: CASSANDRA-15533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15533
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/SASI
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> When reviewing CASSANDRA-15392 it became apparent that the MergeIterator 
> allocated by OnDiskToken#iterator is rarely necessary and so we should avoid 
> allocating one when not needed and skip the MergeIterator pool when needed 
> because its unlikely to be sized correctly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15533) Don't allocate unneeded MergeIterator in OnDiskToken#iterator

[Benjamin Lerer (Jira)]

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

Benjamin Lerer edited comment on CASSANDRA-15533 at 4/24/20, 12:48 PM:
---

The patch looks good to me too.


was (Author: blerer):
The patch looks good to me.

> Don't allocate unneeded MergeIterator in OnDiskToken#iterator 
> --
>
> Key: CASSANDRA-15533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15533
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/SASI
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> When reviewing CASSANDRA-15392 it became apparent that the MergeIterator 
> allocated by OnDiskToken#iterator is rarely necessary and so we should avoid 
> allocating one when not needed and skip the MergeIterator pool when needed 
> because its unlikely to be sized correctly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra-in-jvm-dtest-api] branch master updated: Cluster builder should be provided to the factory and expose state

[ifesdjeen]

This is an automated email from the ASF dual-hosted git repository.

ifesdjeen pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git


The following commit(s) were added to refs/heads/master by this push:
 new 326045f  Cluster builder should be provided to the factory and expose 
state
326045f is described below

commit 326045f699791686efa1ecf43b7353397c956494
Author: David Capwell 
AuthorDate: Wed Apr 15 13:30:08 2020 -0700

Cluster builder should be provided to the factory and expose state

Patch by David Capwell, reviewed by Alex Petrov for CASSANDRA-15733.
---
 .../shared/{Builder.java => AbstractBuilder.java}  | 148 +++--
 .../distributed/shared/DistributedTestBase.java|   2 +-
 2 files changed, 80 insertions(+), 70 deletions(-)

diff --git a/src/main/java/org/apache/cassandra/distributed/shared/Builder.java 
b/src/main/java/org/apache/cassandra/distributed/shared/AbstractBuilder.java
similarity index 70%
rename from src/main/java/org/apache/cassandra/distributed/shared/Builder.java
rename to 
src/main/java/org/apache/cassandra/distributed/shared/AbstractBuilder.java
index b3b7db0..cc341a3 100644
--- a/src/main/java/org/apache/cassandra/distributed/shared/Builder.java
+++ b/src/main/java/org/apache/cassandra/distributed/shared/AbstractBuilder.java
@@ -18,35 +18,31 @@
 
 package org.apache.cassandra.distributed.shared;
 
+import org.apache.cassandra.distributed.api.ICluster;
+import org.apache.cassandra.distributed.api.IInstance;
+import org.apache.cassandra.distributed.api.IInstanceConfig;
+import org.apache.cassandra.distributed.api.TokenSupplier;
+
 import java.io.File;
 import java.io.IOException;
 import java.nio.file.Files;
-import java.util.ArrayList;
 import java.util.HashMap;
-import java.util.List;
 import java.util.Map;
+import java.util.Objects;
 import java.util.function.Consumer;
 import java.util.stream.Collectors;
 import java.util.stream.IntStream;
 
-import org.apache.cassandra.distributed.api.ICluster;
-import org.apache.cassandra.distributed.api.IInstance;
-import org.apache.cassandra.distributed.api.IInstanceConfig;
-import org.apache.cassandra.distributed.api.TokenSupplier;
-
 import static 
org.apache.cassandra.distributed.api.TokenSupplier.evenlyDistributedTokens;
 
-public abstract class Builder
+public abstract class AbstractBuilder>
 {
-
-private final int BROADCAST_PORT = 7012;
-
-public interface Factory
+public interface Factory>
 {
-C newCluster(File root, Versions.Version version, 
List configs, ClassLoader sharedClassLoader);
+C newCluster(B builder);
 }
 
-private final Factory factory;
+private final Factory factory;
 private int nodeCount;
 private int subnet;
 private Map nodeIdTopology;
@@ -54,12 +50,50 @@ public abstract class Builder
 private File root;
 private Versions.Version version;
 private Consumer configUpdater;
+private ClassLoader sharedClassLoader = 
Thread.currentThread().getContextClassLoader();
+private int broadcastPort = 7012;
 
-public Builder(Factory factory)
+public AbstractBuilder(Factory factory)
 {
 this.factory = factory;
 }
 
+public int getNodeCount() {
+return nodeCount;
+}
+
+public int getSubnet() {
+return subnet;
+}
+
+public Map getNodeIdTopology() {
+return nodeIdTopology;
+}
+
+public TokenSupplier getTokenSupplier() {
+return tokenSupplier;
+}
+
+public File getRoot() {
+return root;
+}
+
+public Versions.Version getVersion() {
+return version;
+}
+
+public Consumer getConfigUpdater() {
+return configUpdater;
+}
+
+public ClassLoader getSharedClassLoader() {
+return sharedClassLoader;
+}
+
+public int getBroadcastPort() {
+return broadcastPort;
+}
+
 public C start() throws IOException
 {
 C cluster = createWithoutStarting();
@@ -75,79 +109,55 @@ public abstract class Builder
 if (nodeCount <= 0)
 throw new IllegalStateException("Cluster must have at least one 
node");
 
+root.mkdirs();
+
 if (nodeIdTopology == null)
-{
 nodeIdTopology = IntStream.rangeClosed(1, nodeCount).boxed()
   .collect(Collectors.toMap(nodeId -> 
nodeId,
 nodeId -> 
NetworkTopology.dcAndRack(dcName(0), rackName(0;
-}
-
-root.mkdirs();
-
-ClassLoader sharedClassLoader = 
Thread.currentThread().getContextClassLoader();
-
-List configs = new ArrayList<>();
 
 // TODO: make token allocation strategy configurable
 if (tokenSupplier == null)
 tokenSupplier = evenlyDistributedTokens(nodeCount);
 
-for (int i = 0; i < nodeCount; ++i)
-{
-int nodeNum = i + 1;
-

[jira] [Commented] (CASSANDRA-15560) Change io.compressor.LZ4Compressor to LZ4SafeDecompressor

[Berenguer Blasi (Jira)]

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

Berenguer Blasi commented on CASSANDRA-15560:
-

PR available [here|https://github.com/apache/cassandra/pull/547]

> Change io.compressor.LZ4Compressor to LZ4SafeDecompressor
> -
>
> Key: CASSANDRA-15560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15560
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Compression
>Reporter: Jordan West
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> CASSANDRA-15556 and related tickets showed that LZ4FastDecompressor can crash 
> the JVM and that LZ4SafeDecompressor performs better w/o the crash risk — its 
> also not deprecated. While we protect ourselves by checksumming the 
> compressed data but that doesn’t mean we should leave deprecated code that 
> can segfault the jvm (providing a potential DDOS vector among other things) 
> in crucial places like io.compress. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15560) Change io.compressor.LZ4Compressor to LZ4SafeDecompressor

[Berenguer Blasi (Jira)]

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

Berenguer Blasi updated CASSANDRA-15560:

Test and Documentation Plan: CI runs attached to PR
 Status: Patch Available  (was: In Progress)

> Change io.compressor.LZ4Compressor to LZ4SafeDecompressor
> -
>
> Key: CASSANDRA-15560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15560
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Compression
>Reporter: Jordan West
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> CASSANDRA-15556 and related tickets showed that LZ4FastDecompressor can crash 
> the JVM and that LZ4SafeDecompressor performs better w/o the crash risk — its 
> also not deprecated. While we protect ourselves by checksumming the 
> compressed data but that doesn’t mean we should leave deprecated code that 
> can segfault the jvm (providing a potential DDOS vector among other things) 
> in crucial places like io.compress. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-14764) Evaluate 12 Node Breaking Point, compression=none, encryption=none, coalescing=off

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-14764:
-

Hi [~jolynch], [~vinaykumarcse],
Any thoughts on this ticket?

> Evaluate 12 Node Breaking Point, compression=none, encryption=none, 
> coalescing=off
> --
>
> Key: CASSANDRA-14764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14764
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Legacy/Streaming and Messaging
>Reporter: Joey Lynch
>Assignee: Vinay Chella
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: i-03341e1c52de6ea3e-after-queue-change.svg, 
> i-07cd92e844d66d801-after-queue-bound.svg, i-07cd92e844d66d801-hint-play.svg, 
> i-07cd92e844d66d801-uninlined-with-jvm-methods.svg, ttop.txt
>
>
> *Setup:*
>  * Cassandra: 12 (2*6) node i3.xlarge AWS instance (4 cpu cores, 30GB ram) 
> running cassandra trunk off of jasobrown/14503 jdd7ec5a2 (Jasons patched 
> internode messaging branch) vs the same footprint running 3.0.17
>  * Two datacenters with 100ms latency between them
>  * No compression, encryption, or coalescing turned on
> *Test #1:*
> ndbench sent 1.5k QPS at a coordinator level to one datacenter (RF=3*2 = 6 so 
> 3k global replica QPS) of 4kb single partition BATCH mutations at LOCAL_ONE. 
> This represents about 250 QPS per coordinator in the first datacenter or 60 
> QPS per core. The goal was to observe P99 write and read latencies under 
> various QPS.
> *Result:*
> The good news is since the CASSANDRA-14503 changes, instead of keeping the 
> mutations on heap we put the message into hints instead and don't run out of 
> memory. The bad news is that the {{MessagingService-NettyOutbound-Thread's}} 
> would occasionally enter a degraded state where they would just spin on a 
> core. I've attached flame graphs showing the CPU state as [~jasobrown] 
> applied fixes to the {{OutboundMessagingConnection}} class.
>  *Follow Ups:*
> [~jasobrown] has committed a number of fixes onto his 
> {{jasobrown/14503-collab}} branch including:
> 1. Limiting the amount of time spent dequeuing messages if they are expired 
> (previously if messages entered the queue faster than we could dequeue them 
> we'd just inifinte loop on the consumer side)
> 2. Don't call {{dequeueMessages}} from within {{dequeueMessages}} created 
> callbacks.
> We're continuing to use CPU flamegraphs to figure out where we're looping and 
> fixing bugs as we find them.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15733) jvm dtest builder should be provided to the factory and expose state

[Alex Petrov (Jira)]

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

Alex Petrov commented on CASSANDRA-15733:
-

[~dcapwell] committed in-jvm-dtest with 
[326045f699791686efa1ecf43b7353397c956494|https://github.com/apache/cassandra-in-jvm-dtest-api/commit/326045f699791686efa1ecf43b7353397c956494],
 and published a new snapshot {{0.0.2-326045f-SNAPSHOT}}. Please let me know 
when CI has ran so I could commit the rest. Thanks!

> jvm dtest builder should be provided to the factory and expose state
> 
>
> Key: CASSANDRA-15733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15733
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
>  Labels: pull-request-available
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> Currently the builder is rather heavy and creates configs plus call the 
> factory with specific fields only, this isn’t that flexible and makes it 
> harder to have custom cluster definitions which require additional fields to 
> be defined.  To solve this we should make the builder be sent to the factory 
> and expose the state so the factory can get all the fields it needs, the 
> factory should also be in charge of creating the configs



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra-builds] branch master updated: Source and build artifacts are published with sha512 checksums

[mck]

This is an automated email from the ASF dual-hosted git repository.

mck pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git


The following commit(s) were added to refs/heads/master by this push:
 new 0bdc460  Source and build artifacts are published with sha512 checksums
0bdc460 is described below

commit 0bdc460cba741a47abb0634905aa7bcd5310f13a
Author: mck 
AuthorDate: Wed Nov 13 14:36:06 2019 +0100

Source and build artifacts are published with sha512 checksums

The distribution artifacts are no longer deployed to the maven staging 
repository. Instead they are just gpg signed, and prepare_release.sh commits 
them into the asf dev dist location.
Build both the deb/rpm packages and repositories before vote, each in the 
separate debian/ and redhat/ subdirectoroes. Do the bintray upload inside of 
finish_release.sh
Add `dch -r -D unstable` into prepare_relase.sh script (CASSANDRA-15541)

 patch by Mick Semb Wever; reviewed by Michael Shuler for CASSANDRA-14970
---
 cassandra-release/README.md  |   2 +-
 cassandra-release/finish_release.sh  | 165 ---
 cassandra-release/prepare_release.sh | 301 ++-
 cassandra-release/upload_bintray.sh  |  22 ---
 docker/centos7-image.docker  |   4 +-
 5 files changed, 336 insertions(+), 158 deletions(-)

diff --git a/cassandra-release/README.md b/cassandra-release/README.md
index d443cf8..aac043d 100644
--- a/cassandra-release/README.md
+++ b/cassandra-release/README.md
@@ -1,5 +1,5 @@
 Cassandra release scripts
 =
 
-For release managers of cassandra.
+For release managers of cassandra. See 
http://cassandra.apache.org/doc/latest/development/release_process.html
 
diff --git a/cassandra-release/finish_release.sh 
b/cassandra-release/finish_release.sh
index c18bacf..75edfe2 100755
--- a/cassandra-release/finish_release.sh
+++ b/cassandra-release/finish_release.sh
@@ -4,21 +4,24 @@
 
 asf_username="$USER"
 
+# your username to log into bintray (your account needs access to the "apache" 
organisation)
+BINTRAY_USER="$USER"
+# get your bintray API Key from https://bintray.com/profile/edit/apikey
+BINTRAY_KEY=""
+
 # The name of remote for the asf remote in your git repo
 git_asf_remote="origin"
 
-# Same as for .prepare_release.sh
 mail_dir="$HOME/Mail"
-debian_package_dir="$HOME/tmp/debian"
 
-# The directory for reprepro
-reprepro_dir="$debian_package_dir/packages"
-artifacts_svn_dir="$HOME/svn/cassandra-dist"
+###
+# prerequisites
+command -v svn >/dev/null 2>&1 || { echo >&2 "subversion needs to be 
installed"; exit 1; }
+command -v git >/dev/null 2>&1 || { echo >&2 "git needs to be installed"; exit 
1; }
 
 ###
 
 asf_git_repo="https://gitbox.apache.org/repos/asf";
-apache_host="people.apache.org"
 
 # Reset getopts in case it has been used previously in the shell.
 OPTIND=1
@@ -30,14 +33,14 @@ fake_mode=0
 show_help()
 {
 local name=`basename $0`
-echo "$name [options]  "
+echo "$name [options] "
 echo ""
 echo "where [options] are:"
 echo "  -h: print this help"
 echo "  -v: verbose mode (show everything that is going on)"
 echo "  -f: fake mode, print any output but don't do anything (for 
debugging)"
 echo ""
-echo "Example: $name 2.0.3 1024"
+echo "Example: $name 2.0.3"
 }
 
 while getopts ":hvf" opt; do
@@ -61,7 +64,6 @@ done
 shift $(($OPTIND-1))
 
 release=$1
-staging_number=$2
 deb_release=${release/-/\~}
 
 if [ -z "$release" ]
@@ -70,14 +72,8 @@ then
 show_help
 exit 1
 fi
-if [ -z "$staging_number" ]
-then
-echo "Missing argument "
-show_help
-exit 1
-fi
 
-if [ "$#" -gt 2 ]
+if [ "$#" -gt 1 ]
 then
 shift
 echo "Too many arguments. Don't know what to do with '$@'"
@@ -96,9 +92,9 @@ fi
 
 if [ "$release" == "$deb_release" ]
 then
-echo "Publishing release $release using staging number $staging_number"
+echo "Publishing release $release"
 else
-echo "Publishing release $release (debian uses $deb_release) using staging 
number $staging_number"
+echo "Publishing release $release (debian uses $deb_release)"
 fi
 
 # "Saves" stdout to other descriptor since we might redirect them below
@@ -127,29 +123,14 @@ execute()
 fi
 }
 
-idx=`expr index "$release" -`
-if [ $idx -eq 0 ]
-then
-release_short=${release}
-else
-release_short=${release:0:$((idx-1))}
-fi
-release_major=$(echo ${release_short} | cut -d '.' -f 1)
-release_minor=$(echo ${release_short} | cut -d '.' -f 2)
-
 echo "Deploying artifacts ..." 1>&3 2>&4
-start_dir=$PWD
-cd $artifacts_svn_dir
-mkdir $release_short
-cd $release_short
-for type in bin src; do
-for part in gz gz.md5 gz.sha1 gz.asc gz.asc.md5 gz.asc.sha1; do
-echo "Downloading apache-cassandra-${release}-$type.tar.$part..." 1>&3 
2>&4
-curl -O 
https://repository.apache.org/content/repositories/orgapachecassandra-${sta

[jira] [Updated] (CASSANDRA-15541) Add dch release version to debian packages

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-15541:
---
Reviewers: Michael Shuler, Michael Semb Wever  (was: Michael Semb Wever, 
Michael Shuler)
   Michael Shuler, Michael Semb Wever
   Status: Review In Progress  (was: Patch Available)

> Add dch release version to debian packages
> --
>
> Key: CASSANDRA-15541
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15541
> Project: Cassandra
>  Issue Type: Task
>  Components: Packaging
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> Add to the prepare_release.sh script the `dch -r ` step that adds the version.
> Currently the script will generate an UNRELEASED version.
> Reference: 
> https://lists.apache.org/thread.html/r7f8addef88553955b1057a61b29526cb974cc9037f20ce46fb26fb61%40%3Cdev.cassandra.apache.org%3E



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15541) Add dch release version to debian packages

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-15541:
---
Status: Ready to Commit  (was: Review In Progress)

> Add dch release version to debian packages
> --
>
> Key: CASSANDRA-15541
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15541
> Project: Cassandra
>  Issue Type: Task
>  Components: Packaging
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> Add to the prepare_release.sh script the `dch -r ` step that adds the version.
> Currently the script will generate an UNRELEASED version.
> Reference: 
> https://lists.apache.org/thread.html/r7f8addef88553955b1057a61b29526cb974cc9037f20ce46fb26fb61%40%3Cdev.cassandra.apache.org%3E



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15541) Add dch release version to debian packages

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-15541:
---
  Fix Version/s: (was: 3.11.x)
 (was: 4.x)
 (was: 3.0.x)
 (was: 2.2.x)
 4.0-alpha
 3.11.7
 3.0.21
 2.2.17
Source Control Link: 
https://github.com/apache/cassandra-builds/commit/0bdc460cba741a47abb0634905aa7bcd5310f13a
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed as 0bdc460cba741a47abb0634905aa7bcd5310f13a

> Add dch release version to debian packages
> --
>
> Key: CASSANDRA-15541
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15541
> Project: Cassandra
>  Issue Type: Task
>  Components: Packaging
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.2.17, 3.0.21, 3.11.7, 4.0-alpha
>
>
> Add to the prepare_release.sh script the `dch -r ` step that adds the version.
> Currently the script will generate an UNRELEASED version.
> Reference: 
> https://lists.apache.org/thread.html/r7f8addef88553955b1057a61b29526cb974cc9037f20ce46fb26fb61%40%3Cdev.cassandra.apache.org%3E



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra] branch trunk updated: Updated release process documentation after sha checksum and ASF dev dist changes

[mck]

This is an automated email from the ASF dual-hosted git repository.

mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/trunk by this push:
 new 70d8db8  Updated release process documentation after sha checksum and 
ASF dev dist changes
70d8db8 is described below

commit 70d8db8558c346603da6e64c035d325834467d3a
Author: Mick Semb Wever 
AuthorDate: Fri Jan 31 23:41:24 2020 +0100

Updated release process documentation after sha checksum and ASF dev dist 
changes

 patch by Mick Semb Wever; reviewed by Michael Shuler for CASSANDRA-14970
---
 doc/source/development/release_process.rst | 119 +++--
 1 file changed, 61 insertions(+), 58 deletions(-)

diff --git a/doc/source/development/release_process.rst 
b/doc/source/development/release_process.rst
index 8b06e81..fd86238 100644
--- a/doc/source/development/release_process.rst
+++ b/doc/source/development/release_process.rst
@@ -25,16 +25,11 @@ Release Process
 | 
 |
 
-.. attention::
-
-WORK IN PROGRESS
- * A number of these steps still have been finalised/tested.
- * The use of people.apache.org needs to be replaced with svnpubsub and 
dist.apache.org
 
 
 The steps for Release Managers to create, vote and publish releases for Apache 
Cassandra.
 
-While a committer can perform the initial steps of creating and calling a vote 
on a proposed release, only a PMC can complete the process of publishing and 
announcing the release.
+While a committer can perform the initial steps of creating and calling a vote 
on a proposed release, only a PMC member can complete the process of publishing 
and announcing the release.
 
 
 Prerequisites
@@ -53,6 +48,7 @@ Create and publish your GPG key
 ---
 
 To create a GPG key, follow the `guidelines 
`_.
+The key must be 4096 bit RSA.
 Include your public key in::
 
   https://dist.apache.org/repos/dist/release/cassandra/KEYS
@@ -60,43 +56,51 @@ Include your public key in::
 
 Publish your GPG key in a PGP key server, such as `MIT Keyserver 
`_.
 
+Bintray account with access to Apache organisation
+--
+
+Publishing a successfully voted upon release requires bintray access to the 
Apache organisation. Please verify that you have a bintray account and the 
Apache organisation is listed `here 
`_.
+
 
 Create Release Artifacts
 
 
 Any committer can perform the following steps to create and call a vote on a 
proposed release.
 
-Check that there are no open urgent jira tickets currently being worked on. 
Also check with a PMC that there's security vulnerabilities currently being 
worked on in private.'
+Check that there are no open urgent jira tickets currently being worked on. 
Also check with the PMC that there's security vulnerabilities currently being 
worked on in private.'
 Current project habit is to check the timing for a new release on the dev 
mailing lists.
 
 Perform the Release
 ---
 
-Run the following commands to generate and upload release artifacts, to a 
nexus staging repository and distribution location::
+Run the following commands to generate and upload release artifacts, to the 
ASF nexus staging repository and dev distribution location::
 
 
 cd ~/git
 git clone https://github.com/apache/cassandra-builds.git
-# Edit the variables at the top of 
`cassandra-builds/cassandra-release/prepare_release.sh`
+git clone https://github.com/apache/cassandra.git
+
+# Edit the variables at the top of the `prepare_release.sh` file
+edit cassandra-builds/cassandra-release/prepare_release.sh
 
-# After cloning cassandra-builds repo, the prepare_release.sh is run from 
the actual cassandra git checkout, 
+# Ensure your 4096 RSA key is the default secret key
+edit ~/.gnupg/gpg.conf # update the `default-key` line
+edit ~/.rpmmacros # update the `%gpg_name ` line
+
+# Ensure DEBFULLNAME and DEBEMAIL is defined and exported, in the debian 
scripts configuration
+edit ~/.devscripts
+
+# The prepare_release.sh is run from the actual cassandra git checkout,
 # on the branch/commit that we wish to tag for the tentative release along 
with version number to tag.
-# For example here  might be `3.11` and  `3.11.3`
-cd ~/git/cassandra/
-git checkout cassandra-
-../cassandra-builds/cassandra-release/prepare_release.sh -v 
+cd cassandra
+git switch cassandra-
 
-If successful, take note of the email text output which can be used in the 
next section "Call for a Vote".
+# The following cuts the release artifacts (including deb and rpm 
packages) and deploy to staging environments
+../cassandra-builds/cassandra-release/prepare_release.sh -v 
 
-After validating the uploaded artifacts

[jira] [Updated] (CASSANDRA-14970) New releases must supply SHA-256 and/or SHA-512 checksums

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-14970:
---
Status: Ready to Commit  (was: Review In Progress)

> New releases must supply SHA-256 and/or SHA-512 checksums
> -
>
> Key: CASSANDRA-14970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14970
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Michael Shuler
>Assignee: Michael Semb Wever
>Priority: Urgent
> Fix For: 4.0-alpha
>
> Attachments: 
> 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, 
> 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, 
> ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png, 
> cassandra-2.1_14970_updated.patch
>
>
> Release policy was updated around 9/2018 to state:
> "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT 
> supply MD5 or SHA-1. Existing releases do not need to be changed."
> build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. 
> cassandra-builds/cassandra-release scripts need to be updated to work with 
> the new checksum files.
> http://www.apache.org/dev/release-distribution#sigs-and-sums



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-14970) New releases must supply SHA-256 and/or SHA-512 checksums

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-14970:
---
  Fix Version/s: 2.2.16
 3.0.20
 3.11.6
  Since Version: 0.3
Source Control Link: 
https://github.com/apache/cassandra/commit/70d8db8558c346603da6e64c035d325834467d3a
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed as 
[70d8db8558c346603da6e64c035d325834467d3a|https://github.com/apache/cassandra/commit/70d8db8558c346603da6e64c035d325834467d3a]
 and 
[0bdc460cba741a47abb0634905aa7bcd5310f13a|https://github.com/apache/cassandra-builds/commit/0bdc460cba741a47abb0634905aa7bcd5310f13a]

> New releases must supply SHA-256 and/or SHA-512 checksums
> -
>
> Key: CASSANDRA-14970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14970
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Michael Shuler
>Assignee: Michael Semb Wever
>Priority: Urgent
> Fix For: 4.0-alpha, 3.11.6, 3.0.20, 2.2.16
>
> Attachments: 
> 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, 
> 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, 
> ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png, 
> cassandra-2.1_14970_updated.patch
>
>
> Release policy was updated around 9/2018 to state:
> "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT 
> supply MD5 or SHA-1. Existing releases do not need to be changed."
> build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. 
> cassandra-builds/cassandra-release scripts need to be updated to work with 
> the new checksum files.
> http://www.apache.org/dev/release-distribution#sigs-and-sums



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15533) Don't allocate unneeded MergeIterator in OnDiskToken#iterator

[Benjamin Lerer (Jira)]

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

Benjamin Lerer commented on CASSANDRA-15533:


[~jrwest], [~bdeggleston] Sorry, I did not realized that this ticket has a 
dependency on CASSANDRA-15392.

> Don't allocate unneeded MergeIterator in OnDiskToken#iterator 
> --
>
> Key: CASSANDRA-15533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15533
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/SASI
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> When reviewing CASSANDRA-15392 it became apparent that the MergeIterator 
> allocated by OnDiskToken#iterator is rarely necessary and so we should avoid 
> allocating one when not needed and skip the MergeIterator pool when needed 
> because its unlikely to be sized correctly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15533) Don't allocate unneeded MergeIterator in OnDiskToken#iterator

[Benjamin Lerer (Jira)]

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

Benjamin Lerer updated CASSANDRA-15533:
---
Status: Patch Available  (was: Review In Progress)

> Don't allocate unneeded MergeIterator in OnDiskToken#iterator 
> --
>
> Key: CASSANDRA-15533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15533
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/SASI
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> When reviewing CASSANDRA-15392 it became apparent that the MergeIterator 
> allocated by OnDiskToken#iterator is rarely necessary and so we should avoid 
> allocating one when not needed and skip the MergeIterator pool when needed 
> because its unlikely to be sized correctly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-14970) New releases must supply SHA-256 and/or SHA-512 checksums

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-14970:
---
Source Control Link: 
https://github.com/apache/cassandra/commit/70d8db8558c346603da6e64c035d325834467d3a
 
https://github.com/apache/cassandra-builds/commit/0bdc460cba741a47abb0634905aa7bcd5310f13a
  (was: 
https://github.com/apache/cassandra/commit/70d8db8558c346603da6e64c035d325834467d3a)

> New releases must supply SHA-256 and/or SHA-512 checksums
> -
>
> Key: CASSANDRA-14970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14970
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Michael Shuler
>Assignee: Michael Semb Wever
>Priority: Urgent
> Fix For: 2.2.16, 3.0.20, 3.11.6, 4.0-alpha
>
> Attachments: 
> 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, 
> 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, 
> ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png, 
> cassandra-2.1_14970_updated.patch
>
>
> Release policy was updated around 9/2018 to state:
> "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT 
> supply MD5 or SHA-1. Existing releases do not need to be changed."
> build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. 
> cassandra-builds/cassandra-release scripts need to be updated to work with 
> the new checksum files.
> http://www.apache.org/dev/release-distribution#sigs-and-sums



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[cassandra-website] branch asf-staging updated (4fe576a -> cf25a53)

[mck]

This is an automated email from the ASF dual-hosted git repository.

mck pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.


 discard 4fe576a  regenerate website, and test mck/https-always
 discard e2ca189  Always use https
 add af57570  Always use https
 add 030807b  regenerated docs.
 new cf25a53  regenerated docs.

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (4fe576a)
\
 N -- N -- N   refs/heads/asf-staging (cf25a53)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 .../doc/4.0-alpha5}/_images/Figure_1_backups.jpg   |  Bin
 .../4.0-alpha5}/_images/Figure_1_data_model.jpg|  Bin
 .../4.0-alpha5}/_images/Figure_1_guarantees.jpg|  Bin
 .../4.0-alpha5}/_images/Figure_1_read_repair.jpg   |  Bin
 .../4.0-alpha5}/_images/Figure_2_data_model.jpg|  Bin
 .../4.0-alpha5}/_images/Figure_2_read_repair.jpg   |  Bin
 .../4.0-alpha5}/_images/Figure_3_read_repair.jpg   |  Bin
 .../4.0-alpha5}/_images/Figure_4_read_repair.jpg   |  Bin
 .../4.0-alpha5}/_images/Figure_5_read_repair.jpg   |  Bin
 .../4.0-alpha5}/_images/Figure_6_read_repair.jpg   |  Bin
 .../_images/data_modeling_chebotko_logical.png |  Bin
 .../_images/data_modeling_chebotko_physical.png|  Bin
 .../_images/data_modeling_hotel_bucketing.png  |  Bin
 .../_images/data_modeling_hotel_erd.png|  Bin
 .../_images/data_modeling_hotel_logical.png|  Bin
 .../_images/data_modeling_hotel_physical.png   |  Bin
 .../_images/data_modeling_hotel_queries.png|  Bin
 .../_images/data_modeling_hotel_relational.png |  Bin
 .../_images/data_modeling_reservation_logical.png  |  Bin
 .../_images/data_modeling_reservation_physical.png |  Bin
 .../doc/4.0-alpha5}/_images/docs_commit.png|  Bin
 .../doc/4.0-alpha5}/_images/docs_create_branch.png |  Bin
 .../doc/4.0-alpha5}/_images/docs_create_file.png   |  Bin
 .../doc/4.0-alpha5}/_images/docs_editor.png|  Bin
 .../doc/4.0-alpha5}/_images/docs_fork.png  |  Bin
 .../doc/4.0-alpha5}/_images/docs_pr.png|  Bin
 .../doc/4.0-alpha5}/_images/docs_preview.png   |  Bin
 .../doc/4.0-alpha5}/_images/eclipse_debug0.png |  Bin
 .../doc/4.0-alpha5}/_images/eclipse_debug1.png |  Bin
 .../doc/4.0-alpha5}/_images/eclipse_debug2.png |  Bin
 .../doc/4.0-alpha5}/_images/eclipse_debug3.png |  Bin
 .../doc/4.0-alpha5}/_images/eclipse_debug4.png |  Bin
 .../doc/4.0-alpha5}/_images/eclipse_debug5.png |  Bin
 .../doc/4.0-alpha5}/_images/eclipse_debug6.png |  Bin
 .../4.0-alpha5}/_images/example-stress-graph.png   |  Bin
 .../doc/4.0-alpha5}/_images/hints.svg  |0
 .../doc/4.0-alpha5}/_images/ring.svg   |0
 .../doc/4.0-alpha5}/_images/vnodes.svg |0
 .../architecture/dynamo.html   |4 +-
 .../architecture/guarantees.html   |4 +-
 .../{latest => 4.0-alpha5}/architecture/index.html |4 +-
 .../architecture/overview.html |4 +-
 .../architecture/storage_engine.html   |4 +-
 content/doc/{latest => 4.0-alpha5}/bugs.html   |4 +-
 .../configuration/cassandra_config_file.html   |   28 +-
 .../configuration/index.html   |4 +-
 content/doc/{latest => 4.0-alpha5}/contactus.html  |4 +-
 .../doc/{latest => 4.0-alpha5}/cql/appendices.html |4 +-
 .../doc/{latest => 4.0-alpha5}/cql/changes.html|4 +-
 content/doc/{latest => 4.0-alpha5}/cql/ddl.html|6 +-
 .../{latest => 4.0-alpha5}/cql/definitions.html|4 +-
 content/doc/{latest => 4.0-alpha5}/cql/dml.html|4 +-
 .../doc/{latest => 4.0-alpha5}/cql/functions.html  |4 +-
 content/doc/{latest => 4.0-alpha5}/cql/index.html  |4 +-
 .../doc/{latest => 4.0-alpha5}/cql/indexes.html|4 +-
 content/doc/{latest => 4.0-alpha5}/cql/json.html   |4 +-
 content/doc/{latest => 4.0-alpha5}/cql/mvs.html|4 +-
 .../doc/{latest => 4.0-alpha5}/cql/operators.html  |4 +-
 .../doc/{latest => 4.0-alpha5}/cql/security.html   |4 +-
 .../doc/{latest => 4.0-alpha5}/cql/triggers.html   |4 +-
 content/doc/{latest => 4.0-alpha5}/cql/types.html

[jira] [Updated] (CASSANDRA-15718) Improve BatchMetricsTest

[David Capwell (Jira)]

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

David Capwell updated CASSANDRA-15718:
--
Status: Review In Progress  (was: Changes Suggested)

Thanks for all the work, I am +1.

> Improve BatchMetricsTest 
> -
>
> Key: CASSANDRA-15718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15718
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
> Attachments: CASSANDRA-15582-test-cleanup.patch
>
>
> As noted in CASSANDRA-15582 {{BatchMetricsTest}} should test 
> {{BatchStatement.Type.COUNTER}} to cover all the {{BatchMetrics}}.  Some 
> changes were introduced to make this improvement at:
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics
> and the following suggestions were made in review (in addition to the 
> suggestion that a separate JIRA be created for this change) by [~dcapwell]:
> {quote}
> * I like the usage of BatchStatement.Type for the tests
> * honestly feel quick theories is better than random, but glad you added the 
> seed to all asserts =). Would still be better as a quick theories test since 
> you basically wrote a property anyways!
> * 
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R131
>  feel you should rename to expectedPartitionsPerLoggedBatch 
> {Count,Logged,Unlogged}
> * . pre is what the value is, post is what the value is expected to be 
> (rather than what it is).
> * 
> * 
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R150
>  this doesn't look correct. the batch has distinctPartitions mutations, so 
> shouldn't max reflect that? I ran the current test in a debugger and see that 
> that is the case (aka current test is wrong).
> most of the comments are nit picks, but the last one looks like a test bug to 
> me
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15718) Improve BatchMetricsTest

[David Capwell (Jira)]

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

David Capwell edited comment on CASSANDRA-15718 at 4/24/20, 5:04 PM:
-

Thanks for all the hard work! 

I am +1.


was (Author: dcapwell):
Thanks for all the work, I am +1.

> Improve BatchMetricsTest 
> -
>
> Key: CASSANDRA-15718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15718
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
> Attachments: CASSANDRA-15582-test-cleanup.patch
>
>
> As noted in CASSANDRA-15582 {{BatchMetricsTest}} should test 
> {{BatchStatement.Type.COUNTER}} to cover all the {{BatchMetrics}}.  Some 
> changes were introduced to make this improvement at:
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics
> and the following suggestions were made in review (in addition to the 
> suggestion that a separate JIRA be created for this change) by [~dcapwell]:
> {quote}
> * I like the usage of BatchStatement.Type for the tests
> * honestly feel quick theories is better than random, but glad you added the 
> seed to all asserts =). Would still be better as a quick theories test since 
> you basically wrote a property anyways!
> * 
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R131
>  feel you should rename to expectedPartitionsPerLoggedBatch 
> {Count,Logged,Unlogged}
> * . pre is what the value is, post is what the value is expected to be 
> (rather than what it is).
> * 
> * 
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R150
>  this doesn't look correct. the batch has distinctPartitions mutations, so 
> shouldn't max reflect that? I ran the current test in a debugger and see that 
> that is the case (aka current test is wrong).
> most of the comments are nit picks, but the last one looks like a test bug to 
> me
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15262) server_encryption_options is not backwards compatible with 3.11

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-15262 at 4/24/20, 6:29 PM:
---

Based on our conversation with [~jolynch] in Slack, the following scenarios 
should be confirmed as still working in a ~3 node cluster:
- No TLS certificates, default settings -> cluster works
- Add TLS certificates to 2/3 nodes, after restart the cluster is healthy (the 
two with TLS are talking over TLS and the one without TLS is talking plaintext)
- Add TLS cert to 3/3 nodes, switch optional to false -> cluster healthy
- Remove TLS cert from 1/3 nodes, restart -> other nodes should not see this 
node (because TLS is no longer optional) 

I will handle this later today or tomorrow.


was (Author: e.dimitrova):
Based on our conversation in Slack, the following scenarios should be confirmed 
as still working in a ~3 node cluster:
- No TLS certificates, default settings -> cluster works
- Add TLS certificates to 2/3 nodes, after restart the cluster is healthy (the 
two with TLS are talking over TLS and the one without TLS is talking plaintext)
- Add TLS cert to 3/3 nodes, switch optional to false -> cluster healthy
- Remove TLS cert from 1/3 nodes, restart -> other nodes should not see this 
node (because TLS is no longer optional) 

I will handle this later today or tomorrow.

> server_encryption_options is not backwards compatible with 3.11
> ---
>
> Key: CASSANDRA-15262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15262
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> The current `server_encryption_options` configuration options are as follows:
> {noformat}
> server_encryption_options:
> # set to true for allowing secure incoming connections
> enabled: false
> # If enabled and optional are both set to true, encrypted and unencrypted 
> connections are handled on the storage_port
> optional: false
> # if enabled, will open up an encrypted listening socket on 
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false.
> enable_legacy_ssl_storage_port: false
> # on outbound connections, determine which type of peers to securely 
> connect to. 'enabled' must be set to true.
> internode_encryption: none
> keystore: conf/.keystore
> keystore_password: cassandra
> truststore: conf/.truststore
> truststore_password: cassandra
> # More advanced defaults below:
> # protocol: TLS
> # store_type: JKS
> # cipher_suites: 
> [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
> # require_client_auth: false
> # require_endpoint_verification: false
> {noformat}
> A couple of issues here:
> 1. optional defaults to false, which will break existing TLS configurations 
> for (from what I can tell) no particularly good reason
> 2. The provided protocol and cipher suites are not good ideas (in particular 
> encouraging anyone to use CBC ciphers is a bad plan
> I propose that before the 4.0 cut we fixup server_encryption_options and even 
> client_encryption_options :
> # Change the default {{optional}} setting to true. As the new Netty code 
> intelligently decides to open a TLS connection or not this is the more 
> sensible default (saves operators a step while transitioning to TLS as well)
> # Update the defaults to what netty actually defaults to



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15262) server_encryption_options is not backwards compatible with 3.11

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-15262:
-

Based on our conversation in Slack, the following scenarios should be confirmed 
as still working in a ~3 node cluster:
- No TLS certificates, default settings -> cluster works
- Add TLS certificates to 2/3 nodes, after restart the cluster is healthy (the 
two with TLS are talking over TLS and the one without TLS is talking plaintext)
- Add TLS cert to 3/3 nodes, switch optional to false -> cluster healthy
- Remove TLS cert from 1/3 nodes, restart -> other nodes should not see this 
node (because TLS is no longer optional) 

I will handle this later today or tomorrow.

> server_encryption_options is not backwards compatible with 3.11
> ---
>
> Key: CASSANDRA-15262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15262
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> The current `server_encryption_options` configuration options are as follows:
> {noformat}
> server_encryption_options:
> # set to true for allowing secure incoming connections
> enabled: false
> # If enabled and optional are both set to true, encrypted and unencrypted 
> connections are handled on the storage_port
> optional: false
> # if enabled, will open up an encrypted listening socket on 
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false.
> enable_legacy_ssl_storage_port: false
> # on outbound connections, determine which type of peers to securely 
> connect to. 'enabled' must be set to true.
> internode_encryption: none
> keystore: conf/.keystore
> keystore_password: cassandra
> truststore: conf/.truststore
> truststore_password: cassandra
> # More advanced defaults below:
> # protocol: TLS
> # store_type: JKS
> # cipher_suites: 
> [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
> # require_client_auth: false
> # require_endpoint_verification: false
> {noformat}
> A couple of issues here:
> 1. optional defaults to false, which will break existing TLS configurations 
> for (from what I can tell) no particularly good reason
> 2. The provided protocol and cipher suites are not good ideas (in particular 
> encouraging anyone to use CBC ciphers is a bad plan
> I propose that before the 4.0 cut we fixup server_encryption_options and even 
> client_encryption_options :
> # Change the default {{optional}} setting to true. As the new Netty code 
> intelligently decides to open a TLS connection or not this is the more 
> sensible default (saves operators a step while transitioning to TLS as well)
> # Update the defaults to what netty actually defaults to



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15729) Jenkins Test Results Report in plaintext for ASF ML

[Michael Semb Wever (Jira)]

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

Michael Semb Wever commented on CASSANDRA-15729:


This [cassandra 
commit|https://github.com/thelastpickle/cassandra/commit/ed0a7e7e2f3e2a67825b8d560ee9ffbb60983336]
 is ready to be reviewed.

It ensures the in-tree cqlsh-tests have different package names depending on 
the matrix values, so that in any final aggregated test report the tests are 
distinguished. 

> Jenkins Test Results Report in plaintext for ASF ML
> ---
>
> Key: CASSANDRA-15729
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15729
> Project: Cassandra
>  Issue Type: Task
>  Components: Build, CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>  Labels: Jenkins
> Fix For: 4.0-beta
>
>
> The Jenkins pipeline builds now aggregate all test reports.
> For example: 
> - https://ci-cassandra.apache.org/job/Cassandra-trunk/68/testReport/
> - 
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-trunk/detail/Cassandra-trunk/68/tests
> But Jenkins can only keep a limited amount of build history, so those links 
> are not permanent, can't be used as references, and don't help for bisecting 
> and blame on regressions (and flakey tests) over a longer period of time.
> The builds@ ML can provide a permanent record of test results. 
> This was first brought up in these two threads: 
> - 
> https://lists.apache.org/thread.html/re8122e4fdd8629e7fbca2abf27d72054b3bc0e3690ece8b8e66f618b%40%3Cdev.cassandra.apache.org%3E
> - 
> https://lists.apache.org/thread.html/ra5f6aeea89546825fe7ccc4a80898c62f8ed57decabf709d81d9c720%40%3Cdev.cassandra.apache.org%3E
> An example plaintext report, to demonstrate feasibility, is available here: 
> https://lists.apache.org/thread.html/r80d13f7af706bf8dfbf2387fab46004c1fbd3917b7bc339c49e69aa8%40%3Cbuilds.cassandra.apache.org%3E
> Hurdles:
>  - the ASF mailing lists won't accept html, attachments, or any message body 
> over 1MB.
>  - packages are used as a differentiator in the final aggregated report. The 
> cqlsh and dtests currently don't specify it. It needs to be added as a 
> "dot-separated" prefix to the testsuite and testcase name.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Created] (CASSANDRA-15757) CustomIndexTest.indexBuildingPagesLargePartitions is flaky

[Jon Meredith (Jira)]

Jon Meredith created CASSANDRA-15757:


 Summary: CustomIndexTest.indexBuildingPagesLargePartitions is flaky
 Key: CASSANDRA-15757
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15757
 Project: Cassandra
  Issue Type: Bug
  Components: Test/unit
Reporter: Jon Meredith


CustomIndexTest.indexBuildingPagesLargePartitions is flaky. Failed in CI and 
was able to reproduce failure inside IntelliJ by setting test Repeat to ‘Run 
Until Failure’. Failed after 459 iterations.

{code}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.cassandra.index.CustomIndexTest.lambda$indexBuildingPagesLargePartitions$1(CustomIndexTest.java:687)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
at 
org.apache.cassandra.index.CustomIndexTest.indexBuildingPagesLargePartitions(CustomIndexTest.java:687)
at jdk.internal.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at 
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:53)
at 
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15757) CustomIndexTest.indexBuildingPagesLargePartitions is flaky

[Jon Meredith (Jira)]

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

Jon Meredith updated CASSANDRA-15757:
-
 Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear 
Impact(13164)
   Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.0-rc
 Severity: Low
   Status: Open  (was: Triage Needed)

> CustomIndexTest.indexBuildingPagesLargePartitions is flaky
> --
>
> Key: CASSANDRA-15757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15757
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Jon Meredith
>Priority: Normal
> Fix For: 4.0-rc
>
>
> CustomIndexTest.indexBuildingPagesLargePartitions is flaky. Failed in CI and 
> was able to reproduce failure inside IntelliJ by setting test Repeat to ‘Run 
> Until Failure’. Failed after 459 iterations.
> {code}
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> org.apache.cassandra.index.CustomIndexTest.lambda$indexBuildingPagesLargePartitions$1(CustomIndexTest.java:687)
>   at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
>   at 
> org.apache.cassandra.index.CustomIndexTest.indexBuildingPagesLargePartitions(CustomIndexTest.java:687)
>   at jdk.internal.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>   at 
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:53)
>   at 
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
>   at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15718) Improve BatchMetricsTest

[Dinesh Joshi (Jira)]

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

Dinesh Joshi commented on CASSANDRA-15718:
--

Hi [~spmallette], thanks for the contribution. I have kicked off a CI build 
[here|https://circleci.com/workflow-run/cc16d125-eaff-4395-a8b5-79f7c38994d9].

> Improve BatchMetricsTest 
> -
>
> Key: CASSANDRA-15718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15718
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
> Attachments: CASSANDRA-15582-test-cleanup.patch
>
>
> As noted in CASSANDRA-15582 {{BatchMetricsTest}} should test 
> {{BatchStatement.Type.COUNTER}} to cover all the {{BatchMetrics}}.  Some 
> changes were introduced to make this improvement at:
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics
> and the following suggestions were made in review (in addition to the 
> suggestion that a separate JIRA be created for this change) by [~dcapwell]:
> {quote}
> * I like the usage of BatchStatement.Type for the tests
> * honestly feel quick theories is better than random, but glad you added the 
> seed to all asserts =). Would still be better as a quick theories test since 
> you basically wrote a property anyways!
> * 
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R131
>  feel you should rename to expectedPartitionsPerLoggedBatch 
> {Count,Logged,Unlogged}
> * . pre is what the value is, post is what the value is expected to be 
> (rather than what it is).
> * 
> * 
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R150
>  this doesn't look correct. the batch has distinctPartitions mutations, so 
> shouldn't max reflect that? I ran the current test in a debugger and see that 
> that is the case (aka current test is wrong).
> most of the comments are nit picks, but the last one looks like a test bug to 
> me
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (CASSANDRA-15718) Improve BatchMetricsTest

[Dinesh Joshi (Jira)]

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

Dinesh Joshi commented on CASSANDRA-15718:
--

[~spmallette] I have a little feedback which I have mocked up in this 
[branch|https://github.com/apache/cassandra/compare/trunk...dineshjoshi:CASSANDRA-15582-trunk-batchmetrics?expand=1].
 If it looks good, I can squash and commit it.

> Improve BatchMetricsTest 
> -
>
> Key: CASSANDRA-15718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15718
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
> Attachments: CASSANDRA-15582-test-cleanup.patch
>
>
> As noted in CASSANDRA-15582 {{BatchMetricsTest}} should test 
> {{BatchStatement.Type.COUNTER}} to cover all the {{BatchMetrics}}.  Some 
> changes were introduced to make this improvement at:
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics
> and the following suggestions were made in review (in addition to the 
> suggestion that a separate JIRA be created for this change) by [~dcapwell]:
> {quote}
> * I like the usage of BatchStatement.Type for the tests
> * honestly feel quick theories is better than random, but glad you added the 
> seed to all asserts =). Would still be better as a quick theories test since 
> you basically wrote a property anyways!
> * 
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R131
>  feel you should rename to expectedPartitionsPerLoggedBatch 
> {Count,Logged,Unlogged}
> * . pre is what the value is, post is what the value is expected to be 
> (rather than what it is).
> * 
> * 
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R150
>  this doesn't look correct. the batch has distinctPartitions mutations, so 
> shouldn't max reflect that? I ran the current test in a debugger and see that 
> that is the case (aka current test is wrong).
> most of the comments are nit picks, but the last one looks like a test bug to 
> me
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (CASSANDRA-15718) Improve BatchMetricsTest

[Dinesh Joshi (Jira)]

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

Dinesh Joshi updated CASSANDRA-15718:
-
Status: Changes Suggested  (was: Review In Progress)

> Improve BatchMetricsTest 
> -
>
> Key: CASSANDRA-15718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15718
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
> Attachments: CASSANDRA-15582-test-cleanup.patch
>
>
> As noted in CASSANDRA-15582 {{BatchMetricsTest}} should test 
> {{BatchStatement.Type.COUNTER}} to cover all the {{BatchMetrics}}.  Some 
> changes were introduced to make this improvement at:
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics
> and the following suggestions were made in review (in addition to the 
> suggestion that a separate JIRA be created for this change) by [~dcapwell]:
> {quote}
> * I like the usage of BatchStatement.Type for the tests
> * honestly feel quick theories is better than random, but glad you added the 
> seed to all asserts =). Would still be better as a quick theories test since 
> you basically wrote a property anyways!
> * 
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R131
>  feel you should rename to expectedPartitionsPerLoggedBatch 
> {Count,Logged,Unlogged}
> * . pre is what the value is, post is what the value is expected to be 
> (rather than what it is).
> * 
> * 
> https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics#diff-8948cec1f9d33f10b15c38de80141548R150
>  this doesn't look correct. the batch has distinctPartitions mutations, so 
> shouldn't max reflect that? I ran the current test in a debugger and see that 
> that is the case (aka current test is wrong).
> most of the comments are nit picks, but the last one looks like a test bug to 
> me
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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