[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[
https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503262#comment-17503262
]
Brad Schoening edited comment on CASSANDRA-16983 at 3/9/22, 2:55 AM:
-
I wanted to mention that the new warning message emitted when the credential
have not been separated out will cause the python unit tests to fail. I was a
little surprised since the warning was correctly sent to sys.stderr.
FAILED test/test_cqlsh_output.py
This makes the change sort of mandatory for running the tests. Clearly one can
rework their cqlshrc, but I suspect it will not then be compatible across cqlsh
in C* 4.0 and C* 4.1. Cqlshrc will expect the credential in cqlshrc, right?
*E AssertionError: 10 ! output: '\nNotice: Credentials in the cqlshrc
file is deprecated and will be ignored in the future.\nPlease use a credentials
file to specify the username and password.\n\n\n num !\'$#@!~" |
9223372036854775807 | 0xff | True | 1E-14 |
1e+07 | 1e+05 | 2147483647 | 32767 | ∭Ƕ⑮ฑ➳❏\' | 1950-01-01
00:00:00.00+ | 127 | ---- |
newline->
n<- | 9\n\n(1 rows)'*
{*}test/test_cqlsh_output.py{*}:141: AssertionError
was (Author: bschoeni):
I wanted to mention that the new warning message emitted when the credential
have not been separated out will cause the python unit tests to fail. I was a
little surprised since the warning was correctly sent to sys.stderr.
FAILED test/test_cqlsh_output.py
This makes the change sort of mandatory for running the tests. Clearly one can
rework their cqlshrc, but I suspect it will not then be compatible across cqlsh
4.0 and 4.1. Cqlshrc will expect the credential in cqlshrc, right?
*E AssertionError: 10 ! output: '\nNotice: Credentials in the cqlshrc
file is deprecated and will be ignored in the future.\nPlease use a credentials
file to specify the username and password.\n\n\n num !\'$#@!~" |
9223372036854775807 | 0xff | True | 1E-14 |
1e+07 | 1e+05 | 2147483647 | 32767 | ∭Ƕ⑮ฑ➳❏\' | 1950-01-01
00:00:00.00+ | 127 | ---- |
newline->
n<- | 9\n\n(1 rows)'*
{*}test/test_cqlsh_output.py{*}:141: AssertionError
> Separating CQLSH credentials from the cqlshrc file
> --
>
> Key: CASSANDRA-16983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16983
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Bowen Song
>Assignee: Bowen Song
>Priority: Normal
> Labels: lhf
> Fix For: 4.1
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently, the CQLSH tool accepts credentials (username & password) from the
> following 3 places:
> 1. the command line parameter "-p"
> 2. the cqlshrc file
> 3. prompt the user
> This is not ideal.
> Credentials in the command line is a security risk, because it could be see
> by other users on a shared system.
> The cqlshrc file is better, but still not good enough. Because the cqlshrc
> file is a config file, it's often acceptable to have it as a world readable
> file, and share it with other users. It also prevents user from having
> multiple sets of credentials, either for the same Cassandra cluster or
> different clusters.
> To improve the security of CQLSH and make it secure by design, I purpose the
> following changes:
> * Warn the user if a password is giving in the command line, and recommend
> them to use a credential file instead
> * Warn the user if credentials are present in the cqlshrc file and the
> cqlshrc file is not secure (e.g.: world readable or owned by a different user)
> * Deprecate credentials in the cqlshrc, and recommend the user to move them
> to a separate credential file. The aim is to not break anything at the
> moment, but eventually stop accepting credentials from the cqlshrc file.
> * Reject the credentials file if it's not secure, and tell the user how to
> secure it. Optionally, prompt the user for password if it's an interactive
> session. (Think how does OpenSSH handle insecure credential files)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[
https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503262#comment-17503262
]
Brad Schoening edited comment on CASSANDRA-16983 at 3/9/22, 2:41 AM:
-
I wanted to mention that the new warning message emitted when the credential
have not been separated out will cause the python unit tests to fail. I was a
little surprised since the warning was correctly sent to sys.stderr.
FAILED test/test_cqlsh_output.py
This makes the change sort of mandatory for running the tests. Clearly one can
rework their cqlshrc, but I suspect it will not then be compatible across cqlsh
4.0 and 4.1. Cqlshrc will expect the credential in cqlshrc, right?
*E AssertionError: 10 ! output: '\nNotice: Credentials in the cqlshrc
file is deprecated and will be ignored in the future.\nPlease use a credentials
file to specify the username and password.\n\n\n num !\'$#@!~" |
9223372036854775807 | 0xff | True | 1E-14 |
1e+07 | 1e+05 | 2147483647 | 32767 | ∭Ƕ⑮ฑ➳❏\' | 1950-01-01
00:00:00.00+ | 127 | ---- |
newline->
n<- | 9\n\n(1 rows)'*
{*}test/test_cqlsh_output.py{*}:141: AssertionError
was (Author: bschoeni):
I wanted to mention that the new warning message emitted when the credential
have not been separated out will cause the python unit tests to fail. I was a
little surprised since the warning was correctly sent to sys.stderr.
FAILED test/test_cqlsh_output.py
This makes the change sort of mandatory for running the tests.
*E AssertionError: 10 != 6 : output: '\nNotice: Credentials in the
cqlshrc file is deprecated and will be ignored in the future.\nPlease use a
credentials file to specify the username and password.\n\n\n num | asciicol |
bigintcol | blobcol | booleancol | decimalcol |
doublecol | floatcol | intcol | smallintcol | textcol | timestampcol
| tinyintcol | uuidcol | varcharcol
|
varintcol\n-++-+--+++---+--++-+-+-++--+---+---\n
1 | __!\'$#@!~" | 9223372036854775807 | 0xff | True |
1E-14 | 1e+07 | 1e+05 | 2147483647 | 32767 | ∭Ƕ⑮ฑ➳❏\' |
1950-01-01 00:00:00.00+ | 127 |
---- | newline->\\n<- | 9\n\n(1 rows)'*
*test/test_cqlsh_output.py*:141: AssertionError
> Separating CQLSH credentials from the cqlshrc file
> --
>
> Key: CASSANDRA-16983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16983
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Bowen Song
>Assignee: Bowen Song
>Priority: Normal
> Labels: lhf
> Fix For: 4.1
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently, the CQLSH tool accepts credentials (username & password) from the
> following 3 places:
> 1. the command line parameter "-p"
> 2. the cqlshrc file
> 3. prompt the user
> This is not ideal.
> Credentials in the command line is a security risk, because it could be see
> by other users on a shared system.
> The cqlshrc file is better, but still not good enough. Because the cqlshrc
> file is a config file, it's often acceptable to have it as a world readable
> file, and share it with other users. It also prevents user from having
> multiple sets of credentials, either for the same Cassandra cluster or
> different clusters.
> To improve the security of CQLSH and make it secure by design, I purpose the
> following changes:
> * Warn the user if a password is giving in the command line, and recommend
> them to use a credential file instead
> * Warn the user if credentials are present in the cqlshrc file and the
> cqlshrc file is not secure (e.g.: world readable or owned by a different user)
> * Deprecate credentials in the cqlshrc, and recommend the user to move them
> to a separate credential file. The aim is to not break anything at the
> moment, but eventually stop accepting credentials from the cqlshrc file.
> * Reject the credentials file if it's not secure, and tell the user how to
> secure it. Optionally, prompt the user for password if it's an interactive
> session. (Think how does OpenSSH handle insecure credential files)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For
[jira] [Commented] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503262#comment-17503262 ] Brad Schoening commented on CASSANDRA-16983: I wanted to mention that the new warning message emitted when the credential have not been separated out will cause the python unit tests to fail. I was a little surprised since the warning was correctly sent to sys.stderr. FAILED test/test_cqlsh_output.py This makes the change sort of mandatory for running the tests. *E AssertionError: 10 != 6 : output: '\nNotice: Credentials in the cqlshrc file is deprecated and will be ignored in the future.\nPlease use a credentials file to specify the username and password.\n\n\n num | asciicol | bigintcol | blobcol | booleancol | decimalcol | doublecol | floatcol | intcol | smallintcol | textcol | timestampcol | tinyintcol | uuidcol | varcharcol | varintcol\n-++-+--+++---+--++-+-+-++--+---+---\n 1 | __!\'$#@!~" | 9223372036854775807 | 0xff | True | 1E-14 | 1e+07 | 1e+05 | 2147483647 | 32767 | ∭Ƕ⑮ฑ➳❏\' | 1950-01-01 00:00:00.00+ | 127 | ---- | newline->\\n<- | 9\n\n(1 rows)'* *test/test_cqlsh_output.py*:141: AssertionError > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Fix For: 4.1 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17425) Add new CQL function maxWritetime
Yifan Cai created CASSANDRA-17425: - Summary: Add new CQL function maxWritetime Key: CASSANDRA-17425 URL: https://issues.apache.org/jira/browse/CASSANDRA-17425 Project: Cassandra Issue Type: Improvement Components: CQL/Syntax Reporter: Yifan Cai Assignee: Yifan Cai The function "writetime" does not support multi-cell types, e.g. collections and UDT. It would be useful to enable querying the latest modified timestamp of a column value. I'd like to propose to add a new function named "maxWritetime", which returns the largest timestamp amongst the cells. When being applied to the single cell types, it returns the same result as "writetime". -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17188:
Reviewers: Caleb Rackliffe
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17407) Validate existence of DCs when repairing
[ https://issues.apache.org/jira/browse/CASSANDRA-17407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17407: - Fix Version/s: 3.11.13 4.1 4.0.4 (was: 3.11.x) (was: 4.0.x) Source Control Link: https://github.com/apache/cassandra/commit/b18a9f03377059d9caae8894e8734c2380344b66 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thank you! > Validate existence of DCs when repairing > > > Key: CASSANDRA-17407 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17407 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Jan Karlsson >Assignee: Jan Karlsson >Priority: Normal > Fix For: 3.11.13, 4.1, 4.0.4 > > > With the new validation of data centers in the replication factor, it might > be good to give similar treatment to repair. > Currently the behavior of the --in-dc flag only validates that it contains > the local data center. > If a list is given containing nonexistent data centers, the repair will pass > without errors or warning as long as this list also contains the local data > center. > My suggestion would be to validate all the data centers and give an error > when a nonexistent data center is given. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - 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
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ca218cc012dd8a345259bd75e945eeebdf77eef1 Merge: da2b35b 04c1289 Author: Brandon Williams AuthorDate: Tue Mar 8 17:23:30 2022 -0600 Merge branch 'cassandra-4.0' into trunk CHANGES.txt | 2 ++ src/java/org/apache/cassandra/service/StorageService.java | 7 +++ 2 files changed, 9 insertions(+) diff --cc CHANGES.txt index b2cbe0f,af8983a..1b396b9 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -130,24 -43,15 +130,26 @@@ Merged from 4.0 * Avoid rewriting all sstables during cleanup when transient replication is enabled (CASSANDRA-16966) * Prevent CQLSH from failure on Python 3.10 (CASSANDRA-16987) * Avoid trying to acquire 0 permits from the rate limiter when taking snapshot (CASSANDRA-16872) - * Upgrade Caffeine to 2.5.6 (CASSANDRA-15153) - * Include SASI components to snapshots (CASSANDRA-15134) - * Fix missed wait latencies in the output of `nodetool tpstats -F` (CASSANDRA-16938) * Remove all the state pollution between tests in SSTableReaderTest (CASSANDRA-16888) * Delay auth setup until after gossip has settled to avoid unavailables on startup (CASSANDRA-16783) - * Fix clustering order logic in CREATE MATERIALIZED VIEW (CASSANDRA-16898) * org.apache.cassandra.db.rows.ArrayCell#unsharedHeapSizeExcludingData includes data twice (CASSANDRA-16900) + * Fix clustering order logic in CREATE MATERIALIZED VIEW (CASSANDRA-16898) * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies (CASSANDRA-16854) + * Tolerate missing DNS entry when completing a host replacement (CASSANDRA-16873) + * Harden PrunableArrayQueue against Pruner implementations that might throw exceptions (CASSANDRA-16866) + * Move RepairedDataInfo to the execution controller rather than the ReadCommand to avoid unintended sharing (CASSANDRA-16721) + * Bump zstd-jni version to 1.5.0-4 (CASSANDRA-16884) + * Remove assumption that all urgent messages are small (CASSANDRA-16877) + * ArrayClustering.unsharedHeapSize does not include the data so undercounts the heap size (CASSANDRA-16845) + * Improve help, doc and error messages about sstabledump -k and -x arguments (CASSANDRA-16818) + * Add repaired/unrepaired bytes back to nodetool (CASSANDRA-15282) + * Upgrade lz4-java to 1.8.0 to add RH6 support back (CASSANDRA-16753) + * Improve DiagnosticEventService.publish(event) logging message of events (CASSANDRA-16749) + * Cleanup dependency scopes (CASSANDRA-16704) + * Make JmxHistogram#getRecentValues() and JmxTimer#getRecentValues() thread-safe (CASSANDRA-16707) Merged from 3.11: ++ * dropping of a materialized view creates a snapshot with dropped- prefix (CASSANDRA-17415) ++ * Validate existence of DCs when repairing (CASSANDRA-17407) * Add key validation to ssstablescrub (CASSANDRA-16969) * Update Jackson from 2.9.10 to 2.12.5 (CASSANDRA-16851) * Make assassinate more resilient to missing tokens (CASSANDRA-16847) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch trunk updated: Test that DCs are validated when repairing
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 35d87cf Test that DCs are validated when repairing
35d87cf is described below
commit 35d87cf231cdcac2beca35b4c474a8451d1cc9f9
Author: Jan Karlsson
AuthorDate: Wed Mar 2 12:00:52 2022 +0100
Test that DCs are validated when repairing
Patch by Jan Karlsson; reviewed by bereng and brandonwilliams for
CASSANDRA-17407
---
repair_tests/repair_test.py | 31 +++
1 file changed, 31 insertions(+)
diff --git a/repair_tests/repair_test.py b/repair_tests/repair_test.py
index c1bd71e..af04e14 100644
--- a/repair_tests/repair_test.py
+++ b/repair_tests/repair_test.py
@@ -708,6 +708,37 @@ class TestRepair(BaseRepairTest):
else:
assert len(node1.grep_log('parallelism=PARALLEL')) == 1,
str(node1.grep_log('parallelism'))
+
+@since('3.11')
+def test_repair_validates_dc(self):
+"""
+* Set up a multi DC cluster
+* Perform a -dc repair with nonexistent dc and without local dc
+* Assert that the repair is not trigger in both cases
+"""
+cluster = self._setup_multi_dc()
+node1 = cluster.nodes["node1"]
+node2 = cluster.nodes["node2"]
+node3 = cluster.nodes["node3"]
+
+opts = ["-dc", "dc1", "-dc", "dc13"]
+opts += _repair_options(self.cluster.version(), ks="ks",
sequential=False)
+# repair should fail because dc13 does not exist
+try:
+node1.repair(opts)
+except Exception as e:
+nodetool_error = e
+assert 'data center(s) [dc13] not found' in repr(nodetool_error)
+
+opts = ["-dc", "dc2", "-dc", "dc3"]
+opts += _repair_options(self.cluster.version(), ks="ks",
sequential=False)
+# repair should fail because local dc not included in repair
+try:
+node1.repair(opts)
+except Exception as e:
+nodetool_error = e
+assert 'the local data center must be part of the repair' in
repr(nodetool_error)
+
def _setup_multi_dc(self):
"""
Sets up 3 DCs (2 nodes in 'dc1', and one each in 'dc2' and 'dc3').
-
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-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 04c1289bb96a656bfc9cbf9eb7eb1ff9358f4b6f Merge: 59ea4f8 b18a9f0 Author: Brandon Williams AuthorDate: Tue Mar 8 17:20:50 2022 -0600 Merge branch 'cassandra-3.11' into cassandra-4.0 CHANGES.txt | 3 +++ src/java/org/apache/cassandra/service/StorageService.java | 7 +++ 2 files changed, 10 insertions(+) diff --cc CHANGES.txt index 9320244,c6708f5..af8983a --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,10 -1,8 +1,13 @@@ -3.11.13 - * Validate existence of DCs when repairing (CASSANDRA-17407) +4.0.4 + * Fix ObjectSizes implementation and usages (CASSANDRA-17402) + * Fix race condition bug during local session repair (CASSANDRA-17335) + * Fix ignored streaming encryption settings in sstableloader (CASSANDRA-17367) + * Streaming tasks handle empty SSTables correctly (CASSANDRA-16349) + * Prevent SSTableLoader from doing unnecessary work (CASSANDRA-16349) ++Merged from 3.11: + * dropping of a materialized view creates a snapshot with dropped- prefix (CASSANDRA-17415) ++ * Validate existence of DCs when repairing (CASSANDRA-17407) Merged from 3.0: - * filter out NULL_VERSION entries from peers table in ConfiguredLimit (CASSANDRA-16518) * Suppress inapplicable CVEs (CASSANDRA-17368) * Fix flaky test - test_cqlsh_completion.TestCqlshCompletion (CASSANDRA-17338) * Fixed TestCqlshOutput failing tests (CASSANDRA-17386) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (da2b35b -> ca218cc)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from da2b35b Merge branch 'cassandra-4.0' into trunk new b18a9f0 Validate existence of DCs when repairing new 04c1289 Merge branch 'cassandra-3.11' into cassandra-4.0 new ca218cc Merge branch 'cassandra-4.0' into trunk The 3 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: CHANGES.txt | 2 ++ src/java/org/apache/cassandra/service/StorageService.java | 7 +++ 2 files changed, 9 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated: Validate existence of DCs when repairing
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
new b18a9f0 Validate existence of DCs when repairing
b18a9f0 is described below
commit b18a9f03377059d9caae8894e8734c2380344b66
Author: Jan Karlsson
AuthorDate: Tue Mar 1 09:32:33 2022 +0100
Validate existence of DCs when repairing
Patch by Jan Karlsson; reviewed by bereng and brandonwilliams for
CASSANDRA-17407
---
CHANGES.txt | 1 +
src/java/org/apache/cassandra/service/StorageService.java | 7 +++
2 files changed, 8 insertions(+)
diff --git a/CHANGES.txt b/CHANGES.txt
index 155d11f..c6708f5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.11.13
+ * Validate existence of DCs when repairing (CASSANDRA-17407)
* dropping of a materialized view creates a snapshot with dropped- prefix
(CASSANDRA-17415)
Merged from 3.0:
* filter out NULL_VERSION entries from peers table in ConfiguredLimit
(CASSANDRA-16518)
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 49f3835..c7e0713 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -3779,6 +3779,13 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
{
throw new IllegalArgumentException("the local data center must be
part of the repair");
}
+Set existingDatacenters =
tokenMetadata.cloneOnlyTokenMap().getTopology().getDatacenterEndpoints().keys().elementSet();
+List datacenters = new ArrayList<>(options.getDataCenters());
+if (!existingDatacenters.containsAll(datacenters))
+{
+datacenters.removeAll(existingDatacenters);
+throw new IllegalArgumentException("data center(s) " +
datacenters.toString() + " not found");
+}
RepairRunnable task = new RepairRunnable(this, cmd, options, keyspace);
task.addProgressListener(progressSupport);
-
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 (59ea4f8 -> 04c1289)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 59ea4f8 Merge branch 'cassandra-3.11' into cassandra-4.0 new b18a9f0 Validate existence of DCs when repairing new 04c1289 Merge branch 'cassandra-3.11' into cassandra-4.0 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: CHANGES.txt | 3 +++ src/java/org/apache/cassandra/service/StorageService.java | 7 +++ 2 files changed, 10 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17407) Validate existence of DCs when repairing
[ https://issues.apache.org/jira/browse/CASSANDRA-17407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503220#comment-17503220 ] Brandon Williams commented on CASSANDRA-17407: -- ||Branch||CI|| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17407-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/381/workflows/893a9784-82fe-4dd3-9167-c25da069f6f2], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/381/workflows/15c2ff42-81e1-4550-a86e-24c8ccc4785e]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17407-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/382/workflows/1595da33-d586-4cc0-915f-8fc715128dfe], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/382/workflows/380f45b9-4573-42ed-b8da-5bcaa9e4692b]| These look good (some failures are fixed now that I didn't pull in, but all are unrelated.) > Validate existence of DCs when repairing > > > Key: CASSANDRA-17407 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17407 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Jan Karlsson >Assignee: Jan Karlsson >Priority: Normal > Fix For: 3.11.x, 4.0.x > > > With the new validation of data centers in the replication factor, it might > be good to give similar treatment to repair. > Currently the behavior of the --in-dc flag only validates that it contains > the local data center. > If a list is given containing nonexistent data centers, the repair will pass > without errors or warning as long as this list also contains the local data > center. > My suggestion would be to validate all the data centers and give an error > when a nonexistent data center is given. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17424) Performance and Semantic Concerns w/ Metrics for Local vs. Remote Requests in StorageProxy
[
https://issues.apache.org/jira/browse/CASSANDRA-17424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17424:
Bug Category: Parent values: Correctness(12982)Level 1 values: API /
Semantic Implementation(12988)
Complexity: Normal
Discovered By: Code Inspection
Fix Version/s: 4.x
Severity: Normal
Status: Open (was: Triage Needed)
> Performance and Semantic Concerns w/ Metrics for Local vs. Remote Requests in
> StorageProxy
> --
>
> Key: CASSANDRA-17424
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17424
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
>
> In CASSANDRA-10023, we added two new metrics to both {{ClientRequestMetrics}}
> and {{ClientWriteRequestMetrics}} to represent requests where the driver
> either does or does not make a correct token-aware choice of coordinator.
> (Auditing driver behavior is listed as the primary goal of that Jira.)
> There are, however, a few concerns we should address before this releases in
> 4.1:
> 1.) With paging enabled and a LIMIT < fetch size, {{IN}} queries can hit
> {{fetchRows()}} multiple times, so the number of local + remote requests
> isn’t the same as the number of queries marked in {{ClientRequestMetrics}} in
> {{readRegular()}}.
> 2.) {{IN}} queries will potentially mark a bunch of “remote” requests even if
> one key in the {{IN}} set is “local”.
> 3.) Something similar happens with mutations. If {{StorageProxy#mutate()}}
> receives multiple mutations, we’ll mark against one of these new metrics in
> {{ClientWriteRequestMetrics}} for each mutation, while
> {{ClientWriteRequestMetrics}} will only register the actual client request
> once.
> For cases 2 and 3, we may mark both local and remote requests for the same
> overall client request, which introduces ambiguity if these are intended to
> help audit driver coordinator selection behavior. There are a few options:
> a.) We can accept the ambiguity, but then we haven’t really accomplished the
> goal of CASSANDRA-10023 for some request types.
> b.) We can simply not record any of these metrics for requests where multiple
> partitions/tokens are involved.
> c.) We can be lenient, marking requests as “local” if any of the
> partitions/tokens involved in the client request are, in fact, local.
> “c” feels like the option that preserves as much functionality as possible
> without being ambiguous, but problem #2 above is still tricky, given the way
> IN and GROUP BY queries behave w/ paging. (Perhaps ambiguity in that case is
> acceptable?)
> In addition to the general ambiguity around the above…
> 4.) There is excessive object creation involved (on a hot path) in our
> determination of whether a request is local or remote. We should be able to
> mitigate this by getting rid of
> {{AbstractReadExecutor#getContactedReplicas()}} and relying on
> {{ReplicaPlan#lookup()}} rather than creating strings. (Even for writes, we
> should be able to push down marking into performWrite(), where the write
> ReplicaPlan is already available.)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17424) Performance and Semantic Concerns w/ Metrics for Local vs. Remote Requests in StorageProxy
Caleb Rackliffe created CASSANDRA-17424:
---
Summary: Performance and Semantic Concerns w/ Metrics for Local
vs. Remote Requests in StorageProxy
Key: CASSANDRA-17424
URL: https://issues.apache.org/jira/browse/CASSANDRA-17424
Project: Cassandra
Issue Type: Bug
Components: Observability/Metrics
Reporter: Caleb Rackliffe
In CASSANDRA-10023, we added two new metrics to both {{ClientRequestMetrics}}
and {{ClientWriteRequestMetrics}} to represent requests where the driver either
does or does not make a correct token-aware choice of coordinator. (Auditing
driver behavior is listed as the primary goal of that Jira.)
There are, however, a few concerns we should address before this releases in
4.1:
1.) With paging enabled and a LIMIT < fetch size, {{IN}} queries can hit
{{fetchRows()}} multiple times, so the number of local + remote requests isn’t
the same as the number of queries marked in {{ClientRequestMetrics}} in
{{readRegular()}}.
2.) {{IN}} queries will potentially mark a bunch of “remote” requests even if
one key in the {{IN}} set is “local”.
3.) Something similar happens with mutations. If {{StorageProxy#mutate()}}
receives multiple mutations, we’ll mark against one of these new metrics in
{{ClientWriteRequestMetrics}} for each mutation, while
{{ClientWriteRequestMetrics}} will only register the actual client request once.
For cases 2 and 3, we may mark both local and remote requests for the same
overall client request, which introduces ambiguity if these are intended to
help audit driver coordinator selection behavior. There are a few options:
a.) We can accept the ambiguity, but then we haven’t really accomplished the
goal of CASSANDRA-10023 for some request types.
b.) We can simply not record any of these metrics for requests where multiple
partitions/tokens are involved.
c.) We can be lenient, marking requests as “local” if any of the
partitions/tokens involved in the client request are, in fact, local.
“c” feels like the option that preserves as much functionality as possible
without being ambiguous, but problem #2 above is still tricky, given the way IN
and GROUP BY queries behave w/ paging. (Perhaps ambiguity in that case is
acceptable?)
In addition to the general ambiguity around the above…
4.) There is excessive object creation involved (on a hot path) in our
determination of whether a request is local or remote. We should be able to
mitigate this by getting rid of {{AbstractReadExecutor#getContactedReplicas()}}
and relying on {{ReplicaPlan#lookup()}} rather than creating strings. (Even for
writes, we should be able to push down marking into performWrite(), where the
write ReplicaPlan is already available.)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17424) Performance and Semantic Concerns w/ Metrics for Local vs. Remote Requests in StorageProxy
[
https://issues.apache.org/jira/browse/CASSANDRA-17424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe reassigned CASSANDRA-17424:
---
Assignee: Caleb Rackliffe
> Performance and Semantic Concerns w/ Metrics for Local vs. Remote Requests in
> StorageProxy
> --
>
> Key: CASSANDRA-17424
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17424
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
>
> In CASSANDRA-10023, we added two new metrics to both {{ClientRequestMetrics}}
> and {{ClientWriteRequestMetrics}} to represent requests where the driver
> either does or does not make a correct token-aware choice of coordinator.
> (Auditing driver behavior is listed as the primary goal of that Jira.)
> There are, however, a few concerns we should address before this releases in
> 4.1:
> 1.) With paging enabled and a LIMIT < fetch size, {{IN}} queries can hit
> {{fetchRows()}} multiple times, so the number of local + remote requests
> isn’t the same as the number of queries marked in {{ClientRequestMetrics}} in
> {{readRegular()}}.
> 2.) {{IN}} queries will potentially mark a bunch of “remote” requests even if
> one key in the {{IN}} set is “local”.
> 3.) Something similar happens with mutations. If {{StorageProxy#mutate()}}
> receives multiple mutations, we’ll mark against one of these new metrics in
> {{ClientWriteRequestMetrics}} for each mutation, while
> {{ClientWriteRequestMetrics}} will only register the actual client request
> once.
> For cases 2 and 3, we may mark both local and remote requests for the same
> overall client request, which introduces ambiguity if these are intended to
> help audit driver coordinator selection behavior. There are a few options:
> a.) We can accept the ambiguity, but then we haven’t really accomplished the
> goal of CASSANDRA-10023 for some request types.
> b.) We can simply not record any of these metrics for requests where multiple
> partitions/tokens are involved.
> c.) We can be lenient, marking requests as “local” if any of the
> partitions/tokens involved in the client request are, in fact, local.
> “c” feels like the option that preserves as much functionality as possible
> without being ambiguous, but problem #2 above is still tricky, given the way
> IN and GROUP BY queries behave w/ paging. (Perhaps ambiguity in that case is
> acceptable?)
> In addition to the general ambiguity around the above…
> 4.) There is excessive object creation involved (on a hot path) in our
> determination of whether a request is local or remote. We should be able to
> mitigate this by getting rid of
> {{AbstractReadExecutor#getContactedReplicas()}} and relying on
> {{ReplicaPlan#lookup()}} rather than creating strings. (Even for writes, we
> should be able to push down marking into performWrite(), where the write
> ReplicaPlan is already available.)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16518) Node restart during joining sets protocol version to V3
[
https://issues.apache.org/jira/browse/CASSANDRA-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16518:
--
Since Version: 3.0.19
Source Control Link:
https://github.com/apache/cassandra/commit/4a15c5ad5a1a6b29be9aac6a8133f4dd936e1379
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Node restart during joining sets protocol version to V3
> ---
>
> Key: CASSANDRA-16518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16518
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Joseph Clay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.27, 3.11.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While joining nodes to a cluster, an old node crashed. The old node was
> recovered however clients (datastax java) refused to connect to it.
> The driver error:
> {noformat}
> Detected added or restarted Cassandra host /: but ignoring it since
> it does not support the version V4 of the native protocol which is currently
> in use.{noformat}
> In the recovered node cassandra logs:
> {noformat}
> INFO o.a.c.transport.ConfiguredLimit Detected peers which do not fully
> support protocol V4. Capping max negotiable version to V3{noformat}
> I confirmed that ALL the nodes in the cluster, joining or otherwise, were
> apache-cassandra-3.11.6 so that error message was rather confusing.
> Eventually after digging through the code we got to the bottom of the issue:
> https://issues.apache.org/jira/browse/CASSANDRA-15193 adds a check for node
> version, which reverts the protocol version to V3 if any peer fails the
> version check. Joining nodes have NULL for their version in the peers table,
> which fails the version check.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (f18b432 -> 4a15c5a)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from f18b432 Suppress more inapplicables: CVE-2021-43797, CVE-2021-37136, CVE-2021-37137 add 4a15c5a filter out NULL_VERSION entries from peers table in ConfiguredLimit No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + src/java/org/apache/cassandra/transport/ConfiguredLimit.java | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-) - 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 (d9766f5 -> 59ea4f8)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d9766f5 Merge branch 'cassandra-3.11' into cassandra-4.0 add 4a15c5a filter out NULL_VERSION entries from peers table in ConfiguredLimit add 67b14e4 Merge branch 'cassandra-3.0' into cassandra-3.11 add 59ea4f8 Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (8def4fd -> 67b14e4)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 8def4fd dropping of a materialized view creates a snapshot with dropped- prefix add 4a15c5a filter out NULL_VERSION entries from peers table in ConfiguredLimit add 67b14e4 Merge branch 'cassandra-3.0' into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + src/java/org/apache/cassandra/transport/ConfiguredLimit.java | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-) - 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
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit da2b35b776fe5304611707b4fe3f65462346755f Merge: c0c0f61 59ea4f8 Author: Stefan Miklosovic AuthorDate: Tue Mar 8 21:49:26 2022 +0100 Merge branch 'cassandra-4.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (c0c0f61 -> da2b35b)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from c0c0f61 Merge branch 'cassandra-4.0' into trunk add 4a15c5a filter out NULL_VERSION entries from peers table in ConfiguredLimit add 67b14e4 Merge branch 'cassandra-3.0' into cassandra-3.11 add 59ea4f8 Merge branch 'cassandra-3.11' into cassandra-4.0 new da2b35b Merge branch 'cassandra-4.0' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16518) Node restart during joining sets protocol version to V3
[
https://issues.apache.org/jira/browse/CASSANDRA-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16518:
--
Fix Version/s: 3.0.27
3.11.13
(was: 3.11.x)
> Node restart during joining sets protocol version to V3
> ---
>
> Key: CASSANDRA-16518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16518
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Joseph Clay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.27, 3.11.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While joining nodes to a cluster, an old node crashed. The old node was
> recovered however clients (datastax java) refused to connect to it.
> The driver error:
> {noformat}
> Detected added or restarted Cassandra host /: but ignoring it since
> it does not support the version V4 of the native protocol which is currently
> in use.{noformat}
> In the recovered node cassandra logs:
> {noformat}
> INFO o.a.c.transport.ConfiguredLimit Detected peers which do not fully
> support protocol V4. Capping max negotiable version to V3{noformat}
> I confirmed that ALL the nodes in the cluster, joining or otherwise, were
> apache-cassandra-3.11.6 so that error message was rather confusing.
> Eventually after digging through the code we got to the bottom of the issue:
> https://issues.apache.org/jira/browse/CASSANDRA-15193 adds a check for node
> version, which reverts the protocol version to V3 if any peer fails the
> version check. Joining nodes have NULL for their version in the peers table,
> which fails the version check.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16518) Node restart during joining sets protocol version to V3
[
https://issues.apache.org/jira/browse/CASSANDRA-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16518:
--
Status: Ready to Commit (was: Review In Progress)
3.0 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1481/]
3.11
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1480/]
> Node restart during joining sets protocol version to V3
> ---
>
> Key: CASSANDRA-16518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16518
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Joseph Clay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While joining nodes to a cluster, an old node crashed. The old node was
> recovered however clients (datastax java) refused to connect to it.
> The driver error:
> {noformat}
> Detected added or restarted Cassandra host /: but ignoring it since
> it does not support the version V4 of the native protocol which is currently
> in use.{noformat}
> In the recovered node cassandra logs:
> {noformat}
> INFO o.a.c.transport.ConfiguredLimit Detected peers which do not fully
> support protocol V4. Capping max negotiable version to V3{noformat}
> I confirmed that ALL the nodes in the cluster, joining or otherwise, were
> apache-cassandra-3.11.6 so that error message was rather confusing.
> Eventually after digging through the code we got to the bottom of the issue:
> https://issues.apache.org/jira/browse/CASSANDRA-15193 adds a check for node
> version, which reverts the protocol version to V3 if any peer fails the
> version check. Joining nodes have NULL for their version in the peers table,
> which fails the version check.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16518) Node restart during joining sets protocol version to V3
[
https://issues.apache.org/jira/browse/CASSANDRA-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16518:
--
Reviewers: Brandon Williams, Sam Tunnicliffe (was: Brandon Williams, Sam
Tunnicliffe, Stefan Miklosovic)
> Node restart during joining sets protocol version to V3
> ---
>
> Key: CASSANDRA-16518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16518
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Joseph Clay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While joining nodes to a cluster, an old node crashed. The old node was
> recovered however clients (datastax java) refused to connect to it.
> The driver error:
> {noformat}
> Detected added or restarted Cassandra host /: but ignoring it since
> it does not support the version V4 of the native protocol which is currently
> in use.{noformat}
> In the recovered node cassandra logs:
> {noformat}
> INFO o.a.c.transport.ConfiguredLimit Detected peers which do not fully
> support protocol V4. Capping max negotiable version to V3{noformat}
> I confirmed that ALL the nodes in the cluster, joining or otherwise, were
> apache-cassandra-3.11.6 so that error message was rather confusing.
> Eventually after digging through the code we got to the bottom of the issue:
> https://issues.apache.org/jira/browse/CASSANDRA-15193 adds a check for node
> version, which reverts the protocol version to V3 if any peer fails the
> version check. Joining nodes have NULL for their version in the peers table,
> which fails the version check.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16518) Node restart during joining sets protocol version to V3
[
https://issues.apache.org/jira/browse/CASSANDRA-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16518:
--
Reviewers: Brandon Williams, Sam Tunnicliffe, Stefan Miklosovic
Status: Review In Progress (was: Patch Available)
> Node restart during joining sets protocol version to V3
> ---
>
> Key: CASSANDRA-16518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16518
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Joseph Clay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While joining nodes to a cluster, an old node crashed. The old node was
> recovered however clients (datastax java) refused to connect to it.
> The driver error:
> {noformat}
> Detected added or restarted Cassandra host /: but ignoring it since
> it does not support the version V4 of the native protocol which is currently
> in use.{noformat}
> In the recovered node cassandra logs:
> {noformat}
> INFO o.a.c.transport.ConfiguredLimit Detected peers which do not fully
> support protocol V4. Capping max negotiable version to V3{noformat}
> I confirmed that ALL the nodes in the cluster, joining or otherwise, were
> apache-cassandra-3.11.6 so that error message was rather confusing.
> Eventually after digging through the code we got to the bottom of the issue:
> https://issues.apache.org/jira/browse/CASSANDRA-15193 adds a check for node
> version, which reverts the protocol version to V3 if any peer fails the
> version check. Joining nodes have NULL for their version in the peers table,
> which fails the version check.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503174#comment-17503174
]
Ekaterina Dimitrova commented on CASSANDRA-17419:
-
+1 on disabling squash and merge, thanks
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503171#comment-17503171
]
Brandon Williams commented on CASSANDRA-17419:
--
Still an improvement in my mind, still +1.
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503167#comment-17503167
]
Michael Semb Wever commented on CASSANDRA-17419:
Patch updated, best we can do here is disable squash and merge, while leaving
rebase enabled. Works for me, as squash and merge are more obvious wrong for
us…
What do others thing? Still an improvement on the status-quo?
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17419:
---
Status: Patch Available (was: In Progress)
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch mck/17419/trunk deleted (was a6bf25f)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch mck/17419/trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. was a6bf25f Prevent GH pull request commits This change permanently discards the following revisions: discard a6bf25f Prevent GH pull request commits - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Prevent GH pull request commits
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch mck/17419/trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit a6bf25f5c04a62e479e88c312e85231f000c6307 Author: Mick Semb Wever AuthorDate: Sun Mar 6 12:27:05 2022 +0100 Prevent GH pull request commits patch by Mick Semb Wever; reviewed by XXX for CASSANDRA-17419 --- .asf.yml | 5 + 1 file changed, 5 insertions(+) diff --git a/.asf.yml b/.asf.yml new file mode 100644 index 000..a4ec7f7 --- /dev/null +++ b/.asf.yml @@ -0,0 +1,5 @@ +github: + enabled_merge_buttons: +squash: false +merge: false +rebase: true - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch mck/17419/trunk created (now a6bf25f)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch mck/17419/trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. at a6bf25f Prevent GH pull request commits This branch includes the following new commits: new a6bf25f Prevent GH pull request commits The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17419:
---
Status: In Progress (was: Changes Suggested)
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17419:
---
Status: Changes Suggested (was: Ready to Commit)
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503155#comment-17503155
]
Michael Semb Wever commented on CASSANDRA-17419:
Tested on cassandra-dtest.
{{noformat}}You must select at least one option{{noformat}}
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503155#comment-17503155
]
Michael Semb Wever edited comment on CASSANDRA-17419 at 3/8/22, 7:48 PM:
-
Tested on cassandra-dtest.
{noformat}You must select at least one option{noformat}
was (Author: michaelsembwever):
Tested on cassandra-dtest.
{{noformat}}You must select at least one option{{noformat}}
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch trunk updated: Prevent GH pull request commits
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git The following commit(s) were added to refs/heads/trunk by this push: new 7e7071d Prevent GH pull request commits 7e7071d is described below commit 7e7071d185a2038d4bacdebb76d3c08e0c6f1cad Author: Mick Semb Wever AuthorDate: Tue Mar 8 20:34:46 2022 +0100 Prevent GH pull request commits patch by Mick Semb Wever; reviewed by Brandon Williams, Stefan Miklosovic for CASSANDRA-17419 --- .asf.yml | 5 + 1 file changed, 5 insertions(+) diff --git a/.asf.yml b/.asf.yml new file mode 100644 index 000..5927ee7 --- /dev/null +++ b/.asf.yml @@ -0,0 +1,5 @@ +github: + enabled_merge_buttons: +squash: false +merge: false +rebase: false - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17419:
---
Status: Ready to Commit (was: Review In Progress)
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17419:
---
Reviewers: Benjamin Lerer, Brandon Williams, Stefan Miklosovic (was:
Benjamin Lerer, Brandon Williams)
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17419:
---
Reviewers: Benjamin Lerer, Brandon Williams
Status: Review In Progress (was: Patch Available)
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17423) Add Native Transport Rate Limiter Options to Example cassandra.yaml and Expose Metric for Dispatch Rate
[
https://issues.apache.org/jira/browse/CASSANDRA-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe reassigned CASSANDRA-17423:
---
Assignee: Caleb Rackliffe
> Add Native Transport Rate Limiter Options to Example cassandra.yaml and
> Expose Metric for Dispatch Rate
> ---
>
> Key: CASSANDRA-17423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17423
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1
>
>
> In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
> requests over the native transport. Given it has now had some time to
> marinate in 4.1 snapshot builds, there are a few things we should do to make
> sure it hits the bar for usability and observability:
> 1.) Add the {{native_transport_rate_limiting_enabled}} and
> {{native_transport_max_requests_per_second}} options to the example
> {{cassandra.yaml}} file w/ brief documentation.
> 2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
> native transport requests dispatched for processing. Given there are a few
> cases where native transport requests may not translate 1:1 to the number of
> times we hit StorageProxy, having this metric should make verifying the
> correct operation of the limiter easier. (Ex. IN queries w/ multiple
> partition keys, {{GROUP BY}} queries, etc.) It may make sense to look further
> into adjusting the behavior of the rate limiter to take these kinds of
> queries into account, but that is a bit more complex than either of these 2
> items, and deserves another Jira.
> * We do expose a per-connection counter for the number of requests
> dispatched, and it is exposed over a virtual table and JMX, but even if it
> were global, it is not a rate metric.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17423) Add Native Transport Rate Limiter Options to Example cassandra.yaml and Expose Metric for Dispatch Rate
[
https://issues.apache.org/jira/browse/CASSANDRA-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17423:
Change Category: Operability
Complexity: Normal
Component/s: Local/Config
Observability/Metrics
Status: Open (was: Triage Needed)
> Add Native Transport Rate Limiter Options to Example cassandra.yaml and
> Expose Metric for Dispatch Rate
> ---
>
> Key: CASSANDRA-17423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17423
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Observability/Metrics
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1
>
>
> In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
> requests over the native transport. Given it has now had some time to
> marinate in 4.1 snapshot builds, there are a few things we should do to make
> sure it hits the bar for usability and observability:
> 1.) Add the {{native_transport_rate_limiting_enabled}} and
> {{native_transport_max_requests_per_second}} options to the example
> {{cassandra.yaml}} file w/ brief documentation.
> 2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
> native transport requests dispatched for processing. Given there are a few
> cases where native transport requests may not translate 1:1 to the number of
> times we hit StorageProxy, having this metric should make verifying the
> correct operation of the limiter easier. (Ex. IN queries w/ multiple
> partition keys, {{GROUP BY}} queries, etc.) It may make sense to look further
> into adjusting the behavior of the rate limiter to take these kinds of
> queries into account, but that is a bit more complex than either of these 2
> items, and deserves another Jira.
> * We do expose a per-connection counter for the number of requests
> dispatched, and it is exposed over a virtual table and JMX, but even if it
> were global, it is not a rate metric.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17423) Add Native Transport Rate Limiter Options to Example cassandra.yaml and Expose Metric for Dispatch Rate
[
https://issues.apache.org/jira/browse/CASSANDRA-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17423:
Fix Version/s: 4.1
> Add Native Transport Rate Limiter Options to Example cassandra.yaml and
> Expose Metric for Dispatch Rate
> ---
>
> Key: CASSANDRA-17423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17423
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1
>
>
> In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
> requests over the native transport. Given it has now had some time to
> marinate in 4.1 snapshot builds, there are a few things we should do to make
> sure it hits the bar for usability and observability:
> 1.) Add the {{native_transport_rate_limiting_enabled}} and
> {{native_transport_max_requests_per_second}} options to the example
> {{cassandra.yaml}} file w/ brief documentation.
> 2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
> native transport requests dispatched for processing. Given there are a few
> cases where native transport requests may not translate 1:1 to the number of
> times we hit StorageProxy, having this metric should make verifying the
> correct operation of the limiter easier. (Ex. IN queries w/ multiple
> partition keys, {{GROUP BY}} queries, etc.) It may make sense to look further
> into adjusting the behavior of the rate limiter to take these kinds of
> queries into account, but that is a bit more complex than either of these 2
> items, and deserves another Jira.
> * We do expose a per-connection counter for the number of requests
> dispatched, and it is exposed over a virtual table and JMX, but even if it
> were global, it is not a rate metric.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17423) Add Native Transport Rate Limiter Options to Example cassandra.yaml and Expose Metric for Dispatch Rate
Caleb Rackliffe created CASSANDRA-17423:
---
Summary: Add Native Transport Rate Limiter Options to Example
cassandra.yaml and Expose Metric for Dispatch Rate
Key: CASSANDRA-17423
URL: https://issues.apache.org/jira/browse/CASSANDRA-17423
Project: Cassandra
Issue Type: Improvement
Reporter: Caleb Rackliffe
In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
requests over the native transport. Given it has now had some time to marinate
in 4.1 snapshot builds, there are a few things we should do to make sure it
hits the bar for usability and observability:
1.) Add the {{native_transport_rate_limiting_enabled}} and
{{native_transport_max_requests_per_second}} options to the example
{{cassandra.yaml}} file w/ brief documentation.
2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
native transport requests dispatched for processing. Given there are a few
cases where native transport requests may not translate 1:1 to the number of
times we hit StorageProxy, having this metric should make verifying the correct
operation of the limiter easier. (Ex. IN queries w/ multiple partition keys,
{{GROUP BY}} queries, etc.) It may make sense to look further into adjusting
the behavior of the rate limiter to take these kinds of queries into account,
but that is a bit more complex than either of these 2 items, and deserves
another Jira.
* We do expose a per-connection counter for the number of requests dispatched,
and it is exposed over a virtual table and JMX, but even if it were global, it
is not a rate metric.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17422) Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17422:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.0.x
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
> --
>
> Key: CASSANDRA-17422
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17422
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x
>
>
> Branch: 4.0
> https://ci-cassandra.apache.org/job/Cassandra-4.0/350/testReport/org.apache.cassandra.net/OutboundMessageQueueTest/testRemove_cdc/
> {code}
> java.lang.NullPointerException
> at
> org.apache.cassandra.net.OutboundMessageQueueTest.testRemove(OutboundMessageQueueTest.java:91)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Failure: 1 of 3
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17422) Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
Josh McKenzie created CASSANDRA-17422:
-
Summary: Test Failure:
org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
Key: CASSANDRA-17422
URL: https://issues.apache.org/jira/browse/CASSANDRA-17422
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Josh McKenzie
Branch: 4.0
https://ci-cassandra.apache.org/job/Cassandra-4.0/350/testReport/org.apache.cassandra.net/OutboundMessageQueueTest/testRemove_cdc/
{code}
java.lang.NullPointerException
at
org.apache.cassandra.net.OutboundMessageQueueTest.testRemove(OutboundMessageQueueTest.java:91)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
Failure: 1 of 3
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17421) Test Failure: org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove
[
https://issues.apache.org/jira/browse/CASSANDRA-17421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17421:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.0.x
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure:
> org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove
> -
>
> Key: CASSANDRA-17421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17421
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x
>
>
> Branch: 4.0
> https://ci-cassandra.apache.org/job/Cassandra-4.0/350/testReport/org.apache.cassandra.service/LeaveAndBootstrapTest/testSimultaneousMove/
> {code}
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.updatePeerInfo(StorageService.java:2440)
> at
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2810)
> at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:2316)
> at
> org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove(LeaveAndBootstrapTest.java:354)
> {code}
> Failure: 1 of 15
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17421) Test Failure: org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove
Josh McKenzie created CASSANDRA-17421:
-
Summary: Test Failure:
org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove
Key: CASSANDRA-17421
URL: https://issues.apache.org/jira/browse/CASSANDRA-17421
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Josh McKenzie
Branch: 4.0
https://ci-cassandra.apache.org/job/Cassandra-4.0/350/testReport/org.apache.cassandra.service/LeaveAndBootstrapTest/testSimultaneousMove/
{code}
java.lang.NullPointerException
at
org.apache.cassandra.service.StorageService.updatePeerInfo(StorageService.java:2440)
at
org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2810)
at
org.apache.cassandra.service.StorageService.onChange(StorageService.java:2316)
at
org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove(LeaveAndBootstrapTest.java:354)
{code}
Failure: 1 of 15
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17420) Test Failure: org.apache.cassandra.cql3.validation.miscellaneous.CrcCheckChanceTest.testChangingCrcCheckChanceOldFormat
[
https://issues.apache.org/jira/browse/CASSANDRA-17420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17420:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.x
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure:
> org.apache.cassandra.cql3.validation.miscellaneous.CrcCheckChanceTest.testChangingCrcCheckChanceOldFormat
> ---
>
> Key: CASSANDRA-17420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17420
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/992/testReport/org.apache.cassandra.cql3.validation.miscellaneous/CrcCheckChanceTest/testChangingCrcCheckChanceOldFormat_2/
> bq. Error setting schema for test (query was: CREATE KEYSPACE IF NOT EXISTS
> cql_test_keyspace WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'})
> 1 failure
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17420) Test Failure: org.apache.cassandra.cql3.validation.miscellaneous.CrcCheckChanceTest.testChangingCrcCheckChanceOldFormat
Josh McKenzie created CASSANDRA-17420:
-
Summary: Test Failure:
org.apache.cassandra.cql3.validation.miscellaneous.CrcCheckChanceTest.testChangingCrcCheckChanceOldFormat
Key: CASSANDRA-17420
URL: https://issues.apache.org/jira/browse/CASSANDRA-17420
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Josh McKenzie
https://ci-cassandra.apache.org/job/Cassandra-trunk/992/testReport/org.apache.cassandra.cql3.validation.miscellaneous/CrcCheckChanceTest/testChangingCrcCheckChanceOldFormat_2/
bq. Error setting schema for test (query was: CREATE KEYSPACE IF NOT EXISTS
cql_test_keyspace WITH replication = {'class': 'SimpleStrategy',
'replication_factor': '1'})
1 failure
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (f0ae536 -> 8def4fd)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from f0ae536 Merge pull request #1482 from ErickRamirezAU/CASSANDRA-17361-3.11 add 8def4fd dropping of a materialized view creates a snapshot with dropped- prefix No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + src/java/org/apache/cassandra/config/Schema.java | 2 +- test/unit/org/apache/cassandra/cql3/ViewTest.java | 49 +-- 3 files changed, 48 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (3233c82 -> c0c0f61)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 3233c82 Add guardrail for SELECT IN terms and their cartesian product add 477d006 Fixed title on STCS page, broken links on compaction page (3.11) add f0ae536 Merge pull request #1482 from ErickRamirezAU/CASSANDRA-17361-3.11 add 8def4fd dropping of a materialized view creates a snapshot with dropped- prefix add d9766f5 Merge branch 'cassandra-3.11' into cassandra-4.0 new c0c0f61 Merge branch 'cassandra-4.0' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - 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
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit c0c0f6186929068b87b5e0e3018e931f11fff3f1 Merge: 3233c82 d9766f5 Author: Stefan Miklosovic AuthorDate: Tue Mar 8 17:19:18 2022 +0100 Merge branch 'cassandra-4.0' into trunk - 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 (a690f33 -> d9766f5)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from a690f33 Fix ObjectSizes implementation and usages add 477d006 Fixed title on STCS page, broken links on compaction page (3.11) add f0ae536 Merge pull request #1482 from ErickRamirezAU/CASSANDRA-17361-3.11 add 8def4fd dropping of a materialized view creates a snapshot with dropped- prefix add d9766f5 Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17415) dropping of a materialized view does not create a snapshot with dropped- prefix
[ https://issues.apache.org/jira/browse/CASSANDRA-17415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17415: -- Since Version: NA Source Control Link: https://github.com/apache/cassandra/commit/8def4fd7fb5fd73cb06e66381c3de3b99e397f07 Resolution: Fixed Status: Resolved (was: Ready to Commit) > dropping of a materialized view does not create a snapshot with dropped- > prefix > --- > > Key: CASSANDRA-17415 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17415 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x > > > When auto_snapshot: true and MV is dropped, the name of the snapshot does not > start with "dropped-" prefix as a normal table would. This is an issue for > 3.11.x only. In 4.x, the code was refactored a lot and it does not happen > there. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17415) dropping of a materialized view does not create a snapshot with dropped- prefix
[ https://issues.apache.org/jira/browse/CASSANDRA-17415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17415: -- Fix Version/s: 3.11.13 (was: 3.11.x) > dropping of a materialized view does not create a snapshot with dropped- > prefix > --- > > Key: CASSANDRA-17415 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17415 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.13 > > > When auto_snapshot: true and MV is dropped, the name of the snapshot does not > start with "dropped-" prefix as a normal table would. This is an issue for > 3.11.x only. In 4.x, the code was refactored a lot and it does not happen > there. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17281) Remove support for Javascript UDF from trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-17281: --- Assignee: Ekaterina Dimitrova > Remove support for Javascript UDF from trunk > > > Key: CASSANDRA-17281 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17281 > Project: Cassandra > Issue Type: Task > Components: Feature/UDF >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > [Consensus |https://lists.apache.org/thread/mnxh94lg9v94bfntq88051z3ww16q2fk] > was reached to remove JavaScript UDF with the next major release. > We need to leave an interface for those who would like to supply a UDF > implementation. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16325) Update streaming metrics incrementally
[
https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503042#comment-17503042
]
Paulo Motta commented on CASSANDRA-16325:
-
Hi [~dgvozdenac]. Thanks for taking this up.
It seems like a similar issue happens with compaction metrics.
There was some code changes in these areas in recent versions. I think a good
start would be to inspect the code in {{trunk}} to check where streaming and
compaction size metrics are updated, and if they're being done incrementally or
only at the end of the operation.
> Update streaming metrics incrementally
> --
>
> Key: CASSANDRA-16325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16325
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Paulo Motta
>Assignee: Dejan Gvozdenac
>Priority: Normal
> Labels: lhf
>
> Currently the inbound and outbound streamed bytes metrics are incremented
> after each file is streamed, what doesn't represent the current number of
> bytes streamed since it can take a long time for a large file to be streamed.
> We should update the metric incrementally as data is streamed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17153) Guardrails for collection items and size
[
https://issues.apache.org/jira/browse/CASSANDRA-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503043#comment-17503043
]
Andres de la Peña commented on CASSANDRA-17153:
---
Rebased again on top of the last changes on trunk:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1459]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1344/workflows/a406ed7d-87fa-4277-8ef7-b03f64a09edd]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1344/workflows/ec5a2784-0498-4074-96ce-be206959271b]|
> Guardrails for collection items and size
>
>
> Key: CASSANDRA-17153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17153
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for the number of items and size of collections. For example:
> {code}
> # Guardrail to warn or fail when encountering larger size of collection data
> than threshold.
> # The two thresholds default to 0KiB to disable.
> collection_size_warn_threshold: 0KiB
> collection_size_fail_threshold: 0KiB
> # Guardrail to warn or fail when encountering more elements in collection
> than threshold.
> # The two thresholds default to -1 to disable.
> items_per_collection_warn_threshold: -1
> items_per_collection_fail_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dejan Gvozdenac reassigned CASSANDRA-16325: --- Assignee: Dejan Gvozdenac > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Dejan Gvozdenac >Priority: Normal > Labels: lhf > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17385) Guardrails for items per UDT
[
https://issues.apache.org/jira/browse/CASSANDRA-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503034#comment-17503034
]
Andres de la Peña commented on CASSANDRA-17385:
---
Rebased again on top of the last changes on trunk:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1449]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1343/workflows/123422df-990c-40f7-aedf-4046fd21343c]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1343/workflows/19754592-e3f4-49df-9bd7-5d8e1598314c]|
> Guardrails for items per UDT
>
>
> Key: CASSANDRA-17385
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17385
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add a guardrail for the number of items in a UDT. For example:
> {code}
> # Guardrail to warn or fail when creating a user-defined-type with more
> fields in than threshold.
> # Default -1 to disable.
> fields_per_udt_warn_threshold: -1
> fields_per_udt_fail_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503018#comment-17503018
]
Andres de la Peña commented on CASSANDRA-17188:
---
Rebased again over the last changes on trunk:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1392]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1342/workflows/acbc1c5c-ee18-45ca-90b9-0287316c1381]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1342/workflows/adbf4381-bc4a-4f25-9c66-ee7c47d45a8d]|
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14797) CQLSSTableWriter does not support DELETE
[
https://issues.apache.org/jira/browse/CASSANDRA-14797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502994#comment-17502994
]
Sam Tunnicliffe commented on CASSANDRA-14797:
-
CI issues were mostly attributable to CASSANDRA-17351/CASSANDRA-15234. A fix is
in flight for those, and with the workaround applied CI looks good, with only a
handful of known flaky tests failing:
|[branch|https://github.com/beobal/cassandra/tree/CASSANDRA-14797-trunk]|[J8|https://app.circleci.com/pipelines/github/beobal/cassandra/391/workflows/2f2fbea3-9234-4620-80e7-b30255cad613]|[J11|https://app.circleci.com/pipelines/github/beobal/cassandra/391/workflows/7ea28158-4ba9-48b2-b45c-a8211c49e9d1]|
> CQLSSTableWriter does not support DELETE
>
>
> Key: CASSANDRA-14797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14797
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Eric Evans
>Assignee: Doug Rohrer
>Priority: Low
> Fix For: 3.11.x, 4.x
>
> Attachments: cassandra-14797.patch
>
>
> {{CQLSSTableWriter}} doesn't work with {{DELETE}} statements, and ought to.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17415) dropping of a materialized view does not create a snapshot with dropped- prefix
[ https://issues.apache.org/jira/browse/CASSANDRA-17415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-17415: Reviewers: Paulo Motta, Paulo Motta Paulo Motta, Paulo Motta (was: Paulo Motta) Status: Review In Progress (was: Patch Available) > dropping of a materialized view does not create a snapshot with dropped- > prefix > --- > > Key: CASSANDRA-17415 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17415 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x > > > When auto_snapshot: true and MV is dropped, the name of the snapshot does not > start with "dropped-" prefix as a normal table would. This is an issue for > 3.11.x only. In 4.x, the code was refactored a lot and it does not happen > there. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17415) dropping of a materialized view does not create a snapshot with dropped- prefix
[ https://issues.apache.org/jira/browse/CASSANDRA-17415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-17415: Status: Patch Available (was: In Progress) > dropping of a materialized view does not create a snapshot with dropped- > prefix > --- > > Key: CASSANDRA-17415 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17415 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x > > > When auto_snapshot: true and MV is dropped, the name of the snapshot does not > start with "dropped-" prefix as a normal table would. This is an issue for > 3.11.x only. In 4.x, the code was refactored a lot and it does not happen > there. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17415) dropping of a materialized view does not create a snapshot with dropped- prefix
[ https://issues.apache.org/jira/browse/CASSANDRA-17415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-17415: Status: Ready to Commit (was: Review In Progress) > dropping of a materialized view does not create a snapshot with dropped- > prefix > --- > > Key: CASSANDRA-17415 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17415 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x > > > When auto_snapshot: true and MV is dropped, the name of the snapshot does not > start with "dropped-" prefix as a normal table would. This is an issue for > 3.11.x only. In 4.x, the code was refactored a lot and it does not happen > there. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17415) dropping of a materialized view does not create a snapshot with dropped- prefix
[ https://issues.apache.org/jira/browse/CASSANDRA-17415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502937#comment-17502937 ] Paulo Motta commented on CASSANDRA-17415: - +1 > dropping of a materialized view does not create a snapshot with dropped- > prefix > --- > > Key: CASSANDRA-17415 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17415 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x > > > When auto_snapshot: true and MV is dropped, the name of the snapshot does not > start with "dropped-" prefix as a normal table would. This is an issue for > 3.11.x only. In 4.x, the code was refactored a lot and it does not happen > there. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17415) dropping of a materialized view does not create a snapshot with dropped- prefix
[ https://issues.apache.org/jira/browse/CASSANDRA-17415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-17415: Status: In Progress (was: Patch Available) > dropping of a materialized view does not create a snapshot with dropped- > prefix > --- > > Key: CASSANDRA-17415 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17415 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x > > > When auto_snapshot: true and MV is dropped, the name of the snapshot does not > start with "dropped-" prefix as a normal table would. This is an issue for > 3.11.x only. In 4.x, the code was refactored a lot and it does not happen > there. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17197) Diagnostic events for guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17197:
--
Test and Documentation Plan: {{GuardrailTester}} is modified to verify the
emission of diagnostic events.
Status: Patch Available (was: In Progress)
> Diagnostic events for guardrails
>
>
> Key: CASSANDRA-17197
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17197
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add diagnostic events for guardrails, so we can monitor when each type of
> guardrail is triggered.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17197) Diagnostic events for guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17197: -- Fix Version/s: 4.x > Diagnostic events for guardrails > > > Key: CASSANDRA-17197 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17197 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.x > > > Add diagnostic events for guardrails, so we can monitor when each type of > guardrail is triggered. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17197) Diagnostic events for guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502922#comment-17502922
]
Andres de la Peña commented on CASSANDRA-17197:
---
Here is the patch adding diagnostic events for guardrails:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1485]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1340/workflows/58cc1a02-7a5a-4d60-869f-c698b56d66df]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1340/workflows/2ea9c9a1-288f-4c64-9839-611e640da42b]|
It creates a new type of diagnostic event called
[{{GuardrailEvent}}|https://github.com/adelapena/cassandra/blob/17197-trunk/src/java/org/apache/cassandra/db/guardrails/GuardrailEvent.java].
There are two types on guardrail event, which are {{WARNED}} and
{{{}FAILED{}}}, matching the soft and hard activation of the guardrail. These
events carry two properties, which are the name of the specific guardrail and
the specific error message.
As for testing, there is a consumer/listener for the new type of diagnostic
events attached to every {{{}GuardrailTester{}}}, so every time that we check
the activation of a guardrail we also check that the proper events have also
been emitted.
> Diagnostic events for guardrails
>
>
> Key: CASSANDRA-17197
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17197
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add diagnostic events for guardrails, so we can monitor when each type of
> guardrail is triggered.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17419) Prevent GH pull request commits to cassandra repository
[
https://issues.apache.org/jira/browse/CASSANDRA-17419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502912#comment-17502912
]
Stefan Miklosovic commented on CASSANDRA-17419:
---
+1 thank you, I used to be extra careful to not "push the button" even by
accident. Taking away that possibility takes some stress away :)
> Prevent GH pull request commits to cassandra repository
> ---
>
> Key: CASSANDRA-17419
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17419
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: Screenshot 2022-03-07 at 17.45.22.png
>
>
> The cassandra project (currently) does not permit commits to be pushed to the
> cassandra repository (trunk or any branch) via GH pull requests. It is easy
> to disable this with a {{.asf.yml}} file.
> Note, our other repositories: cassandra-dtest, cassandra-builds,
> cassandra-website, cassandra-in-jvm-dtest-api, …; may be candidates for
> allowing {{rebased}} GH PR merges.
> The cassandra-website repository is already set up to permit these, see
> [here|https://github.com/apache/cassandra-website/blob/trunk/.asf.yaml#L6-L10].
> So long as part of the PR review process tis checking the commit message is
> of the correct project format it works well (there are no forward merges
> across projects in this repository).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17351) Pip doesn't install ccm every time
[
https://issues.apache.org/jira/browse/CASSANDRA-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502905#comment-17502905
]
Sam Tunnicliffe commented on CASSANDRA-17351:
-
+1 to the ccm changes, I've tested that moving the tag works just the same as
if we'd manually updated the version. Great spot to use pbr for that Michael
Semb Wever
While we're here, should we sync the docker images used by the various circle
jobs? I've tried a run against trunk using the {{20210929}} image for
everything, and I only see a couple of test failures (both with JIRAs already)
[J8|https://app.circleci.com/pipelines/github/beobal/cassandra/390/workflows/6cc58a44-e442-4e12-b371-e558e9ca76cc],
[J11|https://app.circleci.com/pipelines/github/beobal/cassandra/390/workflows/02c4b438-0af6-48b0-ae93-b4ccca5564b5]
> Pip doesn't install ccm every time
> --
>
> Key: CASSANDRA-17351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17351
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Urgent
> Fix For: 4.x
>
>
> In CASSANDRA-16688 we fixed requirements.txt in DTest repo, pip install to
> run without -e for ccm in order to address the moveable tag. That worked for
> some time until last night. I successfully retagged and now ccm is not
> re-installed in Circle CI.
> Jenkins picked stuff though. But it was acting unreliably and weird so
> rerunning now things there. Results pending.
> Now I added -e for ccm in requirements.txt and it worked in CircleCI. Still
> pending results. I don't think this will be permanent solution and I am not
> sure whether it will affect also the previous branches in a way. We need to
> further investigate it and test.
> For now I will ask people to test with -e until we figure it out.
> CC [~mck] , [~bereng] , [~dcapwell] and [~stefan.miklosovic]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-10537:
---
Status: Review In Progress (was: Needs Committer)
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15266) java internal exception on attempt to UPDATE a row using CONTAINS operator
[
https://issues.apache.org/jira/browse/CASSANDRA-15266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15266:
---
Status: Ready to Commit (was: Review In Progress)
> java internal exception on attempt to UPDATE a row using CONTAINS operator
> --
>
> Key: CASSANDRA-15266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15266
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Konstantin
>Assignee: Maciej Sokol
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> kostja@atlas ~ % cqlsh -ucassandra -pcassandra
> Connected to My Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh> CREATE KEYSPACE t1 WITH replication =
> \{'class':'SimpleStrategy', 'replication_factor' : 1};
> cassandra@cqlsh> use t1;
> cassandra@cqlsh:t1> create table t (a int, b frozen>, c int,
> primary key (a, b));
> cassandra@cqlsh:t1> insert into t (a, b, c) values (1, \{1:1, 2:2}, 3);
> cassandra@cqlsh:t1> update t set c=3 where a=1 and b contains 1;
> ServerError: java.lang.UnsupportedOperationException
>
> Server log file:
> ```
> ERROR [Native-Transport-Requests-1] 2019-08-07 17:02:59,283
> QueryMessage.java:129 - Unexpected error during query
> java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.cql3.restrictions.SingleColumnRestriction$ContainsRestriction.appendTo(SingleColumnRestriction.java:454)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.valuesAsClustering(ClusteringColumnRestrictions.java:109)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumns(StatementRestrictions.java:770)
> ~[apache-cassan
> dra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.createClustering(ModificationStatement.java:312)
> ~[apache-cassandra-3.
> 11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:677)
> ~[apache-cassandra-3.11.4.j
> ar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:635)
> ~[apache-cassandra-3.11.4
> .jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:437)
> ~[apache-cassa
> ndra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:425)
> ~[apache-cassandra-3.11.4.jar:
> 3.11.4]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:225)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:256)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:566)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.44.Final.jar:4.0.44
> ...
> ```
> +Additional information for newcomers:+
> {{CONTAINS}} and {{CONTAINS KEY}} restrictions are not supported for
> {{UPDATE}} or {{DELETE}} operations but they should be properly rejected with
> a proper error message.
> To fix that problem a new check should be added in the
> {{StatementRestrictions}} constructor to thrown an
> {{InvalidRequestException}} if the relation operator is a {{CONTAINS}} or
> {{CONTAINS_KEY}} and the {{StatementType}} an {{UPDATE}} or a {{DELETION}}.
> Some unit tests should be added to {{UpdateTest}} an {{DeleteTest}} to test
> the behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15266) java internal exception on attempt to UPDATE a row using CONTAINS operator
[
https://issues.apache.org/jira/browse/CASSANDRA-15266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502881#comment-17502881
]
Benjamin Lerer commented on CASSANDRA-15266:
The patches look good. Thanks [~masokol]
> java internal exception on attempt to UPDATE a row using CONTAINS operator
> --
>
> Key: CASSANDRA-15266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15266
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Konstantin
>Assignee: Maciej Sokol
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> kostja@atlas ~ % cqlsh -ucassandra -pcassandra
> Connected to My Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh> CREATE KEYSPACE t1 WITH replication =
> \{'class':'SimpleStrategy', 'replication_factor' : 1};
> cassandra@cqlsh> use t1;
> cassandra@cqlsh:t1> create table t (a int, b frozen>, c int,
> primary key (a, b));
> cassandra@cqlsh:t1> insert into t (a, b, c) values (1, \{1:1, 2:2}, 3);
> cassandra@cqlsh:t1> update t set c=3 where a=1 and b contains 1;
> ServerError: java.lang.UnsupportedOperationException
>
> Server log file:
> ```
> ERROR [Native-Transport-Requests-1] 2019-08-07 17:02:59,283
> QueryMessage.java:129 - Unexpected error during query
> java.lang.UnsupportedOperationException: null
> at
> org.apache.cassandra.cql3.restrictions.SingleColumnRestriction$ContainsRestriction.appendTo(SingleColumnRestriction.java:454)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.valuesAsClustering(ClusteringColumnRestrictions.java:109)
> ~[a
> pache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumns(StatementRestrictions.java:770)
> ~[apache-cassan
> dra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.createClustering(ModificationStatement.java:312)
> ~[apache-cassandra-3.
> 11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:677)
> ~[apache-cassandra-3.11.4.j
> ar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:635)
> ~[apache-cassandra-3.11.4
> .jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:437)
> ~[apache-cassa
> ndra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:425)
> ~[apache-cassandra-3.11.4.jar:
> 3.11.4]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:225)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:256)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
> ~[apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:566)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
> [apache-cassandra-3.11.4.jar:3.11.4]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.44.Final.jar:4.0.44
> ...
> ```
> +Additional information for newcomers:+
> {{CONTAINS}} and {{CONTAINS KEY}} restrictions are not supported for
> {{UPDATE}} or {{DELETE}} operations but they should be properly rejected with
> a proper error message.
> To fix that problem a new check should be added in the
> {{StatementRestrictions}} constructor to thrown an
> {{InvalidRequestException}} if the relation operator is a {{CONTAINS}} or
> {{CONTAINS_KEY}} and the {{StatementType}} an {{UPDATE}} or a {{DELETION}}.
> Some unit tests should be added to {{UpdateTest}} an {{DeleteTest}} to test
> the behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502870#comment-17502870
]
Tibor Repasi commented on CASSANDRA-16378:
--
Thank you all for the support.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Fix For: 4.1
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to expose this information via virtual table
> {{system_views.clients}} and with {{{}nodetool clientstats{}}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options need to be
> retrieved in {{StartupMessage#execute}} and passed to the
> {{{}ClientState{}}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{{}ConnectedClient{}}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17187) Guardrail for SELECT IN terms and their cartesian product
[
https://issues.apache.org/jira/browse/CASSANDRA-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17187:
--
Fix Version/s: 4.1
(was: 4.x)
Source Control Link:
https://github.com/apache/cassandra/commit/3233c823116343cd95381790d736e239d800035a
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Guardrail for SELECT IN terms and their cartesian product
> -
>
> Key: CASSANDRA-17187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17187
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: lhf
> Fix For: 4.1
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Add a guardrail to limit the number restrictions generated by the cartesian
> product of the {{IN}} restrictions of a {{SELECT}} query, for example:
> {code}
> # Guardrail to warn or abort when IN query creates a cartesian product with a
> # size exceeding threshold, eg. "a in (1,2,...10) and b in (1,2...10)"
> results in
> # cartesian product of 100.
> # The two thresholds default to -1 to disable.
> in_select_cartesian_product:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> As an example of why this guardrails is proposed, these queries bring a C*
> instance to its knees even before the query starts executing:
> {code}
> @Test
> public void testPartitionKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, pk3 int, pk4 int, pk5
> int, pk6 int, pk7 int, pk8 int, pk9 int, " +
>"PRIMARY KEY((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)))");
> execute("SELECT * FROM %s WHERE pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> @Test
> public void testClusteringKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int ,ck1 int, ck2 int, ck3 int, ck4 int,
> ck5 int, ck6 int, ck7 int, ck8 int, ck9 int, " +
> "PRIMARY KEY(pk, ck1, ck2, ck3, ck4, ck5, ck6, ck7, ck8, ck9))");
> execute("SELECT * FROM %s WHERE pk = 1 " +
> "AND ck1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> {code}
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on cartesian product in the
> guardrails section of cassandra.yaml.
> # Add a {{getInCartesianProduct}} method in {{GuardrailsConfig}} returning a
> {{Threshold.Config}} object
> # Implement that method in {{GuardrailsOptions}}, which is the default
> yaml-based implementation of {{GuardrailsConfig}}
> # Add a Threshold guardrail named {{inCartesianProduct}} in Guardrails, using
> the previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in {{GuardrailsMBean}}
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails#inCartesianProduct guard method. The
> {{MultiCBuilder}} look like good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend {{ThresholdTester}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17187) Guardrail for SELECT IN terms and their cartesian product
[
https://issues.apache.org/jira/browse/CASSANDRA-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502868#comment-17502868
]
Andres de la Peña commented on CASSANDRA-17187:
---
Committed to trunk as
[3233c823116343cd95381790d736e239d800035a|https://github.com/apache/cassandra/commit/3233c823116343cd95381790d736e239d800035a],
thanks for the review :)
> Guardrail for SELECT IN terms and their cartesian product
> -
>
> Key: CASSANDRA-17187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17187
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: lhf
> Fix For: 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Add a guardrail to limit the number restrictions generated by the cartesian
> product of the {{IN}} restrictions of a {{SELECT}} query, for example:
> {code}
> # Guardrail to warn or abort when IN query creates a cartesian product with a
> # size exceeding threshold, eg. "a in (1,2,...10) and b in (1,2...10)"
> results in
> # cartesian product of 100.
> # The two thresholds default to -1 to disable.
> in_select_cartesian_product:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> As an example of why this guardrails is proposed, these queries bring a C*
> instance to its knees even before the query starts executing:
> {code}
> @Test
> public void testPartitionKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, pk3 int, pk4 int, pk5
> int, pk6 int, pk7 int, pk8 int, pk9 int, " +
>"PRIMARY KEY((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)))");
> execute("SELECT * FROM %s WHERE pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> @Test
> public void testClusteringKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int ,ck1 int, ck2 int, ck3 int, ck4 int,
> ck5 int, ck6 int, ck7 int, ck8 int, ck9 int, " +
> "PRIMARY KEY(pk, ck1, ck2, ck3, ck4, ck5, ck6, ck7, ck8, ck9))");
> execute("SELECT * FROM %s WHERE pk = 1 " +
> "AND ck1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> {code}
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on cartesian product in the
> guardrails section of cassandra.yaml.
> # Add a {{getInCartesianProduct}} method in {{GuardrailsConfig}} returning a
> {{Threshold.Config}} object
> # Implement that method in {{GuardrailsOptions}}, which is the default
> yaml-based implementation of {{GuardrailsConfig}}
> # Add a Threshold guardrail named {{inCartesianProduct}} in Guardrails, using
> the previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in {{GuardrailsMBean}}
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails#inCartesianProduct guard method. The
> {{MultiCBuilder}} look like good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend {{ThresholdTester}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Add guardrail for SELECT IN terms and their cartesian product
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 3233c82 Add guardrail for SELECT IN terms and their cartesian product 3233c82 is described below commit 3233c823116343cd95381790d736e239d800035a Author: Andrés de la Peña AuthorDate: Tue Mar 8 11:08:29 2022 + Add guardrail for SELECT IN terms and their cartesian product patch by Andrés de la Peña; reviewed by Ekaterina Dimitrova for CASSANDRA-17187 Co-authored-by: Aleksandr Sorokoumov Co-authored-by: Andrés de la Peña --- CHANGES.txt| 1 + conf/cassandra.yaml| 5 + src/java/org/apache/cassandra/config/Config.java | 3 + .../apache/cassandra/config/GuardrailsOptions.java | 26 +++ .../restrictions/ClusteringColumnRestrictions.java | 8 +- .../restrictions/PartitionKeyRestrictions.java | 3 +- .../PartitionKeySingleRestrictionSet.java | 8 +- .../cql3/restrictions/StatementRestrictions.java | 11 +- .../cassandra/cql3/restrictions/TokenFilter.java | 10 +- .../cql3/restrictions/TokenRestriction.java| 10 +- .../cassandra/cql3/statements/BatchStatement.java | 6 +- .../cql3/statements/ModificationStatement.java | 17 +- .../cassandra/cql3/statements/SelectStatement.java | 46 ++--- .../org/apache/cassandra/db/MultiCBuilder.java | 25 ++- .../apache/cassandra/db/guardrails/Guardrails.java | 32 .../cassandra/db/guardrails/GuardrailsConfig.java | 12 ++ .../cassandra/db/guardrails/GuardrailsMBean.java | 27 ++- .../cassandra/io/sstable/CQLSSTableWriter.java | 5 +- .../guardrails/GuardrailColumnsPerTableTest.java | 14 +- .../GuardrailInSelectCartesianProductTest.java | 209 + .../db/guardrails/GuardrailKeyspacesTest.java | 14 +- .../GuardrailPartitionKeysInSelectTest.java| 13 +- ...GuardrailReadBeforeWriteListOperationsTest.java | 2 +- .../GuardrailSecondaryIndexesPerTable.java | 19 +- .../db/guardrails/GuardrailTablesTest.java | 10 +- .../cassandra/db/guardrails/GuardrailTester.java | 50 +++-- .../db/guardrails/GuardrailUserTimestampsTest.java | 2 +- .../db/guardrails/GuardrailViewsPerTableTest.java | 14 +- .../cassandra/db/guardrails/ThresholdTester.java | 8 +- .../io/sstable/StressCQLSSTableWriter.java | 5 +- 30 files changed, 496 insertions(+), 119 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 92c14ee..b2cbe0f 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.1 + * Add guardrail for SELECT IN terms and their cartesian product (CASSANDRA-17187) * remove unused imports in cqlsh.py and cqlshlib (CASSANDRA-17413) * deprecate property windows_timer_interval (CASSANDRA-17404) * Expose streaming as a vtable (CASSANDRA-17390) diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml index eecb453..ef03795 100644 --- a/conf/cassandra.yaml +++ b/conf/cassandra.yaml @@ -1620,6 +1620,11 @@ drop_compact_storage_enabled: false # The two thresholds default to -1 to disable. # partition_keys_in_select_warn_threshold: -1 # partition_keys_in_select_fail_threshold: -1 +# Guardrail to warn or fail when an IN query creates a cartesian product with a size exceeding threshold, +# eg. "a in (1,2,...10) and b in (1,2...10)" results in cartesian product of 100. +# The two thresholds default to -1 to disable. +# in_select_cartesian_product_warn_threshold: -1 +# in_select_cartesian_product_fail_threshold: -1 # Startup Checks are executed as part of Cassandra startup process, not all of them # are configurable (so you can disable them) but these which are enumerated bellow. diff --git a/src/java/org/apache/cassandra/config/Config.java b/src/java/org/apache/cassandra/config/Config.java index 9dd1642..09da88c 100644 --- a/src/java/org/apache/cassandra/config/Config.java +++ b/src/java/org/apache/cassandra/config/Config.java @@ -767,10 +767,13 @@ public class Config public volatile int page_size_fail_threshold = DISABLED_GUARDRAIL; public volatile int partition_keys_in_select_warn_threshold = DISABLED_GUARDRAIL; public volatile int partition_keys_in_select_fail_threshold = DISABLED_GUARDRAIL; +public volatile int in_select_cartesian_product_warn_threshold = DISABLED_GUARDRAIL; +public volatile int in_select_cartesian_product_fail_threshold = DISABLED_GUARDRAIL; public volatile Set table_properties_ignored = Collections.emptySet(); public volatile Set table_properties_disallowed = Collections.emptySet(); public volatile boolean user_timestamps_enabled = true; public volatile boolean read_before_write_list_operations_enabled = true; + public volatile DurationSpec streaming_state_expires = DurationSpec.inDays(3);
[jira] [Commented] (CASSANDRA-16518) Node restart during joining sets protocol version to V3
[
https://issues.apache.org/jira/browse/CASSANDRA-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502866#comment-17502866
]
Sam Tunnicliffe commented on CASSANDRA-16518:
-
Yeah, I don't really see another way around this bug in the short term, so I'm
+1 on the proposed patch.
> Node restart during joining sets protocol version to V3
> ---
>
> Key: CASSANDRA-16518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16518
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Joseph Clay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While joining nodes to a cluster, an old node crashed. The old node was
> recovered however clients (datastax java) refused to connect to it.
> The driver error:
> {noformat}
> Detected added or restarted Cassandra host /: but ignoring it since
> it does not support the version V4 of the native protocol which is currently
> in use.{noformat}
> In the recovered node cassandra logs:
> {noformat}
> INFO o.a.c.transport.ConfiguredLimit Detected peers which do not fully
> support protocol V4. Capping max negotiable version to V3{noformat}
> I confirmed that ALL the nodes in the cluster, joining or otherwise, were
> apache-cassandra-3.11.6 so that error message was rather confusing.
> Eventually after digging through the code we got to the bottom of the issue:
> https://issues.apache.org/jira/browse/CASSANDRA-15193 adds a check for node
> version, which reverts the protocol version to V3 if any peer fails the
> version check. Joining nodes have NULL for their version in the peers table,
> which fails the version check.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17287) Replace cqlshlib/wcwidth.py with pypi module 'wcwidth'
[
https://issues.apache.org/jira/browse/CASSANDRA-17287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502857#comment-17502857
]
Berenguer Blasi commented on CASSANDRA-17287:
-
Oh my bad. Will be trying this in again in short though.
> Replace cqlshlib/wcwidth.py with pypi module 'wcwidth'
> --
>
> Key: CASSANDRA-17287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17287
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CQLSH sample query.jpg
>
>
> The module wcwidth implements the same Markus Kuhn algorithm defined in
> POSIX.1-2008 to return the number of cells a unicode string is expected to
> occupy.
> The module wcwidth is used by hundreds of libraries including pytest and
> prompt-toolkit (used in ipython). It replaces 379 lines of bespoke code in
> cqlshlib.
> {quote}from wcwidth import wcswidth # at [https://pypi.org/project/wcwidth/]
> print(wcswidth('コンニチハ'))
> 10
> {{from cqlshlib.wcwidth import wcswidth as cql_wcswidth}}
> print(cql_wcswidth('コンニチハ'))
> 10
> {quote}
> wcwidth appears to be used only by one line in formatting.py:
> return bval if colormap is NO_COLOR_MAP else color_text(bval, colormap,
> wcwidth.wcswidth(bval))
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17334) Pre hashed passwords in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17334:
Test and Documentation Plan: See PR
Status: Patch Available (was: In Progress)
> Pre hashed passwords in CQL
> ---
>
> Key: CASSANDRA-17334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17334
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1
>
> Attachments: cqlsh.diff
>
>
> As seen on CASSANDRA-16801 and friends we are working across the system with
> plain text passwords. These can be unintentionally revealed by intermediate
> systems. Allowing the use of hashed passwords should mitigate that. The idea
> is to add a new option {{HASHED PASSWORD}} for {{CREATE/ALTER ROLE/USER}}.
> Examples:
> {noformat}
> CREATE ROLE foo WITH login = true AND hashed password =
> '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
> ALTER ROLE foo WITH hashed password =
> '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
> {noformat}
> To generate the password hash, there will be a new tool {{hash_password}} in
> resources/cassandra/bin
> Based on original works from [~snazy]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17344) Documentation update of virtual table system_views.clients
[ https://issues.apache.org/jira/browse/CASSANDRA-17344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17344: Fix Version/s: 4.1 Source Control Link: https://github.com/apache/cassandra/commit/ac34f28e31bbc294db80e2b5d06f8904a7f41a46 Resolution: Fixed Status: Resolved (was: Ready to Commit) Thank you [~rtib] for your work! > Documentation update of virtual table system_views.clients > -- > > Key: CASSANDRA-17344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17344 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Fix For: 4.1 > > Time Spent: 50m > Remaining Estimate: 0h > > With CASSANDRA-16378 there are changes introduced to virtual table > system_views.clients. This is updating the documentation page. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Documentation update of virtual table system_views.clients
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
The following commit(s) were added to refs/heads/trunk by this push:
new ac34f28 Documentation update of virtual table system_views.clients
ac34f28 is described below
commit ac34f28e31bbc294db80e2b5d06f8904a7f41a46
Author: Bereng
AuthorDate: Tue Mar 8 11:26:44 2022 +0100
Documentation update of virtual table system_views.clients
patch by Tibor Repasi; reviewed by Berenguer Blasi, Ekaterina Dimitrova for
CASSANDRA-17344
---
doc/modules/cassandra/pages/new/virtualtables.adoc | 117 -
1 file changed, 93 insertions(+), 24 deletions(-)
diff --git a/doc/modules/cassandra/pages/new/virtualtables.adoc
b/doc/modules/cassandra/pages/new/virtualtables.adoc
index 914bc27..69035ae 100644
--- a/doc/modules/cassandra/pages/new/virtualtables.adoc
+++ b/doc/modules/cassandra/pages/new/virtualtables.adoc
@@ -109,18 +109,80 @@ We shall discuss some of the virtual tables in more
detail next.
=== Clients Virtual Table
The `clients` virtual table lists all active connections (connected
-clients) including their ip address, port, connection stage, driver
+clients) including their ip address, port, client_options, connection stage,
driver
name, driver version, hostname, protocol version, request count, ssl
enabled, ssl protocol and user name:
-cqlsh:system_views> select * from system_views.clients;
- address | port | connection_stage | driver_name | driver_version |
hostname | protocol_version | request_count | ssl_cipher_suite | ssl_enabled |
ssl_protocol | username
+---+--+-++---+--+---+--+-+--+---
- 127.0.0.1 | 50628 |ready |null | null |
localhost |4 |55 | null | False |
null | anonymous
- 127.0.0.1 | 50630 |ready |null | null |
localhost |4 |70 | null | False |
null | anonymous
+cqlsh> EXPAND ON ;
+Now Expanded output is enabled
+cqlsh> SELECT * FROM system_views.clients;
+
+@ Row 1
+--+-
+ address | 127.0.0.1
+ port | 50687
+ client_options | {'CQL_VERSION': '3.4.5', 'DRIVER_NAME': 'DataStax Python
Driver', 'DRIVER_VERSION': '3.25.0'}
+ connection_stage | ready
+ driver_name | DataStax Python Driver
+ driver_version | 3.25.0
+ hostname | localhost
+ protocol_version | 5
+ request_count| 16
+ ssl_cipher_suite | null
+ ssl_enabled | False
+ ssl_protocol | null
+ username | anonymous
+
+@ Row 2
+--+-
+ address | 127.0.0.1
+ port | 50688
+ client_options | {'CQL_VERSION': '3.4.5', 'DRIVER_NAME': 'DataStax Python
Driver', 'DRIVER_VERSION': '3.25.0'}
+ connection_stage | ready
+ driver_name | DataStax Python Driver
+ driver_version | 3.25.0
+ hostname | localhost
+ protocol_version | 5
+ request_count| 4
+ ssl_cipher_suite | null
+ ssl_enabled | False
+ ssl_protocol | null
+ username | anonymous
+
+@ Row 3
+--+-
+ address | 127.0.0.1
+ port | 50753
+ client_options | {'APPLICATION_NAME': 'TestApp', 'APPLICATION_VERSION':
'1.0.0', 'CLIENT_ID': '55b3efbd-c56b-469d-8cca-016b860b2f03', 'CQL_VERSION':
'3.0.0', 'DRIVER_NAME': 'DataStax Java driver for Apache Cassandra(R)',
'DRIVER_VERSION': '4.13.0'}
+ connection_stage | ready
+ driver_name | DataStax Java driver for Apache Cassandra(R)
+ driver_version | 4.13.0
+ hostname | localhost
+ protocol_version | 5
+ request_count| 18
+ ssl_cipher_suite | null
+ ssl_enabled | False
+ ssl_protocol | null
+ username | anonymous
+
+@ Row 4
+--+-
+ address | 127.0.0.1
+ port |
[jira] [Updated] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16378:
Fix Version/s: 4.1
(was: 4.x)
Source Control Link:
https://github.com/apache/cassandra/commit/537d02d25f1953f1907d44106f83874ac73e06b4
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed. Thx a lot [~rtib] for your work!
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Fix For: 4.1
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to expose this information via virtual table
> {{system_views.clients}} and with {{{}nodetool clientstats{}}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options need to be
> retrieved in {{StartupMessage#execute}} and passed to the
> {{{}ClientState{}}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{{}ConnectedClient{}}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Expose all client options via system_views.clients and nodetool clientstats
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 The following commit(s) were added to refs/heads/trunk by this push: new 537d02d Expose all client options via system_views.clients and nodetool clientstats 537d02d is described below commit 537d02d25f1953f1907d44106f83874ac73e06b4 Author: Tibor Répási AuthorDate: Tue Jan 4 17:33:31 2022 +0100 Expose all client options via system_views.clients and nodetool clientstats patch by Tibor Repasi reviewed by Benjamin Lerer, Berenguer Blasi, Ekaterina Dimitrova for CASSANDRA-16378 --- CHANGES.txt| 1 + NEWS.txt | 1 + .../apache/cassandra/db/virtual/ClientsTable.java | 3 + .../org/apache/cassandra/service/ClientState.java | 17 +++ .../cassandra/tools/nodetool/ClientStats.java | 5 +- .../cassandra/transport/ConnectedClient.java | 11 ++ .../transport/messages/StartupMessage.java | 1 + .../cassandra/db/virtual/ClientsTableTest.java | 74 ++ .../cassandra/tools/nodetool/ClientStatsTest.java | 162 + 9 files changed, 273 insertions(+), 2 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 2beaa5c..92c14ee 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -2,6 +2,7 @@ * remove unused imports in cqlsh.py and cqlshlib (CASSANDRA-17413) * deprecate property windows_timer_interval (CASSANDRA-17404) * Expose streaming as a vtable (CASSANDRA-17390) + * Expose all client options via system_views.clients and nodetool clientstats (CASSANDRA-16378) * Make startup checks configurable (CASSANDRA-17220) * Add guardrail for number of partition keys on IN queries (CASSANDRA-17186) * update Python test framework from nose to pytest (CASSANDRA-17293) diff --git a/NEWS.txt b/NEWS.txt index 4f5742a..65cce3c 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -56,6 +56,7 @@ using the provided 'sstableupgrade' tool. New features +- Expose all client options via system_views.clients and nodetool clientstats. - Support for String concatenation has been added through the + operator. - New configuration max_hints_size_per_host to limit the size of local hints files per host in mebibytes. Setting to non-positive value disables the limit, which is the default behavior. Setting to a positive value to ensure diff --git a/src/java/org/apache/cassandra/db/virtual/ClientsTable.java b/src/java/org/apache/cassandra/db/virtual/ClientsTable.java index 40e175b..d39c269 100644 --- a/src/java/org/apache/cassandra/db/virtual/ClientsTable.java +++ b/src/java/org/apache/cassandra/db/virtual/ClientsTable.java @@ -33,6 +33,7 @@ final class ClientsTable extends AbstractVirtualTable private static final String USERNAME = "username"; private static final String CONNECTION_STAGE = "connection_stage"; private static final String PROTOCOL_VERSION = "protocol_version"; +private static final String CLIENT_OPTIONS = "client_options"; private static final String DRIVER_NAME = "driver_name"; private static final String DRIVER_VERSION = "driver_version"; private static final String REQUEST_COUNT = "request_count"; @@ -52,6 +53,7 @@ final class ClientsTable extends AbstractVirtualTable .addRegularColumn(USERNAME, UTF8Type.instance) .addRegularColumn(CONNECTION_STAGE, UTF8Type.instance) .addRegularColumn(PROTOCOL_VERSION, Int32Type.instance) + .addRegularColumn(CLIENT_OPTIONS, MapType.getInstance(UTF8Type.instance, UTF8Type.instance, false)) .addRegularColumn(DRIVER_NAME, UTF8Type.instance) .addRegularColumn(DRIVER_VERSION, UTF8Type.instance) .addRegularColumn(REQUEST_COUNT, LongType.instance) @@ -75,6 +77,7 @@ final class ClientsTable extends AbstractVirtualTable .column(USERNAME, client.username().orElse(null)) .column(CONNECTION_STAGE, client.stage().toString().toLowerCase()) .column(PROTOCOL_VERSION, client.protocolVersion()) + .column(CLIENT_OPTIONS, client.clientOptions().orElse(null)) .column(DRIVER_NAME, client.driverName().orElse(null)) .column(DRIVER_VERSION, client.driverVersion().orElse(null)) .column(REQUEST_COUNT, client.requestCount()) diff --git a/src/java/org/apache/cassandra/service/ClientState.java b/src/java/org/apache/cassandra/service/ClientState.java index 24d6225..65c562d 100644 --- a/src/java/org/apache/cassandra/service/ClientState.java +++ b/src/java/org/apache/cassandra/service/ClientState.java @@ -23,11 +23,14 @@ import java.net.SocketAddress; import java.util.Arrays; import java.util.HashSet;
[jira] [Updated] (CASSANDRA-17415) dropping of a materialized view does not create a snapshot with dropped- prefix
[ https://issues.apache.org/jira/browse/CASSANDRA-17415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17415: -- Fix Version/s: (was: 3.0.x) > dropping of a materialized view does not create a snapshot with dropped- > prefix > --- > > Key: CASSANDRA-17415 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17415 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x > > > When auto_snapshot: true and MV is dropped, the name of the snapshot does not > start with "dropped-" prefix as a normal table would. This is an issue for > 3.11.x only. In 4.x, the code was refactored a lot and it does not happen > there. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17187) Guardrail for SELECT IN terms and their cartesian product
[
https://issues.apache.org/jira/browse/CASSANDRA-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17187:
--
Status: Ready to Commit (was: Review In Progress)
> Guardrail for SELECT IN terms and their cartesian product
> -
>
> Key: CASSANDRA-17187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17187
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: lhf
> Fix For: 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Add a guardrail to limit the number restrictions generated by the cartesian
> product of the {{IN}} restrictions of a {{SELECT}} query, for example:
> {code}
> # Guardrail to warn or abort when IN query creates a cartesian product with a
> # size exceeding threshold, eg. "a in (1,2,...10) and b in (1,2...10)"
> results in
> # cartesian product of 100.
> # The two thresholds default to -1 to disable.
> in_select_cartesian_product:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> As an example of why this guardrails is proposed, these queries bring a C*
> instance to its knees even before the query starts executing:
> {code}
> @Test
> public void testPartitionKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, pk3 int, pk4 int, pk5
> int, pk6 int, pk7 int, pk8 int, pk9 int, " +
>"PRIMARY KEY((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)))");
> execute("SELECT * FROM %s WHERE pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> @Test
> public void testClusteringKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int ,ck1 int, ck2 int, ck3 int, ck4 int,
> ck5 int, ck6 int, ck7 int, ck8 int, ck9 int, " +
> "PRIMARY KEY(pk, ck1, ck2, ck3, ck4, ck5, ck6, ck7, ck8, ck9))");
> execute("SELECT * FROM %s WHERE pk = 1 " +
> "AND ck1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> {code}
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on cartesian product in the
> guardrails section of cassandra.yaml.
> # Add a {{getInCartesianProduct}} method in {{GuardrailsConfig}} returning a
> {{Threshold.Config}} object
> # Implement that method in {{GuardrailsOptions}}, which is the default
> yaml-based implementation of {{GuardrailsConfig}}
> # Add a Threshold guardrail named {{inCartesianProduct}} in Guardrails, using
> the previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in {{GuardrailsMBean}}
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails#inCartesianProduct guard method. The
> {{MultiCBuilder}} look like good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend {{ThresholdTester}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17415) dropping of a materialized view does not create a snapshot with dropped- prefix
[ https://issues.apache.org/jira/browse/CASSANDRA-17415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17415: -- Fix Version/s: 3.0.x > dropping of a materialized view does not create a snapshot with dropped- > prefix > --- > > Key: CASSANDRA-17415 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17415 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > When auto_snapshot: true and MV is dropped, the name of the snapshot does not > start with "dropped-" prefix as a normal table would. This is an issue for > 3.11.x only. In 4.x, the code was refactored a lot and it does not happen > there. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17413) Remove unused imports
[ https://issues.apache.org/jira/browse/CASSANDRA-17413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17413: -- Source Control Link: https://github.com/apache/cassandra/commit/27ab63f00501a6afda94e760efab8af3e90c598b Resolution: Fixed Status: Resolved (was: Ready to Commit) > Remove unused imports > - > > Key: CASSANDRA-17413 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17413 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.1 > > > Python3 no longer requires the import of unicode_literals from futures. This > and a few other unused imports, should be removed. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17413) Remove unused imports
[ https://issues.apache.org/jira/browse/CASSANDRA-17413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17413: -- Fix Version/s: 4.1 (was: 4.x) > Remove unused imports > - > > Key: CASSANDRA-17413 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17413 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.1 > > > Python3 no longer requires the import of unicode_literals from futures. This > and a few other unused imports, should be removed. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: remove unused imports in cqlsh.py and cqlshlib
This is an automated email from the ASF dual-hosted git repository.
smiklosovic pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 27ab63f remove unused imports in cqlsh.py and cqlshlib
27ab63f is described below
commit 27ab63f00501a6afda94e760efab8af3e90c598b
Author: Brad Schoening <5796692+bschoen...@users.noreply.github.com>
AuthorDate: Fri Mar 4 12:02:25 2022 +0100
remove unused imports in cqlsh.py and cqlshlib
patch by Brad Schoening; reviewed by Stefan Miklosovic and Brandon Williams
for CASSANDRA-17413
---
CHANGES.txt | 1 +
bin/cqlsh.py | 13 +
pylib/cqlshlib/copyutil.py | 5 +++--
pylib/cqlshlib/cqlhandling.py| 6 --
pylib/cqlshlib/displaying.py | 2 --
pylib/cqlshlib/formatting.py | 3 ---
pylib/cqlshlib/test/__init__.py | 2 --
pylib/cqlshlib/test/ansi_colors.py | 9 ++---
pylib/cqlshlib/test/cassconnect.py | 3 ++-
pylib/cqlshlib/test/run_cqlsh.py | 19 +--
pylib/cqlshlib/test/test_copyutil.py | 13 ++---
pylib/cqlshlib/test/test_cql_parsing.py | 8
pylib/cqlshlib/test/test_cqlsh_completion.py | 6 +++---
pylib/cqlshlib/test/test_cqlsh_output.py | 2 --
pylib/cqlshlib/test/test_unicode.py | 5 +
pylib/cqlshlib/test/winpty.py| 2 +-
pylib/cqlshlib/tracing.py| 1 -
17 files changed, 45 insertions(+), 55 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index e6368eb..2beaa5c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * remove unused imports in cqlsh.py and cqlshlib (CASSANDRA-17413)
* deprecate property windows_timer_interval (CASSANDRA-17404)
* Expose streaming as a vtable (CASSANDRA-17390)
* Make startup checks configurable (CASSANDRA-17220)
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index dd3c705..dad28f1 100755
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -16,8 +16,6 @@
# See the License for the specific language governing permissions and
# limitations under the License.
-from __future__ import division, unicode_literals, print_function
-
import cmd
import codecs
import csv
@@ -37,7 +35,7 @@ from contextlib import contextmanager
from glob import glob
from uuid import UUID
-if sys.version_info < (3, 6) and sys.version_info[0:2] != (2, 7):
+if sys.version_info < (3, 6):
sys.exit("\ncqlsh requires Python 3.6+\n")
# see CASSANDRA-10428
@@ -140,8 +138,7 @@ from cassandra.auth import PlainTextAuthProvider
from cassandra.cluster import Cluster
from cassandra.cqltypes import cql_typename
from cassandra.marshal import int64_unpack
-from cassandra.metadata import (ColumnMetadata, KeyspaceMetadata,
-TableMetadata, protect_name, protect_names)
+from cassandra.metadata import (ColumnMetadata, KeyspaceMetadata,
TableMetadata)
from cassandra.policies import WhiteListRoundRobinPolicy
from cassandra.query import SimpleStatement, ordered_dict_factory,
TraceUnavailable
from cassandra.util import datetime_from_timestamp
@@ -152,15 +149,15 @@ cqlshlibdir = os.path.join(CASSANDRA_PATH, 'pylib')
if os.path.isdir(cqlshlibdir):
sys.path.insert(0, cqlshlibdir)
-from cqlshlib import cql3handling, cqlhandling, pylexotron, sslhandling,
cqlshhandling
+from cqlshlib import cql3handling, pylexotron, sslhandling, cqlshhandling
from cqlshlib.copyutil import ExportTask, ImportTask
from cqlshlib.displaying import (ANSI_RESET, BLUE, COLUMN_NAME_COLORS, CYAN,
RED, WHITE, FormattedValue, colorme)
from cqlshlib.formatting import (DEFAULT_DATE_FORMAT, DEFAULT_NANOTIME_FORMAT,
DEFAULT_TIMESTAMP_FORMAT, CqlType,
DateTimeFormat,
- format_by_type, formatter_for)
+ format_by_type)
from cqlshlib.tracing import print_trace, print_trace_session
-from cqlshlib.util import get_file_encoding_bomsize, trim_if_present
+from cqlshlib.util import get_file_encoding_bomsize
DEFAULT_HOST = '127.0.0.1'
DEFAULT_PORT = 9042
diff --git a/pylib/cqlshlib/copyutil.py b/pylib/cqlshlib/copyutil.py
index 9ecb6ae..b87340b 100644
--- a/pylib/cqlshlib/copyutil.py
+++ b/pylib/cqlshlib/copyutil.py
@@ -16,7 +16,6 @@
# See the License for the specific language governing permissions and
# limitations under the License.
-from __future__ import unicode_literals
import csv
import datetime
import json
@@ -33,6 +32,7 @@ import sys
import threading
import time
import traceback
+import errno
from bisect import bisect_right
from calendar import timegm
@@ -51,7 +51,7 @@ from six.moves.queue import Queue
from cassandra import OperationTimedOut
from cassandra.cluster import Cluster,
[jira] [Commented] (CASSANDRA-17413) Remove unused imports
[ https://issues.apache.org/jira/browse/CASSANDRA-17413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502796#comment-17502796 ] Stefan Miklosovic commented on CASSANDRA-17413: --- https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1478 > Remove unused imports > - > > Key: CASSANDRA-17413 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17413 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python3 no longer requires the import of unicode_literals from futures. This > and a few other unused imports, should be removed. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
