date:20210510



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

Berenguer Blasi updated CASSANDRA-16661:

  Since Version: 4.0
Source Control Link: 
https://github.com/apache/cassandra/commit/8a6dc6a723778374f6db626fa07d242c6dca59e8
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Fix typo: Alterting -> Altering
> ---
>
> Key: CASSANDRA-16661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16661
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Edward Ribeiro
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 4.1, 4.0-rc
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Fix a typo in the response message when trying to alter a type of an UDT 
> field.



--
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] 01/01: Merge branch 'cassandra-4.0' into trunk

2021-05-10 Thread bereng

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

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

commit 8fb105f26966ba5d9ec1af5cab8e4b1a933c218c
Merge: 8975a4f 8a6dc6a
Author: Bereng 
AuthorDate: Tue May 11 07:05:01 2021 +0200

Merge branch 'cassandra-4.0' into trunk

 .../org/apache/cassandra/cql3/statements/schema/AlterTypeStatement.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

[cassandra] branch trunk updated (8975a4f -> 8fb105f)

2021-05-10 Thread bereng

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

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


from 8975a4f  Merge branch 'cassandra-4.0' into trunk
 new 8a6dc6a  Fix typo
 new 8fb105f  Merge branch 'cassandra-4.0' into trunk

The 2 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:
 .../org/apache/cassandra/cql3/statements/schema/AlterTypeStatement.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

[cassandra] branch cassandra-4.0 updated: Fix typo

2021-05-10 Thread bereng

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

bereng pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/cassandra-4.0 by this push:
 new 8a6dc6a  Fix typo
8a6dc6a is described below

commit 8a6dc6a723778374f6db626fa07d242c6dca59e8
Author: Bereng 
AuthorDate: Mon May 10 12:19:23 2021 +0200

Fix typo

patch by Berenguer Blasi; reviewed by Ekaterina Dimitrova for 
CASSANDRA-16661
---
 .../org/apache/cassandra/cql3/statements/schema/AlterTypeStatement.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/src/java/org/apache/cassandra/cql3/statements/schema/AlterTypeStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/schema/AlterTypeStatement.java
index 9228f34..a9887c4 100644
--- 
a/src/java/org/apache/cassandra/cql3/statements/schema/AlterTypeStatement.java
+++ 
b/src/java/org/apache/cassandra/cql3/statements/schema/AlterTypeStatement.java
@@ -193,7 +193,7 @@ public abstract class AlterTypeStatement extends 
AlterSchemaStatement
 
 UserType apply(KeyspaceMetadata keyspace, UserType userType)
 {
-throw ire("Alterting field types is no longer supported");
+throw ire("Altering field types is no longer supported");
 }
 }
 

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

[jira] [Commented] (CASSANDRA-16658) Broken "help" command on cqlsh 6.0.0



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

Ekaterina Dimitrova commented on CASSANDRA-16658:
-

LGTM

> Broken "help" command on cqlsh 6.0.0
> 
>
> Key: CASSANDRA-16658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16658
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> On cqlsh 5.0.1, "help select" command prints this:
> {noformat}
> cqlsh> help select
> *** No browser to display CQL help. URL for help topic select : 
> https://cassandra.apache.org/doc/cql3/CQL-3.2.html#selectStmt
> {noformat}
> However, on cqlsh 6.0.0, "help select" command prints this:
> {noformat}
> cqlsh> help select
> object of type 'NoneType' has no len()
> {noformat}
> Steps to reproduce:
>  # Create and start a Cassandra 4 docker container
> {noformat}
> ~ $ docker create --name cassandra4 cassandra:4.0
> ~ $ docker start cassandra4{noformat}
>  # Get a shell inside the docker container
> {noformat}
>  docker exec -ti CONTAINER_NAME bash{noformat}
>  # Start a cqlsh and run the "help" command inside it (you have to wait for 
> the Cassandra server starting, I had to run "nodetool enablebinary" too, not 
> sure why)
> {noformat}
> root@b03a20987964:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> help select
> object of type 'NoneType' has no len()
> cqlsh> 
> {noformat}



--
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-16658) Broken "help" command on cqlsh 6.0.0



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

Ekaterina Dimitrova updated CASSANDRA-16658:

Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova  (was: Ekaterina 
Dimitrova)
   Ekaterina Dimitrova, Ekaterina Dimitrova
   Status: Review In Progress  (was: Patch Available)

> Broken "help" command on cqlsh 6.0.0
> 
>
> Key: CASSANDRA-16658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16658
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> On cqlsh 5.0.1, "help select" command prints this:
> {noformat}
> cqlsh> help select
> *** No browser to display CQL help. URL for help topic select : 
> https://cassandra.apache.org/doc/cql3/CQL-3.2.html#selectStmt
> {noformat}
> However, on cqlsh 6.0.0, "help select" command prints this:
> {noformat}
> cqlsh> help select
> object of type 'NoneType' has no len()
> {noformat}
> Steps to reproduce:
>  # Create and start a Cassandra 4 docker container
> {noformat}
> ~ $ docker create --name cassandra4 cassandra:4.0
> ~ $ docker start cassandra4{noformat}
>  # Get a shell inside the docker container
> {noformat}
>  docker exec -ti CONTAINER_NAME bash{noformat}
>  # Start a cqlsh and run the "help" command inside it (you have to wait for 
> the Cassandra server starting, I had to run "nodetool enablebinary" too, not 
> sure why)
> {noformat}
> root@b03a20987964:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> help select
> object of type 'NoneType' has no len()
> cqlsh> 
> {noformat}



--
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-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup



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

Ekaterina Dimitrova commented on CASSANDRA-16644:
-

I fixed the CCM patch 
[here|https://github.com/ekaterinadimitrova2/ccm/commit/60515b59cc59dd4ac500321f6b6b3a8818ed7f88],
 I had a small mistake due to which the TAIL was always empty. Now it is fine, 
you can see where the method stopped reading from the log.

You can see in the latest 
[runs|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/808/workflows/737073ba-0e24-4a1f-9cdb-fffbef041a73/jobs/4568/tests#failed-test-0]
 I submitted with lower timeout, the message we look for is in the log but 
_watch_log_for_ method doesn't find the message; we just reached the timeout 
earlier before reaching the message in the log which we read line by line.

I am +1 on the raised timeout plus updated CCM debug message.

> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure 
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds 
> Missing: ['Starting listening for CQL clients'] not found in system.log: 
> Tail: INFO  [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self =  at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor 
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
>  gen_expected(range(0, 21)),
>  gen_expected(range(6, 31)),
>  gen_expected(range(21, 40))]
> >   self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return old_start(*args, **kwargs)
> ../venv/src/ccm/ccmlib/node.py:901: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> start = 1619481570.0236456, timeout = 90
> msg = "Missing: ['Starting listening for CQL clients'] not found in 
> system.log:\nTail: INFO  [main] 2021-04-26 23:59:22,590 YamlConfigura"
> node = 'node4'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> >   raise TimeoutError.create(start, timeout, msg, node)
> E   ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 
> 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in 
> system.log:
> E   Tail: INFO  [main] 2021-04-26 23:59:22,590 YamlConfigura
> ../venv/src/ccm/ccmlib/node.py:56: TimeoutError
> {noformat}



--
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-16661) Fix typo: Alterting -> Altering



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

Ekaterina Dimitrova updated CASSANDRA-16661:

Status: Ready to Commit  (was: Review In Progress)

> Fix typo: Alterting -> Altering
> ---
>
> Key: CASSANDRA-16661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16661
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Edward Ribeiro
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 4.1, 4.0-rc
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Fix a typo in the response message when trying to alter a type of an UDT 
> field.



--
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-16661) Fix typo: Alterting -> Altering



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

Ekaterina Dimitrova commented on CASSANDRA-16661:
-

Ignore my comment, it was before the morning coffee :) +1, thank you!

> Fix typo: Alterting -> Altering
> ---
>
> Key: CASSANDRA-16661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16661
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Edward Ribeiro
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 4.1, 4.0-rc
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Fix a typo in the response message when trying to alter a type of an UDT 
> field.



--
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-16597) Introduce Maven wrapper to build for Maven-less build environments

2021-05-10 Thread David Capwell (Jira)



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

David Capwell commented on CASSANDRA-16597:
---

[~stefan.miklosovic] tested this out after replacing the maven properties file 
pointing to a proxy; build works just fine for me.

> Introduce Maven wrapper to build for Maven-less build environments
> --
>
> Key: CASSANDRA-16597
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16597
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> With the introduction of CASSANDRA-16391, the build machine needs to have 
> Maven installed locally as it executes "mvn" command in its tasks. This might 
> be avoided by adding Maven wrapper which would download (and cache) such 
> installation so build environment might be completely Maven-less otherwise.



--
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-16663) Request-Based Native Transport Rate-Limiting

2021-05-10 Thread Jeremiah Jordan (Jira)



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

Jeremiah Jordan edited comment on CASSANDRA-16663 at 5/11/21, 12:42 AM:


I can definitely see this being useful. I was just taking to someone today 
doing some fairly small payload write stress testing that was easily able to 
overwhelm a large node because it did not get anywhere near the byte based 
backpressure threshold.


was (Author: jjordan):
I can definitely see this being useful. I was just taking to someone today 
doing some fairly small payload write stress testing was was easily able to 
overwhelm a large node because it did not get anywhere near the byte based 
backpressure threshold.

> Request-Based Native Transport Rate-Limiting
> 
>
> Key: CASSANDRA-16663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16663
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support 
> for a runtime-configurable, per-coordinator limit on the number of bytes 
> allocated for concurrent requests over the native protocol. It supports 
> channel back-pressure by default, and optionally supports throwing 
> OverloadedException if that is requested in the relevant connection’s STARTUP 
> message.
> This can be an effective tool to prevent the coordinator from running out of 
> memory, but it may not correspond to how expensive a queries are or provide a 
> direct conceptual mapping to how users think about request capacity. I 
> propose adding the option of request-based (or perhaps more correctly 
> message-based) back-pressure, coexisting with (and reusing the logic that 
> supports) the current bytes-based back-pressure.
> _We can roll this forward in phases_, where the server’s cost accounting 
> becomes more accurate, we segment limits by operation type/keyspace/etc., and 
> the client/driver reacts more intelligently to (especially non-back-pressure) 
> overload, _but something minimally viable could look like this_:
> 1.) Reuse most of the existing logic in Limits, et al. to support a simple 
> per-coordinator limit only on native transport requests in flight (i.e. where 
> requests have a fixed cost of 1). Under this limit will be CQL reads and 
> writes, but also auth requests, prepare requests, and batches. This is 
> obviously simplistic, and it does not account for the variation in cost 
> between individual queries, but even a fixed cost model should be useful in 
> aggregate.
>  * If the client specifies THROW_ON_OVERLOAD in its STARTUP message at 
> connection time, a breach of the per-node limit will result in an 
> OverloadedException being propagated to the client, and the server will 
> discard the request.
>  * If THROW_ON_OVERLOAD is not specified, the server will stop consuming 
> messages from the channel/socket, which should back-pressure the client, 
> while the message continues to be processed.
> 2.) This limit is infinite by default, and can be enabled via the YAML config 
> or JMX at runtime. (The literal default of -1 corresponding to “no limit” can 
> be used here.)
> 3.) The current value of the limit is available via JMX, and metrics around 
> coordinator operations/second are already available to compare against it.
> 4.) Any interaction with existing byte-based limits will intersect. (i.e. A 
> breach of any limit, bytes or request-based, will actuate back-pressure or 
> OverloadedExceptions.)
> In this first pass, explicitly out of scope would be any work on the 
> client/driver side.
> In terms of validation/testing, our biggest concern with anything that adds 
> overhead on a very hot path is performance. In particular, we want to fully 
> understand how the client and server perform along two axes constituting 4 
> scenarios. Those are a.) whether or not we are breaching the request limit 
> and b.) whether the server is throwing on overload at the behest of the 
> client. Having said that, query execution should dwarf the cost of limit 
> accounting.



--
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-16663) Request-Based Native Transport Rate-Limiting

2021-05-10 Thread Jeremiah Jordan (Jira)



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

Jeremiah Jordan commented on CASSANDRA-16663:
-

I can definitely see this being useful. I was just taking to someone today 
doing some fairly small payload write stress testing was was easily able to 
overwhelm a large node because it did not get anywhere near the byte based 
backpressure threshold.

> Request-Based Native Transport Rate-Limiting
> 
>
> Key: CASSANDRA-16663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16663
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support 
> for a runtime-configurable, per-coordinator limit on the number of bytes 
> allocated for concurrent requests over the native protocol. It supports 
> channel back-pressure by default, and optionally supports throwing 
> OverloadedException if that is requested in the relevant connection’s STARTUP 
> message.
> This can be an effective tool to prevent the coordinator from running out of 
> memory, but it may not correspond to how expensive a queries are or provide a 
> direct conceptual mapping to how users think about request capacity. I 
> propose adding the option of request-based (or perhaps more correctly 
> message-based) back-pressure, coexisting with (and reusing the logic that 
> supports) the current bytes-based back-pressure.
> _We can roll this forward in phases_, where the server’s cost accounting 
> becomes more accurate, we segment limits by operation type/keyspace/etc., and 
> the client/driver reacts more intelligently to (especially non-back-pressure) 
> overload, _but something minimally viable could look like this_:
> 1.) Reuse most of the existing logic in Limits, et al. to support a simple 
> per-coordinator limit only on native transport requests in flight (i.e. where 
> requests have a fixed cost of 1). Under this limit will be CQL reads and 
> writes, but also auth requests, prepare requests, and batches. This is 
> obviously simplistic, and it does not account for the variation in cost 
> between individual queries, but even a fixed cost model should be useful in 
> aggregate.
>  * If the client specifies THROW_ON_OVERLOAD in its STARTUP message at 
> connection time, a breach of the per-node limit will result in an 
> OverloadedException being propagated to the client, and the server will 
> discard the request.
>  * If THROW_ON_OVERLOAD is not specified, the server will stop consuming 
> messages from the channel/socket, which should back-pressure the client, 
> while the message continues to be processed.
> 2.) This limit is infinite by default, and can be enabled via the YAML config 
> or JMX at runtime. (The literal default of -1 corresponding to “no limit” can 
> be used here.)
> 3.) The current value of the limit is available via JMX, and metrics around 
> coordinator operations/second are already available to compare against it.
> 4.) Any interaction with existing byte-based limits will intersect. (i.e. A 
> breach of any limit, bytes or request-based, will actuate back-pressure or 
> OverloadedExceptions.)
> In this first pass, explicitly out of scope would be any work on the 
> client/driver side.
> In terms of validation/testing, our biggest concern with anything that adds 
> overhead on a very hot path is performance. In particular, we want to fully 
> understand how the client and server perform along two axes constituting 4 
> scenarios. Those are a.) whether or not we are breaching the request limit 
> and b.) whether the server is throwing on overload at the behest of the 
> client. Having said that, query execution should dwarf the cost of limit 
> accounting.



--
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-16662) Move CASSANDRA-14559s bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address into a jvm-dtest

2021-05-10 Thread David Capwell (Jira)



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

David Capwell commented on CASSANDRA-16662:
---

[~stefan.miklosovic] all tests are passing and included the python dtest change 
to no longer run the test on trunk; can you review again?

> Move CASSANDRA-14559s 
> bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address
>  into a jvm-dtest
> --
>
> Key: CASSANDRA-16662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16662
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java, Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
>
> In debugging an issue I ended up porting 
> bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address
>  into a jvm-dtest, it would be good to move away from the python dtest in 
> favor of a jvm-dtest



--
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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword



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

Ekaterina Dimitrova edited comment on CASSANDRA-16659 at 5/10/21, 11:34 PM:


I experimented a bit and the behavior Is quite inconsistent. According to 
CASSANDRA-16240, in Ubuntu the newly created table should appear in "" when we 
run _describe tables;_ This is not the case on my Mac.  Not sure whether 
something somewhere has been also changed since that ticket. 

Below is some output to show the current behavior. Seems like all operations 
would work but we should put _reserved_keywords in ""_ when we do _DESCRIBE_ or 
_USE_.

I think that the best would be really this to be fixed on the driver side. 
[~aholmber], do you know by chance if 
[PYTHON-1270|https://datastax-oss.atlassian.net/browse/PYTHON-1270] is planned 
for work soon?

 
{code:java}
cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': '1'};
cqlsh> use config;
Improper use command.
cqlsh> use "config";
cqlsh:config> CREATE TABLE emp(
          ...    emp_id int PRIMARY KEY,
          ...    emp_name text,
          ...    emp_city text,
          ...    emp_sal varint,
          ...    emp_phone varint
          ...    );
cqlsh:config> CREATE TABLE config.emp2(    emp_id int PRIMARY KEY,    emp_name 
text,    emp_city text,    emp_sal varint,    emp_phone varint    );
cqlsh:config> select emp_id from config.emp2;
 emp_id

(0 rows)
cqlsh:config> describe config;
Improper describe command.
cqlsh:config> describe "config";
CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': '1'}  AND durable_writes = true;
CREATE TABLE config.emp (
    emp_id int PRIMARY KEY,
    emp_city text,
    emp_name text,
    emp_phone varint,
    emp_sal varint
) WITH additional_write_policy = '99p'
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND cdc = false
    AND comment = ''
    AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '16', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND default_time_to_live = 0
    AND extensions = {}
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair = 'BLOCKING'
    AND speculative_retry = '99p';
CREATE TABLE config.emp2 (
    emp_id int PRIMARY KEY,
    emp_city text,
    emp_name text,
    emp_phone varint,
    emp_sal varint
) WITH additional_write_policy = '99p'
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND cdc = false
    AND comment = ''
    AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '16', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND default_time_to_live = 0
    AND extensions = {}
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair = 'BLOCKING'
    AND speculative_retry = '99p';
cqlsh:config> drop keyspace config;
cqlsh:config> create keyspace config WITH replication = {'class': 
'SimpleStrategy', 'replication_factor': '1'};
cqlsh:config> drop keyspace "config";
cqlsh:config> create keyspace config WITH replication = {'class': 
'SimpleStrategy', 'replication_factor': '1'};
cqlsh:config> describe keyspaces;
config  system_auth         system_schema  system_views         
system  system_distributed  system_traces  system_virtual_schema
cqlsh:config> CREATE TABLE config.config(    emp_id int PRIMARY KEY,    
emp_name text,    emp_city text,    emp_sal varint,    emp_phone varint    );
cqlsh:config> describe tables;
config
cqlsh:config> CREATE TABLE config.profiles(    emp_id int PRIMARY KEY,    
emp_name text,    emp_city text,    emp_sal varint,    emp_phone varint    );
cqlsh:config> 
cqlsh:config> describe tables;
config  profiles
cqlsh:config> describe keyspaces config  system_auth         system_schema  
system_views          system  system_distributed  system_traces  
system_virtual_schema cqlsh:config> drop keyspace config; cqlsh:config> 
describe keyspaces; system       system_distributed  system_traces  
system_virtual_schema system_auth  system_schema       system_views 
{code}
 

 

 


was (Author: e.dimitrova):
I experimented a bit and the behavior Is quite inconsistent. According to 
CASSANDRA-16240, in Ubuntu the newly created table should appear in "" when we 
run

[jira] [Commented] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword



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

Ekaterina Dimitrova commented on CASSANDRA-16659:
-

I experimented a bit and the behavior Is quite inconsistent. According to 
CASSANDRA-16240, in Ubuntu the newly created table should appear in "" when we 
run _describe tables;_ This is not the case on my Mac.  Not sure whether 
something somewhere has been also changed since that ticket. 

Below is some output to show the current behavior. Seems like all operations 
would work but we should put _reserved_keywords in ""_ when we do describe or 
use.

I think that the best would be really to be fixed on the driver side. 
[~aholmber], do you know by chance if 
[PYTHON-1270|https://datastax-oss.atlassian.net/browse/PYTHON-1270] is planned 
for work soon?

 

 
{code:java}
cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': '1'};
cqlsh> use config;
Improper use command.
cqlsh> use "config";
cqlsh:config> CREATE TABLE emp(
          ...    emp_id int PRIMARY KEY,
          ...    emp_name text,
          ...    emp_city text,
          ...    emp_sal varint,
          ...    emp_phone varint
          ...    );
cqlsh:config> CREATE TABLE config.emp2(    emp_id int PRIMARY KEY,    emp_name 
text,    emp_city text,    emp_sal varint,    emp_phone varint    );
cqlsh:config> select emp_id from config.emp2;
 emp_id

(0 rows)
cqlsh:config> describe config;
Improper describe command.
cqlsh:config> describe "config";
CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': '1'}  AND durable_writes = true;
CREATE TABLE config.emp (
    emp_id int PRIMARY KEY,
    emp_city text,
    emp_name text,
    emp_phone varint,
    emp_sal varint
) WITH additional_write_policy = '99p'
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND cdc = false
    AND comment = ''
    AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '16', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND default_time_to_live = 0
    AND extensions = {}
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair = 'BLOCKING'
    AND speculative_retry = '99p';
CREATE TABLE config.emp2 (
    emp_id int PRIMARY KEY,
    emp_city text,
    emp_name text,
    emp_phone varint,
    emp_sal varint
) WITH additional_write_policy = '99p'
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND cdc = false
    AND comment = ''
    AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '16', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND default_time_to_live = 0
    AND extensions = {}
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair = 'BLOCKING'
    AND speculative_retry = '99p';
cqlsh:config> drop keyspace config;
cqlsh:config> create keyspace config WITH replication = {'class': 
'SimpleStrategy', 'replication_factor': '1'};
cqlsh:config> drop keyspace "config";
cqlsh:config> create keyspace config WITH replication = {'class': 
'SimpleStrategy', 'replication_factor': '1'};
cqlsh:config> describe keyspaces;
config  system_auth         system_schema  system_views         
system  system_distributed  system_traces  system_virtual_schema
cqlsh:config> CREATE TABLE config.config(    emp_id int PRIMARY KEY,    
emp_name text,    emp_city text,    emp_sal varint,    emp_phone varint    );
cqlsh:config> describe tables;
config
cqlsh:config> CREATE TABLE config.profiles(    emp_id int PRIMARY KEY,    
emp_name text,    emp_city text,    emp_sal varint,    emp_phone varint    );
cqlsh:config> 
cqlsh:config> describe tables;
config  profiles
cqlsh:config> describe keyspaces config  system_auth         system_schema  
system_views          system  system_distributed  system_traces  
system_virtual_schema cqlsh:config> drop keyspace config; cqlsh:config> 
describe keyspaces; system       system_distributed  system_traces  
system_virtual_schema system_auth  system_schema       system_views 
{code}
 

 

 

> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project:

[jira] [Updated] (CASSANDRA-16664) Log JVM Arguments at in-JVM Test Class Initialization



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

Caleb Rackliffe updated CASSANDRA-16664:

Description: Normal C* startup flows through {{CassandraDaemon.setup()}}, 
which calls {{logSystemInfo()}}, logging JVM arguments and a number of other 
useful bits of information. The in-JVM dtest startup does not flow through 
{{CassandraDaemon.setup()}}, and therefore does not. It would be useful for 
troubleshooting purposes if {{TestBaseImpl}} logged the JVM arguments before 
moving into executing tests.  (was: Normal C* startup flows through 
`CassandraDaemon.setup()`, which calls `logSystemInfo()`, logging JVM arguments 
and a number of other useful bits of information. The in-JVM dtest startup does 
not flow through `CassandraDaemon.setup()`, and therefore does not. It would be 
useful for troubleshooting purposes if `TestBaseImpl` logged the JVM arguments 
before moving into executing tests.)

> Log JVM Arguments at in-JVM Test Class Initialization
> -
>
> Key: CASSANDRA-16664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16664
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Normal C* startup flows through {{CassandraDaemon.setup()}}, which calls 
> {{logSystemInfo()}}, logging JVM arguments and a number of other useful bits 
> of information. The in-JVM dtest startup does not flow through 
> {{CassandraDaemon.setup()}}, and therefore does not. It would be useful for 
> troubleshooting purposes if {{TestBaseImpl}} logged the JVM arguments before 
> moving into executing tests.



--
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] [Assigned] (CASSANDRA-16664) Log JVM Arguments at in-JVM Test Class Initialization



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

Caleb Rackliffe reassigned CASSANDRA-16664:
---

Assignee: (was: Caleb Rackliffe)

> Log JVM Arguments at in-JVM Test Class Initialization
> -
>
> Key: CASSANDRA-16664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16664
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Normal C* startup flows through {{CassandraDaemon.setup()}}, which calls 
> {{logSystemInfo()}}, logging JVM arguments and a number of other useful bits 
> of information. The in-JVM dtest startup does not flow through 
> {{CassandraDaemon.setup()}}, and therefore does not. It would be useful for 
> troubleshooting purposes if {{TestBaseImpl}} logged the JVM arguments before 
> moving into executing tests.



--
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] [Assigned] (CASSANDRA-16664) Log JVM Arguments at in-JVM Test Class Initialization



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

Caleb Rackliffe reassigned CASSANDRA-16664:
---

Assignee: Caleb Rackliffe

> Log JVM Arguments at in-JVM Test Class Initialization
> -
>
> Key: CASSANDRA-16664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16664
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Normal C* startup flows through {{CassandraDaemon.setup()}}, which calls 
> {{logSystemInfo()}}, logging JVM arguments and a number of other useful bits 
> of information. The in-JVM dtest startup does not flow through 
> {{CassandraDaemon.setup()}}, and therefore does not. It would be useful for 
> troubleshooting purposes if {{TestBaseImpl}} logged the JVM arguments before 
> moving into executing tests.



--
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-16664) Log JVM Arguments at in-JVM Test Class Initialization

Caleb Rackliffe created CASSANDRA-16664:
---

 Summary: Log JVM Arguments at in-JVM Test Class Initialization
 Key: CASSANDRA-16664
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16664
 Project: Cassandra
  Issue Type: Improvement
  Components: Test/dtest/java
Reporter: Caleb Rackliffe


Normal C* startup flows through `CassandraDaemon.setup()`, which calls 
`logSystemInfo()`, logging JVM arguments and a number of other useful bits of 
information. The in-JVM dtest startup does not flow through 
`CassandraDaemon.setup()`, and therefore does not. It would be useful for 
troubleshooting purposes if `TestBaseImpl` logged the JVM arguments before 
moving into executing tests.



--
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-16664) Log JVM Arguments at in-JVM Test Class Initialization



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

Caleb Rackliffe updated CASSANDRA-16664:

Change Category: Operability
 Complexity: Low Hanging Fruit
  Fix Version/s: 4.x
 4.0.x
 Status: Open  (was: Triage Needed)

> Log JVM Arguments at in-JVM Test Class Initialization
> -
>
> Key: CASSANDRA-16664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16664
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Normal C* startup flows through `CassandraDaemon.setup()`, which calls 
> `logSystemInfo()`, logging JVM arguments and a number of other useful bits of 
> information. The in-JVM dtest startup does not flow through 
> `CassandraDaemon.setup()`, and therefore does not. It would be useful for 
> troubleshooting purposes if `TestBaseImpl` logged the JVM arguments before 
> moving into executing tests.



--
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-16663) Request-Based Native Transport Rate-Limiting

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

Caleb Rackliffe updated CASSANDRA-16663:

Description:
Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support
for a runtime-configurable, per-coordinator limit on the number of bytes
allocated for concurrent requests over the native protocol. It supports channel
back-pressure by default, and optionally supports throwing OverloadedException
if that is requested in the relevant connection’s STARTUP message.

This can be an effective tool to prevent the coordinator from running out of
memory, but it may not correspond to how expensive a queries are or provide a
direct conceptual mapping to how users think about request capacity. I propose
adding the option of request-based (or perhaps more correctly message-based)
back-pressure, coexisting with (and reusing the logic that supports) the
current bytes-based back-pressure.

_We can roll this forward in phases_, where the server’s cost accounting
becomes more accurate, we segment limits by operation type/keyspace/etc., and
the client/driver reacts more intelligently to (especially non-back-pressure)
overload, but something minimally viable could look like this:

1.) Reuse most of the existing logic in Limits, et al. to support a simple
per-coordinator limit only on native transport requests in flight (i.e. where
requests have a fixed cost of 1). Under this limit will be CQL reads and
writes, but also auth requests, prepare requests, and batches. This is
obviously simplistic, and it does not account for the variation in cost between
individual queries, but even a fixed cost model should be useful in aggregate.
* If the client specifies THROW_ON_OVERLOAD in its STARTUP message at
connection time, a breach of the per-node limit will result in an
OverloadedException being propagated to the client, and the server will discard
the request.
* If THROW_ON_OVERLOAD is not specified, the server will stop consuming
messages from the channel/socket, which should back-pressure the client, while
the message continues to be processed.

2.) This limit is infinite by default, and can be enabled via the YAML config
or JMX at runtime. (The literal default of -1 corresponding to “no limit” can
be used here.)

3.) The current value of the limit is available via JMX, and metrics around
coordinator operations/second are already available to compare against it.

4.) Any interaction with existing byte-based limits will intersect. (i.e. A
breach of any limit, bytes or request-based, will actuate back-pressure or
OverloadedExceptions.)

In this first pass, explicitly out of scope would be any work on the
client/driver side.

In terms of validation/testing, our biggest concern with anything that adds
overhead on a very hot path is performance. In particular, we want to fully
understand how the client and server perform along two axes constituting 4
scenarios. Those are a.) whether or not we are breaching the request limit and
b.) whether the server is throwing on overload at the behest of the client.
Having said that, query execution should dwarf the cost of limit accounting.

was:
Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support
for a runtime-configurable, per-coordinator limit on the number of bytes
allocated for concurrent requests over the native protocol. It supports channel
back-pressure by default, and optionally supports throwing OverloadedException
if that is requested in the relevant connection’s STARTUP message.

We can roll this forward in phases, where the server’s cost accounting becomes
more accurate, and the client/driver reacts more intelligently to (especially
non-back-pressure) overload, but something minimally viable could look like
this:

[jira] [Updated] (CASSANDRA-16663) Request-Based Native Transport Rate-Limiting

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

Caleb Rackliffe updated CASSANDRA-16663:

_We can roll this forward in phases_, where the server’s cost accounting
becomes more accurate, we segment limits by operation type/keyspace/etc., and
the client/driver reacts more intelligently to (especially non-back-pressure)
overload, _but something minimally viable could look like this_:

2.) This limit is infinite by default, and can be enabled via the YAML config
or JMX at runtime. (The literal default of -1 corresponding to “no limit” can
be used here.)

3.) The current value of the limit is available via JMX, and metrics around
coordinator operations/second are already available to compare against it.

4.) Any interaction with existing byte-based limits will intersect. (i.e. A
breach of any limit, bytes or request-based, will actuate back-pressure or
OverloadedExceptions.)

In this first pass, explicitly out of scope would be any work on the
client/driver side.

[jira] [Updated] (CASSANDRA-16663) Request-Based Native Transport Rate-Limiting

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

Caleb Rackliffe updated CASSANDRA-16663:

2.) This limit is infinite by default, and can be enabled via the YAML config
or JMX at runtime. (The literal default of -1 corresponding to “no limit” can
be used here.)

3.) The current value of the limit is available via JMX, and metrics around
coordinator operations/second are already available to compare against it.

4.) Any interaction with existing byte-based limits will intersect. (i.e. A
breach of any limit, bytes or request-based, will actuate back-pressure or
OverloadedExceptions.)

In this first pass, explicitly out of scope would be any work on the
client/driver side.

1.) Reuse most of the existing logic in Limits, et al. to support a simple
per-coordinator limit only on native transport requests in flight (i.e. where
requests have a fixed cost of 1). Under this limit will be CQL reads and
writes, but also auth requests, prepare requests, and batches.
* If the client specifies THROW_ON_OVERLOAD in its STARTUP message at
connection time, a breach of the per-node limit will result in an
OverloadedException being propagated to the client, and the server will discard
the request.
* If THROW_ON_OVERLOAD is not specified, the server will stop consuming
messages from the channel/socket, which should back-pressure the client, while
the message continues to be

[jira] [Updated] (CASSANDRA-16663) Request-Based Native Transport Rate-Limiting

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

Caleb Rackliffe updated CASSANDRA-16663:

1.) Reuse most of the existing logic in Limits, et al. to support a simple
per-coordinator limit only on native transport requests in flight (i.e. where
requests have a fixed cost of 1). Under this limit will be CQL reads and
writes, but also auth requests, prepare requests, and batches.
* If the client specifies THROW_ON_OVERLOAD in its STARTUP message at
connection time, a breach of the per-node limit will result in an
OverloadedException being propagated to the client, and the server will discard
the request.
* If THROW_ON_OVERLOAD is not specified, the server will stop consuming
messages from the channel/socket, which should back-pressure the client, while
the message continues to be processed.

2.) This limit is infinite by default, and can be enabled via the YAML config
or JMX at runtime. (The literal default of -1 corresponding to “no limit” can
be used here.)

3.) The current value of the limit is available via JMX, and metrics around
coordinator operations/second are already available to compare against it.

4.) Any interaction with existing byte-based limits will intersect. (i.e. A
breach of any limit, bytes or request-based, will actuate back-pressure or
OverloadedExceptions.)

In this first pass, explicitly out of scope would be any work on the
client/driver side.

This can be an effective tool to prevent the coordinator from running out of
memory, but it may not correspond to how expensive a query is or provide a
direct conceptual mapping to how users think about request capacity. I propose
adding the option of request-based (or perhaps more correctly message-based)
back-pressure, coexisting with (and reusing the logic that supports) the
current bytes-based back-pressure.

1.) Reuse most of the existing logic in Limits, et al. to support a simple
per-coordinator limit only on native transport requests in flight (i.e. where
requests have a fixed cost of 1). Under this limit will be CQL reads and
writes, but also auth requests, prepare requests, and batches.
* If the client specifies THROW_ON_OVERLOAD in its STARTUP message at
connection time, a breach of the per-node limit will result in an
OverloadedException being propagated to the client, and the server will discard
the request.
* If THROW_ON_OVERLOAD is not specified, the server will stop consuming
messages from the channel/socket, which should back-pressure the client, while
the message continues to be processed.

2.) This limit is infinite by default, and can be enabled via the YAML config
or JMX at runtime. (The literal default of -1 corresponding to “no limit” can
be

[jira] [Updated] (CASSANDRA-16663) Request-Based Native Transport Rate-Limiting



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

Caleb Rackliffe updated CASSANDRA-16663:

Change Category: Operability
 Complexity: Normal
  Fix Version/s: 4.x
 4.0.x
 Status: Open  (was: Triage Needed)

> Request-Based Native Transport Rate-Limiting
> 
>
> Key: CASSANDRA-16663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16663
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support 
> for a runtime-configurable, per-coordinator limit on the number of bytes 
> allocated for concurrent requests over the native protocol. It supports 
> channel back-pressure by default, and optionally supports throwing 
> OverloadedException if that is requested in the relevant connection’s STARTUP 
> message.
> This can be an effective tool to prevent the coordinator from running out of 
> memory, but it may not correspond to how expensive a query is or provide a 
> direct conceptual mapping to how users think about request capacity. I 
> propose adding the option of request-based (or perhaps more correctly 
> message-based) back-pressure, coexisting with (and reusing the logic that 
> supports) the current bytes-based back-pressure.
> We can roll this forward in phases, where the server’s cost accounting 
> becomes more accurate, and the client/driver reacts more intelligently to 
> (especially non-back-pressure) overload, but something minimally viable could 
> look like this:
> 1.) Reuse most of the existing logic in Limits, et al. to support a simple 
> per-coordinator limit only on native transport requests in flight (i.e. where 
> requests have a fixed cost of 1). Under this limit will be CQL reads and 
> writes, but also auth requests, prepare requests, and batches.
>  * If the client specifies THROW_ON_OVERLOAD in its STARTUP message at 
> connection time, a breach of the per-node limit will result in an 
> OverloadedException being propagated to the client, and the server will 
> discard the request.
>  * If THROW_ON_OVERLOAD is not specified, the server will stop consuming 
> messages from the channel/socket, which should back-pressure the client, 
> while the message continues to be processed.
> 2.) This limit is infinite by default, and can be enabled via the YAML config 
> or JMX at runtime. (The literal default of -1 corresponding to “no limit” can 
> be used here.)
> 3.) The current value of the limit is available via JMX, and metrics around 
> coordinator operations/second are already available to compare against it.
> 4.) Any interaction with existing byte-based limits will intersect. (i.e. A 
> breach of any limit, bytes or request-based, will actuate back-pressure or 
> OverloadedExceptions.)
> In this first pass, explicitly out of scope would be any work on the 
> client/driver side.
> In terms of validation/testing, our biggest concern with anything that adds 
> overhead on a very hot path is performance. In particular, we want to fully 
> understand how the client and server perform along two axes constituting 4 
> scenarios. Those are a.) whether or not we are breaching the request limit 
> and b.) whether the server is throwing on overload at the behest of the 
> client. Having said that, query execution should dwarf the cost of limit 
> accounting.



--
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-16663) Request-Based Native Transport Rate-Limiting

Caleb Rackliffe created CASSANDRA-16663:
---

 Summary: Request-Based Native Transport Rate-Limiting
 Key: CASSANDRA-16663
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16663
 Project: Cassandra
  Issue Type: Improvement
  Components: Messaging/Client
Reporter: Caleb Rackliffe
Assignee: Caleb Rackliffe


Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support 
for a runtime-configurable, per-coordinator limit on the number of bytes 
allocated for concurrent requests over the native protocol. It supports channel 
back-pressure by default, and optionally supports throwing OverloadedException 
if that is requested in the relevant connection’s STARTUP message.

This can be an effective tool to prevent the coordinator from running out of 
memory, but it may not correspond to how expensive a query is or provide a 
direct conceptual mapping to how users think about request capacity. I propose 
adding the option of request-based (or perhaps more correctly message-based) 
back-pressure, coexisting with (and reusing the logic that supports) the 
current bytes-based back-pressure.

We can roll this forward in phases, where the server’s cost accounting becomes 
more accurate, and the client/driver reacts more intelligently to (especially 
non-back-pressure) overload, but something minimally viable could look like 
this:

1.) Reuse most of the existing logic in Limits, et al. to support a simple 
per-coordinator limit only on native transport requests in flight (i.e. where 
requests have a fixed cost of 1). Under this limit will be CQL reads and 
writes, but also auth requests, prepare requests, and batches.
 * If the client specifies THROW_ON_OVERLOAD in its STARTUP message at 
connection time, a breach of the per-node limit will result in an 
OverloadedException being propagated to the client, and the server will discard 
the request.
 * If THROW_ON_OVERLOAD is not specified, the server will stop consuming 
messages from the channel/socket, which should back-pressure the client, while 
the message continues to be processed.

2.) This limit is infinite by default, and can be enabled via the YAML config 
or JMX at runtime. (The literal default of -1 corresponding to “no limit” can 
be used here.)

3.) The current value of the limit is available via JMX, and metrics around 
coordinator operations/second are already available to compare against it.

4.) Any interaction with existing byte-based limits will intersect. (i.e. A 
breach of any limit, bytes or request-based, will actuate back-pressure or 
OverloadedExceptions.)

In this first pass, explicitly out of scope would be any work on the 
client/driver side.

In terms of validation/testing, our biggest concern with anything that adds 
overhead on a very hot path is performance. In particular, we want to fully 
understand how the client and server perform along two axes constituting 4 
scenarios. Those are a.) whether or not we are breaching the request limit and 
b.) whether the server is throwing on overload at the behest of the client. 
Having said that, query execution should dwarf the cost of limit accounting.



--
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-16092) Add Index Group Interface for Storage Attached Index



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

Caleb Rackliffe updated CASSANDRA-16092:

Status: Review In Progress  (was: Patch Available)

> Add Index Group Interface for Storage Attached Index
> 
>
> Key: CASSANDRA-16092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16092
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Feature/SASI
>Reporter: Zhao Yang
>Assignee: Zhao Yang
>Priority: Normal
> Fix For: 4.x
>
>
> [Index 
> group|https://github.com/datastax/cassandra/blob/storage_attached_index/src/java/org/apache/cassandra/index/Index.java#L634]
>  interface allows:
> * indexes on the same table to receive centralized lifecycle events called 
> secondary index groups. Sharing of data between multiple column indexes on 
> the same table allows SAI disk usage to realise significant space savings 
> over other index implementations.
> * index-group to analyze user query and provide a query plan that leverages 
> all available indexes within the group.



--
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-16662) Move CASSANDRA-14559s bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address into a jvm-dtest

2021-05-10 Thread David Capwell (Jira)



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

David Capwell commented on CASSANDRA-16662:
---

bq. my build failed on Rat because you havent put the license on top of the 
test class.

my template never adds it!!! will fix!

bq. Do you think it makes sense to spend some time on trying to "fix" 
NetworkTopologyStrategy 

I do, but would prefer to put that into a different ticket as it requires a API 
change then rollout to all 5 branches.  [~ifesdjeen] ill file a ticket and try 
to talk to you to make sure we are on the same page with those changes.

> Move CASSANDRA-14559s 
> bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address
>  into a jvm-dtest
> --
>
> Key: CASSANDRA-16662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16662
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java, Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
>
> In debugging an issue I ended up porting 
> bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address
>  into a jvm-dtest, it would be good to move away from the python dtest in 
> favor of a jvm-dtest



--
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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword



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

Ekaterina Dimitrova edited comment on CASSANDRA-16659 at 5/10/21, 7:59 PM:
---

:D Figured it out 3 minutes ago.

Thanks [~aholmber], I will check the tickets you pointed to


was (Author: e.dimitrova):
:D Figured it out 3 minutes ago. 

> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information 
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
>  from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not 
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh:config> 
> {noformat}
> For reference:
>  * Non-reserved keywords, such as "all", don't have the above problem. They 
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh:all> 
> {noformat}
>  * Reserved keywords, such as "add", can be used as keyspace name but 
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create 
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be 
> used in the "create keyspace" statement without quoting, but requires quoting 
> in the "use" and "desc" statements.
>  
>  I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when 
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> 
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh:config> 
> {noformat}



--
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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword



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

Ekaterina Dimitrova commented on CASSANDRA-16659:
-

:D Figured it out 3 minutes ago. 

> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information 
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
>  from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not 
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh:config> 
> {noformat}
> For reference:
>  * Non-reserved keywords, such as "all", don't have the above problem. They 
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh:all> 
> {noformat}
>  * Reserved keywords, such as "add", can be used as keyspace name but 
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create 
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be 
> used in the "create keyspace" statement without quoting, but requires quoting 
> in the "use" and "desc" statements.
>  
>  I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when 
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> 
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh:config> 
> {noformat}



--
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-16400) cqlsh cannot DESC TYPE with non-ascii character in the identifier

2021-05-10 Thread Adam Holmberg (Jira)



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

Adam Holmberg commented on CASSANDRA-16400:
---

Previous CI run failed, apparently on a transient error in the build script. 
Ekaterina started another one 
[here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/761/].

> cqlsh cannot DESC TYPE with non-ascii character in the identifier
> -
>
> Key: CASSANDRA-16400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16400
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/cqlsh
>Reporter: Adam Holmberg
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> cqlsh fails to describe types with non-ascii characters. This is specific to 
> Python 2 and does not occur in Python 3 (only tested on trunk so far).
> {code}
> CREATE TYPE ks."ࠑ " (
> v int
> );
> {code}
> {noformat}
> aholmberg-rmbp16:cassandra adamholmberg$ pyenv shell 2.7.17
> aholmberg-rmbp16:cassandra adamholmberg$ bin/cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 4.0-beta4-SNAPSHOT | CQL spec 3.4.5 | Native 
> protocol v4]
> Use HELP for help.
> cqlsh> desc types;
> Traceback (most recent call last):
>   File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1391, in 
> do_describe
> self.describe_list(result)
>   File "/Users/adamholmberg/code/cassandra/bin/cqlsh.py", line 1438, in 
> describe_list
> names.append(str(row['name']))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u0811' in 
> position 1: ordinal not in range(128)
> {noformat}
> 3.11 appears to handle everything properly.



--
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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword

2021-05-10 Thread Adam Holmberg (Jira)



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

Adam Holmberg commented on CASSANDRA-16659:
---

I think this is because of the updated driver:
https://datastax-oss.atlassian.net/browse/PYTHON-1270
https://issues.apache.org/jira/browse/CASSANDRA-16240
https://github.com/datastax/python-driver/blob/master/cassandra/metadata.py#L62-L68

> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information 
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
>  from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not 
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh:config> 
> {noformat}
> For reference:
>  * Non-reserved keywords, such as "all", don't have the above problem. They 
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh:all> 
> {noformat}
>  * Reserved keywords, such as "add", can be used as keyspace name but 
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create 
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be 
> used in the "create keyspace" statement without quoting, but requires quoting 
> in the "use" and "desc" statements.
>  
>  I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when 
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> 
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh:config> 
> {noformat}



--
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-16658) Broken "help" command on cqlsh 6.0.0

2021-05-10 Thread Adam Holmberg (Jira)



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

Adam Holmberg updated CASSANDRA-16658:
--
Test and Documentation Plan: Tested manually with CQLSH_PYTHON set in 
Python 2.7, 3.6, 3.8
 Status: Patch Available  (was: In Progress)

[patch|https://github.com/aholmberg/cassandra/pull/60]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16658]

> Broken "help" command on cqlsh 6.0.0
> 
>
> Key: CASSANDRA-16658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16658
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> On cqlsh 5.0.1, "help select" command prints this:
> {noformat}
> cqlsh> help select
> *** No browser to display CQL help. URL for help topic select : 
> https://cassandra.apache.org/doc/cql3/CQL-3.2.html#selectStmt
> {noformat}
> However, on cqlsh 6.0.0, "help select" command prints this:
> {noformat}
> cqlsh> help select
> object of type 'NoneType' has no len()
> {noformat}
> Steps to reproduce:
>  # Create and start a Cassandra 4 docker container
> {noformat}
> ~ $ docker create --name cassandra4 cassandra:4.0
> ~ $ docker start cassandra4{noformat}
>  # Get a shell inside the docker container
> {noformat}
>  docker exec -ti CONTAINER_NAME bash{noformat}
>  # Start a cqlsh and run the "help" command inside it (you have to wait for 
> the Cassandra server starting, I had to run "nodetool enablebinary" too, not 
> sure why)
> {noformat}
> root@b03a20987964:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> help select
> object of type 'NoneType' has no len()
> cqlsh> 
> {noformat}



--
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-16597) Introduce Maven wrapper to build for Maven-less build environments

2021-05-10 Thread Stefan Miklosovic (Jira)



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

Stefan Miklosovic commented on CASSANDRA-16597:
---

Hi [~mck],

I have implemented this feature as discussed 
[https://github.com/instaclustr/cassandra/commit/bc5f1cdc58c2790188b3b4958d4fe6fcaef13650]

Would you mind to review please?

> Introduce Maven wrapper to build for Maven-less build environments
> --
>
> Key: CASSANDRA-16597
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16597
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> With the introduction of CASSANDRA-16391, the build machine needs to have 
> Maven installed locally as it executes "mvn" command in its tasks. This might 
> be avoided by adding Maven wrapper which would download (and cache) such 
> installation so build environment might be completely Maven-less otherwise.



--
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-16653) Multinode counters don't get updated

2021-05-10 Thread Jira



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

Andres de la Peña commented on CASSANDRA-16653:
---

It seems that the test needs some fixing. The failing case is an upgrade from 
4.0-rc1 to indev 4.0. The {{DROP COMPACT STORAGE}} is run in the original 
version, 4.0-rc1. That version doesn't contain this bug fix, so the table 
wrongly stops being a counter table ever before doing the upgrade. I'm working 
on a patch fixing the dtest.

> Multinode counters don't get updated
> 
>
> Key: CASSANDRA-16653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16653
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Counters
>Reporter: Berenguer Blasi
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc2, 4.1
>
>
> A multi node setup with counters doesn't update counters value. Works as 
> expected on a single node though. Comes from 
> [this|https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/cql_tests.py#L460]
>  test. Repro:
> {noformat}
> ccm create counters40
> ccm populate -n 2
> ccm start
> ccm node1 cqlsh
>   CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 
> 'NetworkTopologyStrategy', 'datacenter1' : 1 } ;
>   use foo;
>   CREATE TABLE clicks ( userid int, url text, total counter, PRIMARY KEY 
> (userid, url) ) WITH COMPACT STORAGE;
>   ALTER TABLE clicks DROP COMPACT STORAGE;
>   TRUNCATE clicks;
>   UPDATE clicks SET total = total + 1 WHERE userid = 1 AND url = 
> 'http://foo.com';
>   SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com';
>  total
> ---
>  1
>   UPDATE clicks SET total = total - 4 WHERE userid = 1 AND url = 
> 'http://foo.com';
>   SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com';
>  total
> ---
>  1 *** Should be '-3'
> {noformat}



--
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-16649) Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)

2021-05-10 Thread Michael Semb Wever (Jira)



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

Michael Semb Wever commented on CASSANDRA-16649:


bq. Wanted to discuss this change in more details. …

Now that we don't keep jar files in the {{lib/}}, adding a snapshot maven 
repository to download is going to be more common for patches that cross code 
repos. That change was intentionally in a separate commit, to be thrown away 
before merge (I should have prefixed the commit msg: 'THROWAWAY …'). I too am 
not sure how we should be standardising this…

bq. Do you plan to address rc/beta/alpha comparisons in this patch (see this 
todo)?

I'm thinking that solving that is going to be easier, and more maintainable, by 
using [SemVer4j|https://github.com/vdurmont/semver4j] inside 
{{Versions.Major}}. I plan on doing that in a separate ticket. WDYT?

> Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
> --
>
> Key: CASSANDRA-16649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16649
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Test/dtest/java
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc, 4.x
>
>
> - 
> https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649
> - 
> https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk
>  



--
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-16649) Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)

2021-05-10 Thread Alex Petrov (Jira)



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

Alex Petrov commented on CASSANDRA-16649:
-

Wanted to discuss [this 
change|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk#diff-b7d8cc9a23d28a1713d5242f83da30838851d0685528abdb937afe7d9b899de6R59]
 in more details. I think it's a good idea to allow people to test out 
dtest-api changes using a snapshot, however it seems that allowing people to 
commit these things to `trunk` might be a bit dangerous, since we won't be able 
to reproduce the builds. I'm not sure what's the best way to mitigate this 
though. 

Do you plan to address {{rc/beta/alpha}} comparisons in this patch (see [this 
todo|https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649#diff-871746bc8496d850d8660ffd287e44fcc60c9050e17f12c45ab8c9ece49c3acdR122])?
 

The rest of the change looks good to me.

> Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
> --
>
> Key: CASSANDRA-16649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16649
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Test/dtest/java
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc, 4.x
>
>
> - 
> https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649
> - 
> https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk
>  



--
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-16661) Fix typo: Alterting -> Altering



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

Ekaterina Dimitrova commented on CASSANDRA-16661:
-

Left a message for one more typo I saw. Otherwise, +1

> Fix typo: Alterting -> Altering
> ---
>
> Key: CASSANDRA-16661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16661
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Edward Ribeiro
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 4.1, 4.0-rc
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Fix a typo in the response message when trying to alter a type of an UDT 
> field.



--
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-16661) Fix typo: Alterting -> Altering



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

Ekaterina Dimitrova updated CASSANDRA-16661:

Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova  (was: Ekaterina 
Dimitrova)
   Ekaterina Dimitrova, Ekaterina Dimitrova
   Status: Review In Progress  (was: Patch Available)

> Fix typo: Alterting -> Altering
> ---
>
> Key: CASSANDRA-16661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16661
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Edward Ribeiro
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 4.1, 4.0-rc
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Fix a typo in the response message when trying to alter a type of an UDT 
> field.



--
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-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup



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

Ekaterina Dimitrova commented on CASSANDRA-16644:
-

I pushed it on Friday with different timeout values and got a time when it 
fails but I wanted to try today with the final version of the multiplexer so I 
can easily track down the logs. ([~adelapena] added that option to easily find 
the logs you need)

I am fine to remove the ccm patch but at least rename correctly the tail to 
head. I will let you know if I find anything new in the logs

 

> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure 
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds 
> Missing: ['Starting listening for CQL clients'] not found in system.log: 
> Tail: INFO  [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self =  at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor 
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
>  gen_expected(range(0, 21)),
>  gen_expected(range(6, 31)),
>  gen_expected(range(21, 40))]
> >   self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return old_start(*args, **kwargs)
> ../venv/src/ccm/ccmlib/node.py:901: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> start = 1619481570.0236456, timeout = 90
> msg = "Missing: ['Starting listening for CQL clients'] not found in 
> system.log:\nTail: INFO  [main] 2021-04-26 23:59:22,590 YamlConfigura"
> node = 'node4'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> >   raise TimeoutError.create(start, timeout, msg, node)
> E   ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 
> 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in 
> system.log:
> E   Tail: INFO  [main] 2021-04-26 23:59:22,590 YamlConfigura
> ../venv/src/ccm/ccmlib/node.py:56: TimeoutError
> {noformat}



--
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-16662) Move CASSANDRA-14559s bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address into a jvm-dtest

2021-05-10 Thread Stefan Miklosovic (Jira)



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

Stefan Miklosovic commented on CASSANDRA-16662:
---

[~dcapwell] it looks good! Btw my build failed on Rat because you havent put 
the license on top of the test class.

Do you think it makes sense to spend some time on trying to "fix" 
NetworkTopologyStrategy as you commented on it in ClusterUtils? Making it 
thread safe / not setting stuff via refrection, that might be done under 
another ticket, that does not block this one to happen.

> Move CASSANDRA-14559s 
> bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address
>  into a jvm-dtest
> --
>
> Key: CASSANDRA-16662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16662
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java, Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
>
> In debugging an issue I ended up porting 
> bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address
>  into a jvm-dtest, it would be good to move away from the python dtest in 
> favor of a jvm-dtest



--
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-16625) Add a CircleCI job to run some tests repeatedly

2021-05-10 Thread Jira



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

Andres de la Peña commented on CASSANDRA-16625:
---

[~bereng] good idea, I have just added a couple of options for stopping the 
iteration on the first failure. I think we can wait for your review, should I 
set you as second reviewer?

> Add a CircleCI job to run some tests repeatedly
> ---
>
> Key: CASSANDRA-16625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16625
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> I think it could be useful to have an optional CircleCI job to run some 
> specific tests n times. That way, tickets could attach CircleCI runs showing 
> that the changes don't make a certain ticket flaky or, conversely, that they 
> fix a flaky test. Doing this systematically should mitigate the risk of 
> introducing new flaky tests, and I guess it would be more convenient and easy 
> to share than running the tests locally or on a private CI system.
> It would also be nice to have something similar in Jenkins, but I'm focusing 
> this ticket on CircleCI because it's available also for non-committers, so 
> assignees can run their tests before setting the tickets as ready for review.



--
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-16661) Fix typo: Alterting -> Altering



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

Berenguer Blasi updated CASSANDRA-16661:

Fix Version/s: 4.1

> Fix typo: Alterting -> Altering
> ---
>
> Key: CASSANDRA-16661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16661
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Edward Ribeiro
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 4.1, 4.0-rc
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Fix a typo in the response message when trying to alter a type of an UDT 
> field.



--
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-16661) Fix typo: Alterting -> Altering



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

Berenguer Blasi updated CASSANDRA-16661:

Test and Documentation Plan: Just a typo
 Status: Patch Available  (was: In Progress)

> Fix typo: Alterting -> Altering
> ---
>
> Key: CASSANDRA-16661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16661
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Edward Ribeiro
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 4.1, 4.0-rc
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Fix a typo in the response message when trying to alter a type of an UDT 
> field.



--
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-16661) Fix typo: Alterting -> Altering



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

Berenguer Blasi updated CASSANDRA-16661:

Fix Version/s: 4.0

> Fix typo: Alterting -> Altering
> ---
>
> Key: CASSANDRA-16661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16661
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Edward Ribeiro
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Fix a typo in the response message when trying to alter a type of an UDT 
> field.



--
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] [Assigned] (CASSANDRA-16661) Fix typo: Alterting -> Altering



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

Berenguer Blasi reassigned CASSANDRA-16661:
---

Assignee: Berenguer Blasi  (was: Edward Ribeiro)

> Fix typo: Alterting -> Altering
> ---
>
> Key: CASSANDRA-16661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16661
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Edward Ribeiro
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Fix a typo in the response message when trying to alter a type of an UDT 
> field.



--
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-16653) Multinode counters don't get updated



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

Berenguer Blasi commented on CASSANDRA-16653:
-

[~adelapena] 
[this|https://ci-cassandra.apache.org/job/Cassandra-4.0/31/#showFailuresLink] 
run still fails 
[counters|https://ci-cassandra.apache.org/job/Cassandra-4.0/31/testReport/junit/dtest-upgrade.upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_4_0_x_To_indev_4_0_x/test_counters/]
 and I can see it's on {{62e1d74701bcb59437aeb1c778ba7a81aac84741}} which 
should include your fix already?

> Multinode counters don't get updated
> 
>
> Key: CASSANDRA-16653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16653
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Counters
>Reporter: Berenguer Blasi
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc2, 4.1
>
>
> A multi node setup with counters doesn't update counters value. Works as 
> expected on a single node though. Comes from 
> [this|https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/cql_tests.py#L460]
>  test. Repro:
> {noformat}
> ccm create counters40
> ccm populate -n 2
> ccm start
> ccm node1 cqlsh
>   CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 
> 'NetworkTopologyStrategy', 'datacenter1' : 1 } ;
>   use foo;
>   CREATE TABLE clicks ( userid int, url text, total counter, PRIMARY KEY 
> (userid, url) ) WITH COMPACT STORAGE;
>   ALTER TABLE clicks DROP COMPACT STORAGE;
>   TRUNCATE clicks;
>   UPDATE clicks SET total = total + 1 WHERE userid = 1 AND url = 
> 'http://foo.com';
>   SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com';
>  total
> ---
>  1
>   UPDATE clicks SET total = total - 4 WHERE userid = 1 AND url = 
> 'http://foo.com';
>   SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com';
>  total
> ---
>  1 *** Should be '-3'
> {noformat}



--
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-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup



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

Berenguer Blasi commented on CASSANDRA-16644:
-

Tail patch wasn't producing anything. But seems that just by increasing the 
timeout the thing runs 
[clean|https://app.circleci.com/pipelines/github/bereng/cassandra/282/workflows/793a0963-d319-4667-acaf-a74ec3e8b84f/jobs/2697].
 It still irks me we're not bottoming out on this thing... Proposed PR 
[here|https://github.com/apache/cassandra-dtest/pull/135] but I would remove 
the ccm from Ekaterina.

> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure 
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds 
> Missing: ['Starting listening for CQL clients'] not found in system.log: 
> Tail: INFO  [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self =  at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor 
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
>  gen_expected(range(0, 21)),
>  gen_expected(range(6, 31)),
>  gen_expected(range(21, 40))]
> >   self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return old_start(*args, **kwargs)
> ../venv/src/ccm/ccmlib/node.py:901: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> start = 1619481570.0236456, timeout = 90
> msg = "Missing: ['Starting listening for CQL clients'] not found in 
> system.log:\nTail: INFO  [main] 2021-04-26 23:59:22,590 YamlConfigura"
> node = 'node4'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> >   raise TimeoutError.create(start, timeout, msg, node)
> E   ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 
> 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in 
> system.log:
> E   Tail: INFO  [main] 2021-04-26 23:59:22,590 YamlConfigura
> ../venv/src/ccm/ccmlib/node.py:56: TimeoutError
> {noformat}



--
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-16662) Move CASSANDRA-14559s bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address into a jvm-dtest

2021-05-10 Thread Stefan Miklosovic (Jira)



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

Stefan Miklosovic commented on CASSANDRA-16662:
---

Hi [~dcapwell], yes, I will look at it very shortly.

> Move CASSANDRA-14559s 
> bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address
>  into a jvm-dtest
> --
>
> Key: CASSANDRA-16662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16662
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Test/dtest/java, Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
>
> In debugging an issue I ended up porting 
> bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address
>  into a jvm-dtest, it would be good to move away from the python dtest in 
> favor of a jvm-dtest



--
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-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup