[jira] [Comment Edited] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[
https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846159#comment-17846159
]
Leo Toff edited comment on CASSANDRA-19335 at 5/14/24 3:39 AM:
---
Sounds good. At some point, dtests and CCM should start parsing the JSON/YAML
output instead of plain text. Speaking of JSON/YAML, I had to force
{{no-human-readable}} mode when the {{--output}} flag is present. See [this
commit|https://github.com/apache/cassandra/pull/3069/commits/e8951dc823129186ab68d72c379be7946f9844d7].
Otherwise, JSON output contains values like {{"memtable_data_size": "43.47
KiB"}} and {{{}"bloom_filter_off_heap_memory_used": "16 bytes"{}}}.
[~brandon.williams] could you help me figure out what should be my next step
here?
was (Author: JIRAUSER303078):
Sounds good. At some point, dtests and CCM should start parsing the JSON/YAML
output instead of plain text. Speaking of JSON/YAML, I had to force
{{no-human-readable}} mode when the {{--output}} flag is present. See [this
commit|https://github.com/apache/cassandra/pull/3069/commits/e8951dc823129186ab68d72c379be7946f9844d7].
[~brandon.williams] could you help me figure out what should be my next step
here?
> Default nodetool tablestats to Human-Readable Output
>
>
> Key: CASSANDRA-19335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19335
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Leo Toff
>Assignee: Leo Toff
>Priority: Low
> Fix For: 5.x
>
> Attachments: c-19335-dtest-bootstraptest-fail.txt,
> c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *Current Behavior*
> The current implementation of nodetool tablestats in Apache Cassandra outputs
> statistics in a format that is not immediately human-readable. This output
> primarily includes raw byte counts, which require additional calculation or
> conversion to be easily understood by users. This can be inefficient and
> time-consuming, especially for users who frequently monitor these statistics
> for performance tuning or maintenance purposes.
> *Proposed Change*
> We propose that nodetool tablestats should, by default, provide its output in
> a human-readable format. This change would involve converting byte counts
> into more understandable units (KiB, MiB, GiB). The tool could still retain
> the option to display raw data for those who need it, perhaps through a flag
> such as --no-human-readable or --raw.
> *Considerations*
> The change should maintain backward compatibility, ensuring that scripts or
> tools relying on the current output format can continue to function correctly.
> We should provide adequate documentation and examples of both the new default
> output and how to access the raw data format, if needed.
> *Alignment*
> Discussion in the dev mailing list:
> [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9]
> *Related work*
> Previous work in the series:
> # https://issues.apache.org/jira/browse/CASSANDRA-19015
> # https://issues.apache.org/jira/browse/CASSANDRA-19104
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[
https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846159#comment-17846159
]
Leo Toff commented on CASSANDRA-19335:
--
Sounds good. At some point, dtests and CCM should start parsing the JSON/YAML
output instead of plain text. Speaking of JSON/YAML, I had to force
{{no-human-readable}} mode when the {{--output}} flag is present. See [this
commit|https://github.com/apache/cassandra/pull/3069/commits/e8951dc823129186ab68d72c379be7946f9844d7].
[~brandon.williams] could you help me figure out what should be my next step
here?
> Default nodetool tablestats to Human-Readable Output
>
>
> Key: CASSANDRA-19335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19335
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Leo Toff
>Assignee: Leo Toff
>Priority: Low
> Fix For: 5.x
>
> Attachments: c-19335-dtest-bootstraptest-fail.txt,
> c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *Current Behavior*
> The current implementation of nodetool tablestats in Apache Cassandra outputs
> statistics in a format that is not immediately human-readable. This output
> primarily includes raw byte counts, which require additional calculation or
> conversion to be easily understood by users. This can be inefficient and
> time-consuming, especially for users who frequently monitor these statistics
> for performance tuning or maintenance purposes.
> *Proposed Change*
> We propose that nodetool tablestats should, by default, provide its output in
> a human-readable format. This change would involve converting byte counts
> into more understandable units (KiB, MiB, GiB). The tool could still retain
> the option to display raw data for those who need it, perhaps through a flag
> such as --no-human-readable or --raw.
> *Considerations*
> The change should maintain backward compatibility, ensuring that scripts or
> tools relying on the current output format can continue to function correctly.
> We should provide adequate documentation and examples of both the new default
> output and how to access the raw data format, if needed.
> *Alignment*
> Discussion in the dev mailing list:
> [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9]
> *Related work*
> Previous work in the series:
> # https://issues.apache.org/jira/browse/CASSANDRA-19015
> # https://issues.apache.org/jira/browse/CASSANDRA-19104
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19604:
Status: Review In Progress (was: Patch Available)
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-analytics) branch trunk updated: Ninja fix for CASSANDRA-19634
This is an automated email from the ASF dual-hosted git repository.
frankgh pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-analytics.git
The following commit(s) were added to refs/heads/trunk by this push:
new 16a0e5f Ninja fix for CASSANDRA-19634
16a0e5f is described below
commit 16a0e5f3193c9764d897a98126a2c3c8b4c498d5
Author: Francisco Guerrero
AuthorDate: Mon May 13 17:10:54 2024 -0700
Ninja fix for CASSANDRA-19634
Restores original spark configurations because it is causing Java 8
failures when running local development environment
---
.../test/java/org/apache/cassandra/analytics/SparkTestUtils.java| 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
a/cassandra-analytics-integration-tests/src/test/java/org/apache/cassandra/analytics/SparkTestUtils.java
b/cassandra-analytics-integration-tests/src/test/java/org/apache/cassandra/analytics/SparkTestUtils.java
index b5f62a4..e49ffdb 100644
---
a/cassandra-analytics-integration-tests/src/test/java/org/apache/cassandra/analytics/SparkTestUtils.java
+++
b/cassandra-analytics-integration-tests/src/test/java/org/apache/cassandra/analytics/SparkTestUtils.java
@@ -157,9 +157,9 @@ public class SparkTestUtils
// the quoted identifiers tests where we test
mixed case
.set("spark.sql.caseSensitive", "True")
.set("spark.master", "local[8,4]")
-
.set("spark.cassandra_analytics.sidecar.request.retries", "4")
-
.set("spark.cassandra_analytics.sidecar.request.retries.delay.milliseconds",
"250")
-
.set("spark.cassandra_analytics.sidecar.request.retries.max.delay.milliseconds",
"250");
+
.set("spark.cassandra_analytics.sidecar.request.retries", "5")
+
.set("spark.cassandra_analytics.sidecar.request.retries.delay.milliseconds",
"500")
+
.set("spark.cassandra_analytics.sidecar.request.retries.max.delay.milliseconds",
"500");
BulkSparkConf.setupSparkConf(sparkConf, true);
KryoRegister.setup(sparkConf);
return sparkConf;
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846108#comment-17846108 ] Ekaterina Dimitrova commented on CASSANDRA-18106: - bq. We weren't running dtest-upgrade-large tests at all, so there was no need for jdk switching. (We'd forgotten about the --intensive flag on upgrade tests.) Good catch bq. Are these tests really testing something that is persisted (serialised), i.e. something that happens in 3.0 that persists and isn't a problem until two major version later in 5.0 ? That sounds more like serialisation tests (that don't even need to be upgrade tests). bq. ccm still supports jdk switching with JAVAx_HOME env vars, so if we need to we can still introduce these vars carefully for just these particular tests found in dtest-upgrade-large. (i.e. there's no change to undo here, we're still moving forward to a cleaner place…) That sounds like a topic for a new ticket? We should also add the missing --intensive flag to CircleCI config, too. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846101#comment-17846101 ] Michael Semb Wever edited comment on CASSANDRA-18106 at 5/13/24 10:22 PM: -- We weren't running dtest-upgrade-large tests at all, so there was no need for jdk switching. (We'd forgotten about the --intensive flag on upgrade tests.) The tests in question are doing multi-step upgrades. (We don't recommend upgrading and switching jdk at the same time, here the absolutely correct thing for the tests to be doing is upgrading and then restarting to switch jdk, but that's kinda overkill.) Are these tests really testing something that is persisted (serialised), i.e. something that happens in 3.0 that persists and isn't a problem until two major version later in 5.0 ? That sounds more like serialisation tests (that don't even need to be upgrade tests). ccm still supports jdk switching with JAVAx_HOME env vars, so if we need to we can still introduce these vars carefully for just these particular tests found in dtest-upgrade-large. (i.e. there's no change to undo here, we're still moving forward to a cleaner place…) was (Author: michaelsembwever): We weren't running dtest-upgrade-large tests at all, so there was no need for jdk switching. (We'd forgotten about the --intensive flag on upgrade tests.) The tests in question are doing multi-step upgrades. (We don't recommend upgrading and switching jdk at the same time, here the absolutely correct thing for the tests to be doing is upgrading and then restarting to switch jdk, but that's kinda overkill.) Are these tests really testing something that is persisted (serialised), i.e. something that happens in 3.0 that persists and isn't a problem until two major version later in 5.0 ? That sounds more like serialisation tests (that don't even need to be upgrade tests). ccm still supports jdk switching with JAVAx_HOME env vars, so if we need to we can still introduce these vars carefully for just these particular tests found in dtest-upgrade-large. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846101#comment-17846101 ] Michael Semb Wever commented on CASSANDRA-18106: We weren't running dtest-upgrade-large tests at all, so there was no need for jdk switching. (We'd forgotten about the --intensive flag on upgrade tests.) The tests in question are doing multi-step upgrades. (We don't recommend upgrading and switching jdk at the same time, here the absolutely correct thing for the tests to be doing is upgrading and then restarting to switch jdk, but that's kinda overkill.) Are these tests really testing something that is persisted (serialised), i.e. something that happens in 3.0 that persists and isn't a problem until two major version later in 5.0 ? That sounds more like serialisation tests (that don't even need to be upgrade tests). ccm still supports jdk switching with JAVAx_HOME env vars, so if we need to we can still introduce these vars carefully for just these particular tests found in dtest-upgrade-large. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846100#comment-17846100
]
Dmitry Konstantinov commented on CASSANDRA-19557:
-
Agree, the last item may depend on a lot of factors like a type of GC (read vs
write barrier cost).
Regarding caching on ShallowInfoRetriever level I have one additional idea:
currently in
org.apache.cassandra.io.sstable.format.big.RowIndexEntry.ShallowInfoRetriever#fetchIndex
we do 2 seek/read operations: 1st is to find the offset for IndexInfo and the
2nd to read it. These are two quite distant regions of the file and for
standard disk access mode we do not use a benefit from a buffer in
RandomAccessReader due to jumping between the regions and reseting this buffer
again and again. A possible improvement here can be to read and cache N first
offsets (to limit the amount of memory to use) on the first read and do later
only sequential reads of IndexInfo data. By caching of less than 1Kb we can
reduce the number of syscalls even more, in my case: from few hundred to less
than 10.
If it makes sense - I can create a separate ticket for such change..
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
>
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846094#comment-17846094
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
Nothing seems to be related. I am sending it by tomorrow.
[CASSANDRA-19498-trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19498-trunk]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 14s
✓ j17_cqlsh_dtests_py311 7m 12s
✓ j17_cqlsh_dtests_py311_vnode 7m 17s
✓ j17_cqlsh_dtests_py38 7m 1s
✓ j17_cqlsh_dtests_py38_vnode 7m 38s
✓ j17_cqlshlib_cython_tests7m 30s
✓ j17_cqlshlib_tests 9m 13s
✓ j17_dtests_vnode36m 15s
✓ j17_unit_tests 13m 36s
✓ j17_utests_latest 14m 55s
✓ j17_utests_oa 13m 51s
✕ j17_dtests 37m 33s
pushed_notifications_test.TestPushedNotifications
test_move_single_node_localhost
✕ j17_dtests_latest 36m 11s
configuration_test.TestConfiguration test_change_durable_writes
topology_test.TestTopology test_resumable_decommission
✕ j17_jvm_dtests 23m 43s
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN
org.apache.cassandra.distributed.test.log.CoordinatorPathTest
readConsistencyTest
✕ j17_jvm_dtests_latest_vnode 19m 35s
org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest
testConcurrentReadWriteWorkload
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4306/workflows/af302198-2b4a-4283-a6f0-bd90710f05a8]
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail:
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846093#comment-17846093 ] Brandon Williams edited comment on CASSANDRA-18106 at 5/13/24 10:04 PM: Ah, that's right. I think this was a relevant bit: bq. b) we run the python dtest upgrade tests twice and each run ignores (filters out) upgrade paths that are not valid for the current JAVA_HOME jdk. So we obviated the need to switch JDKs during a run by doing more runs with adjacent versions that share the same JDK. was (Author: brandon.williams): Ah, that's right. I think this was a relevant bit: > b) we run the python dtest upgrade tests twice and each run ignores (filters > out) upgrade paths that are not valid for the current JAVA_HOME jdk. So we obviated the need to switch JDKs during a run by doing more runs with adjacent versions that share the same JDK. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846093#comment-17846093 ] Brandon Williams commented on CASSANDRA-18106: -- Ah, that's right. I think this was a relevant bit: > b) we run the python dtest upgrade tests twice and each run ignores (filters > out) upgrade paths that are not valid for the current JAVA_HOME jdk. So we obviated the need to switch JDKs during a run by doing more runs with adjacent versions that share the same JDK. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846092#comment-17846092
]
Ekaterina Dimitrova commented on CASSANDRA-18106:
-
{quote}From the comments it seems that both V3 and V4 will need to cross JDKs
{quote}
Not if we do not recommend that the JDK and Cassandra upgrade happen
simultaneously. Which we do not?
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846090#comment-17846090
]
Caleb Rackliffe commented on CASSANDRA-19557:
-
Thanks for responding! Those things all make sense. Who knows whether the index
access is better or worse than updating the {{IndexState}} cache in the
{{IndexedEntry}} case (unless there's a microbenchmark somewhere). I wouldn't
worry about patching unless we have real evidence that this is problematic.
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
>
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846089#comment-17846089
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 5/13/24 9:59 PM:
--
{quote}We do have tests that need to change jdks. The dtest-upgrade-large* test
types have tests like
upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
{quote}
I mentioned this back then, and if I remember correctly there was the argument
- we repeat test runs with the different branch upgrade test runs, we should
save resources?
If we consider change of jdks, we will be running the whole path when we run on
3.0, same on 3.11, same on 4.0, etc. Lots of repetition. Is this not an
argument anymore?
bq. Without the JAVAx_HOME variables set they skip steps that involve C*
versions that require a different jdk.
So this was intentional and those are not skipped when run with other branches
was (Author: e.dimitrova):
{quote}We do have tests that need to change jdks. The dtest-upgrade-large* test
types have tests like
upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
{quote}
I mentioned this back then, and if I remember correctly there was the argument
- we repeat test runs with the different branch upgrade test runs, we should
save resources?
If we consider change of jdks, we will be running the whole path when we run on
3.0, same on 3.11, same on 4.0, etc. Lots of repetition. Is this not an
argument anymore?
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846089#comment-17846089
]
Ekaterina Dimitrova commented on CASSANDRA-18106:
-
{quote}We do have tests that need to change jdks. The dtest-upgrade-large* test
types have tests like
upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
{quote}
I mentioned this back then, and if I remember correctly there was the argument
- we repeat test runs with the different branch upgrade test runs, we should
save resources?
If we consider change of jdks, we will be running the whole path when we run on
3.0, same on 3.11, same on 4.0, etc. Lots of repetition. Is this not an
argument anymore?
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846085#comment-17846085 ] Brandon Williams edited comment on CASSANDRA-18106 at 5/13/24 9:50 PM: --- >From the comments it seems that both V3 and V4 will need to cross JDKs, and >probably someday V5 will too: \# Proto v3 upgrades (v3 is supported on 2.1, 2.2, 3.0, 3.11, 4.0, 4.1, trunk) \# Proto v4 upgrades (v4 is supported on 2.2, 3.0, 3.1, 4.0, 4.1, trunk) \# Proto v5 upgrades (v5 is supported on 4.1, trunk) It is unfortunate to discover this almost a year after an implementation relying on it not being true, but I guess we have no choice but to bring back JAVAx_HOME. was (Author: brandon.williams): >From the comments it seems that both V3 and V4 will need to cross JDKs, and >probably someday V5 will too: # Proto v3 upgrades (v3 is supported on 2.1, 2.2, 3.0, 3.11, 4.0, 4.1, trunk) # Proto v4 upgrades (v4 is supported on 2.2, 3.0, 3.1, 4.0, 4.1, trunk) # Proto v5 upgrades (v5 is supported on 4.1, trunk) It is unfortunate to discover this almost a year after an implementation relying on it not being true, but I guess we have no choice but to bring back JAVAx_HOME. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[ https://issues.apache.org/jira/browse/CASSANDRA-19557 ]
Brandon Williams deleted comment on CASSANDRA-19557:
--
was (Author: brandon.williams):
Good point. Doing this in {{ShallowInfoRetriever}} instead looks viable to me.
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:829)
> {code}
> This Cassandra logic was originally written for the case when there is a
> small number of index entries and all of them are fetched in memory, so it
> was cheap to retrieve the IndexInfo
[jira] [Commented] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846086#comment-17846086
]
Dmitry Konstantinov commented on CASSANDRA-19557:
-
Hi Caleb, yes, I thought about this option as well.
The main reason why I placed the logic in the current place - the existing
indexInfoGetsHistogram metric (it is present for disk as well as for memory
cases). Before the change the metric was actually equal to the number of
fetched rows and I wanted it to represent the number of different used
IndexedEntry items.
Another reason: for me the multiple retrievals of IndexState by index again and
again during the iteration by rows looks a bit odd and ideally it should be one
retrieval per block within the iteration logic itself but that part of the
logic looks quite complicated, so I decided not to touch it - to not introduce
a possible regression :) and I put my logic as close as possible to the
iteration logic and at the same time in a way which does not require to change
a lot.
Finally, there is a tiny performance benefit from the caching for memory
IndexedEntry option as well, by reducing the number fetches from the array by
index, but, of course, it is insignificant compared to the disk
access/deserialization which is happening near by.
If you still think that it is better to place the logic in
ShallowInfoRetriever/FileIndexInfoRetriever - I can submit a patch for this
change, there are no major concerns from my side for this option as well.
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
>
[jira] [Commented] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846087#comment-17846087
]
Brandon Williams commented on CASSANDRA-19557:
--
Good point. Doing this in {{ShallowInfoRetriever}} instead looks viable to me.
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:829)
> {code}
> This Cassandra logic was originally written for the case when there is a
> small number of index entries and all of them are fetched in
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846085#comment-17846085 ] Brandon Williams commented on CASSANDRA-18106: -- >From the comments it seems that both V3 and V4 will need to cross JDKs, and >probably someday V5 will too: # Proto v3 upgrades (v3 is supported on 2.1, 2.2, 3.0, 3.11, 4.0, 4.1, trunk) # Proto v4 upgrades (v4 is supported on 2.2, 3.0, 3.1, 4.0, 4.1, trunk) # Proto v5 upgrades (v5 is supported on 4.1, trunk) It is unfortunate to discover this almost a year after an implementation relying on it not being true, but I guess we have no choice but to bring back JAVAx_HOME. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19618) Accord: Need to simulate Cassandra Journal in Accord BurnTest to detect issues earlier before they are seen in Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-19618: -- Status: Ready to Commit (was: Review In Progress) +1 from [~benedict] in GH > Accord: Need to simulate Cassandra Journal in Accord BurnTest to detect > issues earlier before they are seen in Cassandra > > > Key: CASSANDRA-19618 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19618 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > Right now Cassandra splits a txn data into 2 places: system table, and > journal (commit log like structure), when we read we read from both places > and zip together. One issue we face is the logic to join them together is in > Accord and kept failing as we would hit unexpected states. > We should simulate the journal logic in BurnTest and call this reconstruct > logic so we improve test coverage before Cassandra sees it -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19618) Accord: Need to simulate Cassandra Journal in Accord BurnTest to detect issues earlier before they are seen in Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-19618: -- Reviewers: Benedict Elliott Smith, David Capwell Status: Review In Progress (was: Patch Available) > Accord: Need to simulate Cassandra Journal in Accord BurnTest to detect > issues earlier before they are seen in Cassandra > > > Key: CASSANDRA-19618 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19618 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > Right now Cassandra splits a txn data into 2 places: system table, and > journal (commit log like structure), when we read we read from both places > and zip together. One issue we face is the logic to join them together is in > Accord and kept failing as we would hit unexpected states. > We should simulate the journal logic in BurnTest and call this reconstruct > logic so we improve test coverage before Cassandra sees it -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19635) Update target Cassandra versions for integration tests, support new 5.0.x
Bret McGuire created CASSANDRA-19635:
Summary: Update target Cassandra versions for integration tests,
support new 5.0.x
Key: CASSANDRA-19635
URL: https://issues.apache.org/jira/browse/CASSANDRA-19635
Project: Cassandra
Issue Type: Task
Components: Client/java-driver
Reporter: Bret McGuire
{color:#172b4d}[CASSANDRA-19292|https://issues.apache.org/jira/browse/CASSANDRA-19292]
added support for running integration tests against Cassandra 4.1.x but we
still need the ability to run against Cassandra 5.0.x. As of this writing we
need [riptano/ccm|https://github.com/riptano/ccm] to manage Cassandra 5.0.x
clusters. The DataStax CI infrastructure, however, uses a private fork of ccm
which adds the ability to manage DSE clusters (something riptano/ccm can't do
right now). So we presumably need to do one of the following:
{color}
* Port Cassandra 5.0.x support to the private fork
* Port DSE support to riptano/ccm
* Change the build process to install both riptano/ccm and the private fork
into distinct venvs and manage accordingly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19618) Accord: Need to simulate Cassandra Journal in Accord BurnTest to detect issues earlier before they are seen in Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-19618: -- Test and Documentation Plan: new tests and improved burn test Status: Patch Available (was: In Progress) > Accord: Need to simulate Cassandra Journal in Accord BurnTest to detect > issues earlier before they are seen in Cassandra > > > Key: CASSANDRA-19618 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19618 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > Right now Cassandra splits a txn data into 2 places: system table, and > journal (commit log like structure), when we read we read from both places > and zip together. One issue we face is the logic to join them together is in > Accord and kept failing as we would hit unexpected states. > We should simulate the journal logic in BurnTest and call this reconstruct > logic so we improve test coverage before Cassandra sees it -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846069#comment-17846069
]
Michael Semb Wever commented on CASSANDRA-18106:
We do have tests that need to change jdks. The dtest-upgrade-large* test types
have tests like
{{upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD}}
These types multi-step through the upgrades.
Without the JAVAx_HOME variables set they skip steps that involve C* versions
that require a different jdk.
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-131) Reset system properties on test completion to avoid pollution from prior integration test
[ https://issues.apache.org/jira/browse/CASSANDRASC-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846059#comment-17846059 ] Francisco Guerrero commented on CASSANDRASC-131: +1 Thanks for the patch > Reset system properties on test completion to avoid pollution from prior > integration test > - > > Key: CASSANDRASC-131 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-131 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > Some integration test alters the System properties in order to start > operations like replacement. Due to the test specific setup, there is a race > condition on rolling back the system properties and causing pollution for the > next test run and failure. > The patch is to have a common solution for integration test that records the > initial system properties and restores on completion. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18732) Baseline Diagnostic vtables for Accord
[
https://issues.apache.org/jira/browse/CASSANDRA-18732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846058#comment-17846058
]
Caleb Rackliffe commented on CASSANDRA-18732:
-
Finally getting back to this with CASSANDRA-19577 resolved...
> Baseline Diagnostic vtables for Accord
> --
>
> Key: CASSANDRA-18732
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18732
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
>
> In addition to JMX-based metrics, there are bits of diagnostic information
> for Accord that we should consider exposing through vtables:
> 1.) We should ensure that coordinator-level CQL transactions and the local
> reads and writes they spawn are visible to the existing {{QueriesTable}}
> vtable.
> The first may already just work. We may need to make some tweaks to
> {{TxnNamedRead}} and {{TxnWrite}} for the local operations though.
> ({{CommandStore}} tasks are out of scope here, as they would probably be more
> confusing than useful in {{QueriesTable}}?)
> 2.) A new vtable for pending commands for a key.
> - Disable SELECT */require a partition key
> - Might require partial back-port of stringifying table/partition key from
> Accord to be correct
> - ex. {{SELECT timestamps FROM myawesometable where ks=? and table=? and
> partition_key=?}}
> - Clustering can be the Accord timestamp elements, no further normal columns.
> 3.) A new vtable for command store-specific cache stats
> - Gather via {{Store.execute()}} for correctness.
> - Store id should be partition key (see {{AccordCommandStore}})
> - hits, misses, total (maybe just throw out the keyspaces and coalesce
> ranges?)
> 4.) (Requires [~aweisberg]'s outstanding work) A new vtable for live
> migration state
> - {{TableMigrationState}} could be flattened into a row
> - Is this already persisted? If so, why a new vtable?
> 5.) A vtable to expose {{accord.local.Node#coordinating()}} as a map
> - ex. {{SELECT txn_id, type}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846048#comment-17846048
]
Caleb Rackliffe commented on CASSANDRA-19557:
-
Apologies for coming to this a little late, but I'm curious if it would have
made more sense to cache in {{ShallowInfoRetriever}} itself. That way,
{{IndexState}} wouldn't have to concern itself when {{ShallowIndexedEntry}}
isn't used? (It doesn't look like any of these classes are meant to be
thread-safe, so that shouldn't be a reason not to.)
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
>
[jira] [Updated] (CASSANDRASC-131) Reset system properties on test completion to avoid pollution from prior integration test
[ https://issues.apache.org/jira/browse/CASSANDRASC-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRASC-131: --- Reviewers: Francisco Guerrero Status: Review In Progress (was: Patch Available) > Reset system properties on test completion to avoid pollution from prior > integration test > - > > Key: CASSANDRASC-131 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-131 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > Some integration test alters the System properties in order to start > operations like replacement. Due to the test specific setup, there is a race > condition on rolling back the system properties and causing pollution for the > next test run and failure. > The patch is to have a common solution for integration test that records the > initial system properties and restores on completion. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846045#comment-17846045
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
[CASSANDRA-19498-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19498-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 11s
✓ j17_cqlsh_dtests_py311 6m 43s
✓ j17_cqlsh_dtests_py311_vnode 6m 11s
✓ j17_cqlsh_dtests_py38 6m 2s
✓ j17_cqlsh_dtests_py38_vnode 6m 31s
✓ j17_cqlshlib_cython_tests7m 21s
✓ j17_cqlshlib_tests 6m 43s
✓ j17_dtests 35m 20s
✓ j17_dtests_latest 33m 16s
✓ j17_dtests_vnode33m 50s
✓ j17_jvm_dtests 22m 25s
✓ j17_jvm_dtests_latest_vnode 17m 1s
✓ j17_unit_tests 15m 43s
✓ j17_utests_latest 14m 16s
✓ j17_utests_oa 14m 16s
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4305/workflows/f1f3c878-e0be-4b3c-9b53-315b3148e556]
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19599) Remove unused config params for out of range token requests
[
https://issues.apache.org/jira/browse/CASSANDRA-19599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19599:
Attachment: ci_summary.html
> Remove unused config params for out of range token requests
> ---
>
> Key: CASSANDRA-19599
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19599
> Project: Cassandra
> Issue Type: Task
> Components: Local/Config
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> The fields {{log_out_of_token_range_requests}} and
> {{reject_out_of_token_range_requests}} in {{Config.java}} have never actually
> been used and are just vestiges from early development on CEP-21.
> We should remove them and the related accessors in {{DatabaseDescriptor}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-131) Reset system properties on test completion to avoid pollution from prior integration test
[ https://issues.apache.org/jira/browse/CASSANDRASC-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-131: -- Test and Documentation Plan: ci; integration test Status: Patch Available (was: Open) PR: https://github.com/apache/cassandra-sidecar/pull/122 CI: https://app.circleci.com/pipelines/github/yifan-c/cassandra-sidecar?branch=CASSANDRASC-131%2Ftrunk > Reset system properties on test completion to avoid pollution from prior > integration test > - > > Key: CASSANDRASC-131 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-131 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > Some integration test alters the System properties in order to start > operations like replacement. Due to the test specific setup, there is a race > condition on rolling back the system properties and causing pollution for the > next test run and failure. > The patch is to have a common solution for integration test that records the > initial system properties and restores on completion. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-131) Reset system properties on test completion to avoid pollution from prior integration test
[ https://issues.apache.org/jira/browse/CASSANDRASC-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-131: -- Description: Some integration test alters the System properties in order to start operations like replacement. Due to the test specific setup, there is a race condition on rolling back the system properties and causing pollution for the next test run and failure. The patch is to have a common solution for integration test that records the initial system properties and restores on completion. was: Some integration test alters the System properties in order to start operations like replacement. Due to the test specific setup, there is a race condition on rolling back the system properties and causing population for the next test run and failure. The patch is to have a common solution for integration test that records the initial system properties and restores on completion. > Reset system properties on test completion to avoid pollution from prior > integration test > - > > Key: CASSANDRASC-131 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-131 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > Some integration test alters the System properties in order to start > operations like replacement. Due to the test specific setup, there is a race > condition on rolling back the system properties and causing pollution for the > next test run and failure. > The patch is to have a common solution for integration test that records the > initial system properties and restores on completion. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-131) Reset system properties on test completion to avoid population from prior integration test
[ https://issues.apache.org/jira/browse/CASSANDRASC-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRASC-131: --- Labels: pull-request-available (was: ) > Reset system properties on test completion to avoid population from prior > integration test > -- > > Key: CASSANDRASC-131 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-131 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > Some integration test alters the System properties in order to start > operations like replacement. Due to the test specific setup, there is a race > condition on rolling back the system properties and causing population for > the next test run and failure. > The patch is to have a common solution for integration test that records the > initial system properties and restores on completion. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-131) Reset system properties on test completion to avoid pollution from prior integration test
[ https://issues.apache.org/jira/browse/CASSANDRASC-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-131: -- Summary: Reset system properties on test completion to avoid pollution from prior integration test (was: Reset system properties on test completion to avoid population from prior integration test) > Reset system properties on test completion to avoid pollution from prior > integration test > - > > Key: CASSANDRASC-131 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-131 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > Some integration test alters the System properties in order to start > operations like replacement. Due to the test specific setup, there is a race > condition on rolling back the system properties and causing population for > the next test run and failure. > The patch is to have a common solution for integration test that records the > initial system properties and restores on completion. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-131) Reset system properties on test completion to avoid population from prior integration test
[ https://issues.apache.org/jira/browse/CASSANDRASC-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-131: -- Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > Reset system properties on test completion to avoid population from prior > integration test > -- > > Key: CASSANDRASC-131 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-131 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > Some integration test alters the System properties in order to start > operations like replacement. Due to the test specific setup, there is a race > condition on rolling back the system properties and causing population for > the next test run and failure. > The patch is to have a common solution for integration test that records the > initial system properties and restores on completion. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRASC-131) Reset system properties on test completion to avoid population from prior integration test
Yifan Cai created CASSANDRASC-131: - Summary: Reset system properties on test completion to avoid population from prior integration test Key: CASSANDRASC-131 URL: https://issues.apache.org/jira/browse/CASSANDRASC-131 Project: Sidecar for Apache Cassandra Issue Type: Task Components: Rest API Reporter: Yifan Cai Assignee: Yifan Cai Some integration test alters the System properties in order to start operations like replacement. Due to the test specific setup, there is a race condition on rolling back the system properties and causing population for the next test run and failure. The patch is to have a common solution for integration test that records the initial system properties and restores on completion. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19534) unbounded queues in native transport requests lead to node instability
[
https://issues.apache.org/jira/browse/CASSANDRA-19534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846031#comment-17846031
]
Caleb Rackliffe commented on CASSANDRA-19534:
-
+1 LGTM
(dropped a couple more little cleanup nits in the PR)
> unbounded queues in native transport requests lead to node instability
> --
>
> Key: CASSANDRA-19534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19534
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Jon Haddad
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Attachments: Scenario 1 - QUEUE + Backpressure.jpg, Scenario 1 -
> QUEUE.jpg, Scenario 1 - Stock.jpg, Scenario 2 - QUEUE + Backpressure.jpg,
> Scenario 2 - QUEUE.jpg, Scenario 2 - Stock.jpg, ci_summary.html,
> image-2024-05-03-16-08-10-101.png, screenshot-1.png, screenshot-2.png,
> screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png,
> screenshot-7.png, screenshot-8.png, screenshot-9.png
>
> Time Spent: 9h 40m
> Remaining Estimate: 0h
>
> When a node is under pressure, hundreds of thousands of requests can show up
> in the native transport queue, and it looks like it can take way longer to
> timeout than is configured. We should be shedding load much more
> aggressively and use a bounded queue for incoming work. This is extremely
> evident when we combine a resource consuming workload with a smaller one:
> Running 5.0 HEAD on a single node as of today:
> {noformat}
> # populate only
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --maxrlat 100 --populate
> 10m --rate 50k -n 1
> # workload 1 - larger reads
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --rate 200 -d 1d
> # second workload - small reads
> easy-cass-stress run KeyValue -p 1m --rate 20k -r .5 -d 24h{noformat}
> It appears our results don't time out at the requested server time either:
>
> {noformat}
> Writes Reads
> Deletes Errors
> Count Latency (p99) 1min (req/s) | Count Latency (p99) 1min (req/s) |
> Count Latency (p99) 1min (req/s) | Count 1min (errors/s)
> 950286 70403.93 634.77 | 789524 70442.07 426.02 |
> 0 0 0 | 9580484 18980.45
> 952304 70567.62 640.1 | 791072 70634.34 428.36 |
> 0 0 0 | 9636658 18969.54
> 953146 70767.34 640.1 | 791400 70767.76 428.36 |
> 0 0 0 | 9695272 18969.54
> 956833 71171.28 623.14 | 794009 71175.6 412.79 |
> 0 0 0 | 9749377 19002.44
> 959627 71312.58 656.93 | 795703 71349.87 435.56 |
> 0 0 0 | 9804907 18943.11{noformat}
>
> After stopping the load test altogether, it took nearly a minute before the
> requests were no longer queued.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19633) Replaced node is stuck in a loop calculating ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-19633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846027#comment-17846027
]
Jai Bheemsen Rao Dhanwada commented on CASSANDRA-19633:
---
This looks to be due to the optimization done in
[CASSANDRA-4650|https://issues.apache.org/jira/browse/CASSANDRA-4650]
> Replaced node is stuck in a loop calculating ranges
> ---
>
> Key: CASSANDRA-19633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19633
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jai Bheemsen Rao Dhanwada
>Priority: Normal
> Labels: Bootstrap
> Attachments: result1.html
>
>
> Hello,
>
> I am running into an issue where in a node that is replacing a dead
> (non-seed) node is stuck in calculating ranges forever. It eventually
> succeeds, however the time taken for calculating the ranges is not constant.
> I do sometimes see that it takes 24 hours to calculate ranges for each
> keyspace. Attached the flume graph of the cassandra process during this time,
> which points to the below code.
> {code:java}
> Multimap>
> getRangeFetchMapForNonTrivialRanges()
> {
> //Get the graph with edges between ranges and their source endpoints
> MutableCapacityGraph graph = getGraph();
> //Add source and destination vertex and edges
> addSourceAndDestination(graph, getDestinationLinkCapacity(graph));
> int flow = 0;
> MaximumFlowAlgorithmResult> result =
> null;
> //We might not be working on all ranges
> while (flow < getTotalRangeVertices(graph))
> {
> if (flow > 0)
> { //We could not find a path with previous graph. Bump the capacity b/w
> endpoint vertices and destination by 1 incrementCapacity(graph, 1); }
> MaximumFlowAlgorithm fordFulkerson =
> FordFulkersonAlgorithm.getInstance(DFSPathFinder.getInstance());
> result = fordFulkerson.calc(graph, sourceVertex, destinationVertex,
> IntegerNumberSystem.getInstance());
> int newFlow = result.calcTotalFlow();
> assert newFlow > flow; //We are not making progress which should not happen
> flow = newFlow;
> }
> return getRangeFetchMapFromGraphResult(graph, result);
> }
> {code}
> Digging through the logs, I see the below log line for a given keyspace
> `system_auth`
> {code:java}
> INFO [main] 2024-05-10 17:35:02,489 RangeStreamer.java:330 - Bootstrap: range
> Full(/10.135.56.214:7000,(5080189126057290696,5081324396311791613]) exists on
> Full(/10.135.56.157:7000,(5080189126057290696,5081324396311791613]) for
> keyspace system_auth{code}
> corresponding code:
> {code:java}
> for (Map.Entry entry : fetchMap.flattenEntries())
> logger.info("{}: range {} exists on {} for keyspace {}", description,
> entry.getKey(), entry.getValue(), keyspaceName);{code}
> BUT do not see the below line for the corresponding keyspace
> {code:java}
> RangeStreamer.java:606 - Output from RangeFetchMapCalculator for
> keyspace{code}
> this means the code it's stuck in `getRangeFetchMap();`
> {code:java}
> Multimap> rangeFetchMapMap =
> calculator.getRangeFetchMap();
> logger.info("Output from RangeFetchMapCalculator for keyspace {}",
> keyspace);{code}
> Here is the cluster topology:
> * Cassandra version: 4.0.12
> * # of nodes: 190
> * Tokens (vnodes): 128
> Initial hypothesis was that the graph calculation was taking longer due to
> the combination of nodes + tokens + tables but in the same cluster I see one
> of the node joined without any issues.
> wondering if I am hitting a bug causing it to work sometimes but get into an
> infinite loop some times?
> Please let me know if you need any other details and appreciate any pointers
> to debug this further.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19335: - Status: Review In Progress (was: Changes Suggested) > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19335: - Status: Needs Committer (was: Review In Progress) > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846013#comment-17846013 ] Brandon Williams commented on CASSANDRA-19335: -- None of the failures are related to this patch, +1 from me. > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16717) The fetching strategy can be optimized for CL.ONE and CL.LOCAL_ONE
[
https://issues.apache.org/jira/browse/CASSANDRA-16717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846006#comment-17846006
]
Jeremiah Jordan commented on CASSANDRA-16717:
-
It’s not just about resolving multiple nodes, it is also about knowing if the
row exists on the current node such that you are returning null (row exists,
column does not) or returning nothing (row does not exist).
There should be ways to better optimize the ONE case that only queries some
columns, but it’s definitely not as simple as just setting the column filter.
> The fetching strategy can be optimized for CL.ONE and CL.LOCAL_ONE
> --
>
> Key: CASSANDRA-16717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16717
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> The current {{ColumnFilter}} fetching strategy has been implemented in order
> to guaranty the CQL semantics around empty vs non-existing rows. It has also
> some importance regarding read-repair (CASSANDRA-16710). Nevertheless, reads
> at {{CL.ONE}} and at {{CL.LOCAL_ONE}} do not use read-repair and do not
> require more columns than the queried ones as those cannot be deleted by
> column deletions present on other nodes. By consequence, having
> {{ColumnFilter}} fetching only the queried columns should improve query
> speed, by reducing the number of SSTable reads for queries fetching specific
> rows and reducing the amound of data serialized and transfered between nodes
> (if the data is not local).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845986#comment-17845986
]
Brandon Williams commented on CASSANDRA-19498:
--
TopPartitionsTest testServiceTopPartitionsSingleTable is CASSANDRA-17798
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845985#comment-17845985
]
Brad Schoening commented on CASSANDRA-19498:
[~smiklosovic] junit TopPartitionsTest wouldn't be using CQLSH, I assume?
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845957#comment-17845957 ] Brandon Williams edited comment on CASSANDRA-19335 at 5/13/24 2:55 PM: --- bq. which utilizes the "raw" or "no-human-readable" output option I see the short flag came in handy! :) This looks good to me, let's see how it fares in CI: ||Branch||CI|| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19335-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1630/workflows/0be4de5e-2879-4c15-827e-b709bb58b4a0], [j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1630/workflows/09bd2a1d-e3a3-4ec1-a6b4-19cdff50307d]| was (Author: brandon.williams): bq. which utilizes the "raw" or "no-human-readable" output option I see the short flag came in handy! :) This looks good to me, let's see how it fares in CI: ||Branch||CI|| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19335-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1628/workflows/91587415-6150-47cd-9612-2c3ea48ea953], [j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1628/workflows/8bf28bd5-efb1-436c-935d-c1eeea5165d3]| > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845960#comment-17845960
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
[CASSANDRA-19498-4.1|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19498-4.1]
{noformat}
java11_pre-commit_tests
✓ j11_build 2m 0s
✓ j11_cqlsh_dtests_py3 5m 50s
✓ j11_cqlsh_dtests_py311 5m 42s
✓ j11_cqlsh_dtests_py311_vnode 5m 58s
✓ j11_cqlsh_dtests_py385m 36s
✓ j11_cqlsh_dtests_py38_vnode 6m 1s
✓ j11_cqlsh_dtests_py3_vnode 6m 10s
✓ j11_cqlshlib_cython_tests 8m 4s
✓ j11_cqlshlib_tests 6m 28s
✓ j11_dtests 35m 12s
✓ j11_dtests_vnode37m 47s
✓ j11_jvm_dtests 19m 30s
✓ j11_jvm_dtests_vnode11m 50s
✕ j11_unit_tests 7m 30s
org.apache.cassandra.tools.TopPartitionsTest
testServiceTopPartitionsSingleTable
org.apache.cassandra.cql3.MemtableSizeTest testSize[skiplist]
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4300/workflows/47cb43ab-a92d-41e0-8ed7-6a45da454d23]
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845957#comment-17845957 ] Brandon Williams commented on CASSANDRA-19335: -- bq. which utilizes the "raw" or "no-human-readable" output option I see the short flag came in handy! :) This looks good to me, let's see how it fares in CI: ||Branch||CI|| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19335-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1628/workflows/91587415-6150-47cd-9612-2c3ea48ea953], [j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1628/workflows/8bf28bd5-efb1-436c-935d-c1eeea5165d3]| > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845934#comment-17845934 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/13/24 1:57 PM: So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Plus we are not going to deprecate it in 5.0.x either. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. Having two rules at the same time leads to kind of inconsistency / unexpected behavior. If we have ddl_enabled, it will, functionally, shadow alter_table_enabled. If the former is disabled but the latter is enabled, we can not alter tables which I find rather confusing for a user. I think there is no such case yet which would behave similarly. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. was (Author: smiklosovic): So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Plus we are not going to deprecate it in 5.0.x either. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19134) Avoid flushing on every append in the LocalLog
[ https://issues.apache.org/jira/browse/CASSANDRA-19134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov reassigned CASSANDRA-19134: --- Assignee: Aleksey Yeschenko (was: Alex Petrov) > Avoid flushing on every append in the LocalLog > -- > > Key: CASSANDRA-19134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19134 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Marcus Eriksson >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 5.1-alpha1 > > > Right now, we are performing flush on every transformation that is appended > to the local log. While this does make _some_ sense, it may not be what we > always want to do. We have initially added this flush as a way to remedy node > bounces following schema changes, but this should no longer be necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19592) Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
[ https://issues.apache.org/jira/browse/CASSANDRA-19592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845935#comment-17845935 ] Alex Petrov commented on CASSANDRA-19592: - Updated the patch with comments from Sam, Marcus, and Stefan > Expand CREATE TABLE CQL on a coordinating node before submitting to CMS > --- > > Key: CASSANDRA-19592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19592 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Attachments: ci_summary.html > > > This is done to unblock CASSANDRA-12937 and allow preserving defaults with > which the table was created between node bounces and between nodes with > different configurations. For now, we are preserving 5.0 behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845934#comment-17845934 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/13/24 1:55 PM: So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Plus we are not going to deprecate it in 5.0.x either. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. was (Author: smiklosovic): So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845934#comment-17845934 ] Stefan Miklosovic commented on CASSANDRA-19556: --- So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19534) unbounded queues in native transport requests lead to node instability
[
https://issues.apache.org/jira/browse/CASSANDRA-19534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845930#comment-17845930
]
Alex Petrov commented on CASSANDRA-19534:
-
Pushed a new commit that should address your comments [~maedhroz]
> unbounded queues in native transport requests lead to node instability
> --
>
> Key: CASSANDRA-19534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19534
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Jon Haddad
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Attachments: Scenario 1 - QUEUE + Backpressure.jpg, Scenario 1 -
> QUEUE.jpg, Scenario 1 - Stock.jpg, Scenario 2 - QUEUE + Backpressure.jpg,
> Scenario 2 - QUEUE.jpg, Scenario 2 - Stock.jpg, ci_summary.html,
> image-2024-05-03-16-08-10-101.png, screenshot-1.png, screenshot-2.png,
> screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png,
> screenshot-7.png, screenshot-8.png, screenshot-9.png
>
> Time Spent: 9h
> Remaining Estimate: 0h
>
> When a node is under pressure, hundreds of thousands of requests can show up
> in the native transport queue, and it looks like it can take way longer to
> timeout than is configured. We should be shedding load much more
> aggressively and use a bounded queue for incoming work. This is extremely
> evident when we combine a resource consuming workload with a smaller one:
> Running 5.0 HEAD on a single node as of today:
> {noformat}
> # populate only
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --maxrlat 100 --populate
> 10m --rate 50k -n 1
> # workload 1 - larger reads
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --rate 200 -d 1d
> # second workload - small reads
> easy-cass-stress run KeyValue -p 1m --rate 20k -r .5 -d 24h{noformat}
> It appears our results don't time out at the requested server time either:
>
> {noformat}
> Writes Reads
> Deletes Errors
> Count Latency (p99) 1min (req/s) | Count Latency (p99) 1min (req/s) |
> Count Latency (p99) 1min (req/s) | Count 1min (errors/s)
> 950286 70403.93 634.77 | 789524 70442.07 426.02 |
> 0 0 0 | 9580484 18980.45
> 952304 70567.62 640.1 | 791072 70634.34 428.36 |
> 0 0 0 | 9636658 18969.54
> 953146 70767.34 640.1 | 791400 70767.76 428.36 |
> 0 0 0 | 9695272 18969.54
> 956833 71171.28 623.14 | 794009 71175.6 412.79 |
> 0 0 0 | 9749377 19002.44
> 959627 71312.58 656.93 | 795703 71349.87 435.56 |
> 0 0 0 | 9804907 18943.11{noformat}
>
> After stopping the load test altogether, it took nearly a minute before the
> requests were no longer queued.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19534) unbounded queues in native transport requests lead to node instability
[
https://issues.apache.org/jira/browse/CASSANDRA-19534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845930#comment-17845930
]
Alex Petrov edited comment on CASSANDRA-19534 at 5/13/24 1:47 PM:
--
[~maedhroz] thank you for the review!
Pushed a new commit that should address your comments.
was (Author: ifesdjeen):
Pushed a new commit that should address your comments [~maedhroz]
> unbounded queues in native transport requests lead to node instability
> --
>
> Key: CASSANDRA-19534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19534
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Jon Haddad
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Attachments: Scenario 1 - QUEUE + Backpressure.jpg, Scenario 1 -
> QUEUE.jpg, Scenario 1 - Stock.jpg, Scenario 2 - QUEUE + Backpressure.jpg,
> Scenario 2 - QUEUE.jpg, Scenario 2 - Stock.jpg, ci_summary.html,
> image-2024-05-03-16-08-10-101.png, screenshot-1.png, screenshot-2.png,
> screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png,
> screenshot-7.png, screenshot-8.png, screenshot-9.png
>
> Time Spent: 9h
> Remaining Estimate: 0h
>
> When a node is under pressure, hundreds of thousands of requests can show up
> in the native transport queue, and it looks like it can take way longer to
> timeout than is configured. We should be shedding load much more
> aggressively and use a bounded queue for incoming work. This is extremely
> evident when we combine a resource consuming workload with a smaller one:
> Running 5.0 HEAD on a single node as of today:
> {noformat}
> # populate only
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --maxrlat 100 --populate
> 10m --rate 50k -n 1
> # workload 1 - larger reads
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --rate 200 -d 1d
> # second workload - small reads
> easy-cass-stress run KeyValue -p 1m --rate 20k -r .5 -d 24h{noformat}
> It appears our results don't time out at the requested server time either:
>
> {noformat}
> Writes Reads
> Deletes Errors
> Count Latency (p99) 1min (req/s) | Count Latency (p99) 1min (req/s) |
> Count Latency (p99) 1min (req/s) | Count 1min (errors/s)
> 950286 70403.93 634.77 | 789524 70442.07 426.02 |
> 0 0 0 | 9580484 18980.45
> 952304 70567.62 640.1 | 791072 70634.34 428.36 |
> 0 0 0 | 9636658 18969.54
> 953146 70767.34 640.1 | 791400 70767.76 428.36 |
> 0 0 0 | 9695272 18969.54
> 956833 71171.28 623.14 | 794009 71175.6 412.79 |
> 0 0 0 | 9749377 19002.44
> 959627 71312.58 656.93 | 795703 71349.87 435.56 |
> 0 0 0 | 9804907 18943.11{noformat}
>
> After stopping the load test altogether, it took nearly a minute before the
> requests were no longer queued.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[
https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845918#comment-17845918
]
Josh McKenzie commented on CASSANDRA-19556:
---
{quote}where Josh said that he would make an exception
{quote}
For the record, I'm one voice among {_}many{_}. That said, lazy consensus is a
thing. Looks like [~mck] would prefer it in 5.0.1 vs. this late in the release
cycle. Personally I hold a pretty strong opinion we shouldn't deprecate
features or guardrails in point releases and those kinds of changes need to
happen in a major.
So as I said before and indicated on the ML, I'm ambivalent. I think we'd be
fine with individual guardrails for each group of DDL in our next major, and we
could even create a superset guardrail (as we have on the ticket here) that
effectively overrides all of them to keep backwards compatibility.
> Add guardrail to block DDL/DCL queries and replace alter_table_enabled
> guardrail
>
>
> Key: CASSANDRA-19556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19556
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Yuqi Yan
>Assignee: Yuqi Yan
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Sometimes we want to block DDL/DCL queries to stop new schemas being created
> or roles created. (e.g. when doing live-upgrade)
> For DDL guardrail current implementation won't block the query if it's no-op
> (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The
> guardrail check is added in apply() right after all the existence check)
> I don't have preference on either block every DDL query or check whether if
> it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS..
> at startup, which is no-op but will be blocked by this guardrail and failed
> to start.
>
> 4.1 PR: [https://github.com/apache/cassandra/pull/3248]
> trunk PR: [https://github.com/apache/cassandra/pull/3275]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Fix Version/s: 5.0.x
(was: 5.0-rc)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Fix Version/s: 5.0-rc
(was: 5.0.x)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Summary: support legacy [plain_text_auth] section in credentials file
removed unintentionally (was: support legacy [plain_text_auth] in credentials
file)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845890#comment-17845890
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
I am starting the builds. I also tweaked the wording around docs a little bit
etc ...
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Description:
The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
however, it is immediately ignored.
[https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
{code:java}
if not options.username:
credentials = configparser.ConfigParser()
if options.credentials is not None:
credentials.read(options.credentials) # use the username
from credentials file but fallback to cqlshrc if username is absent from the
command line parameters
options.username = username_from_cqlshrc if not options.password:
rawcredentials = configparser.RawConfigParser()
if options.credentials is not None:
rawcredentials.read(options.credentials) # handling password
in the same way as username, priority cli > credentials > cqlshrc
options.password = option_with_default(rawcredentials.get,
'plain_text_auth', 'password', password_from_cqlshrc)
options.password = password_from_cqlshrc{code}
These corrections have been made in accordance with
https://issues.apache.org/jira/browse/CASSANDRA-16983 and
https://issues.apache.org/jira/browse/CASSANDRA-16456.
The documentation does not indicate that AuthProviders can be used in the
cqlshrc and credentials files.
I propose to return the ability to use the legacy option of specifying the user
and password in the credentials file in the [plain_text_auth] section.
It is also required to describe the rules for using the credentials file in the
documentation.
I can make a corresponding pull request.
EDIT by Stefan Miklosovic:
specifying username and password in credentials file works, it is just that
[plain_text_auth] section does not work in credentials file anymore. This was
working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
tickets were firstly introduced in 4.1.0 (for the public). I do not think that
it was ever an intention to stop to support that when CASSANDRA-16456 was
merged and it was most probably just overlooked.
was:
The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
however, it is immediately ignored.
[https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
{code:java}
if not options.username:
credentials = configparser.ConfigParser()
if options.credentials is not None:
credentials.read(options.credentials) # use the username
from credentials file but fallback to cqlshrc if username is absent from the
command line parameters
options.username = username_from_cqlshrc if not options.password:
rawcredentials = configparser.RawConfigParser()
if options.credentials is not None:
rawcredentials.read(options.credentials) # handling password
in the same way as username, priority cli > credentials > cqlshrc
options.password = option_with_default(rawcredentials.get,
'plain_text_auth', 'password', password_from_cqlshrc)
options.password = password_from_cqlshrc{code}
These corrections have been made in accordance with
https://issues.apache.org/jira/browse/CASSANDRA-16983 and
https://issues.apache.org/jira/browse/CASSANDRA-16456.
The documentation does not indicate that AuthProviders can be used in the
cqlshrc and credentials files.
I propose to return the ability to use the legacy option of specifying the user
and password in the credentials file in the [plain_text_auth] section.
It is also required to describe the rules for using the credentials file in the
documentation.
I can make a corresponding pull request.
EDIT:
specifying username and password in credentials file works, it is just that
[plain_text_auth] section does not work in credentials file anymore. This was
working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
tickets were firstly introduced in 4.1.0 (for the public). I do not think that
it was ever an intention to stop to support that when CASSANDRA-16456 was
merged and it was most probably just overlooked.
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Reviewers: Brad Schoening, Stefan Miklosovic, Stefan Miklosovic (was: Brad
Schoening, Stefan Miklosovic)
Brad Schoening, Stefan Miklosovic, Stefan Miklosovic (was: Brad
Schoening, Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Description:
The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
however, it is immediately ignored.
[https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
{code:java}
if not options.username:
credentials = configparser.ConfigParser()
if options.credentials is not None:
credentials.read(options.credentials) # use the username
from credentials file but fallback to cqlshrc if username is absent from the
command line parameters
options.username = username_from_cqlshrc if not options.password:
rawcredentials = configparser.RawConfigParser()
if options.credentials is not None:
rawcredentials.read(options.credentials) # handling password
in the same way as username, priority cli > credentials > cqlshrc
options.password = option_with_default(rawcredentials.get,
'plain_text_auth', 'password', password_from_cqlshrc)
options.password = password_from_cqlshrc{code}
These corrections have been made in accordance with
https://issues.apache.org/jira/browse/CASSANDRA-16983 and
https://issues.apache.org/jira/browse/CASSANDRA-16456.
The documentation does not indicate that AuthProviders can be used in the
cqlshrc and credentials files.
I propose to return the ability to use the legacy option of specifying the user
and password in the credentials file in the [plain_text_auth] section.
It is also required to describe the rules for using the credentials file in the
documentation.
I can make a corresponding pull request.
EDIT:
specifying username and password in credentials file works, it is just that
[plain_text_auth] section does not work in credentials file anymore. This was
working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
tickets were firstly introduced in 4.1.0 (for the public). I do not think that
it was ever an intention to stop to support that when CASSANDRA-16456 was
merged and it was most probably just overlooked.
was:
The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
however, it is immediately ignored.
https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070
{code:java}
if not options.username:
credentials = configparser.ConfigParser()
if options.credentials is not None:
credentials.read(options.credentials) # use the username
from credentials file but fallback to cqlshrc if username is absent from the
command line parameters
options.username = username_from_cqlshrc if not options.password:
rawcredentials = configparser.RawConfigParser()
if options.credentials is not None:
rawcredentials.read(options.credentials) # handling password
in the same way as username, priority cli > credentials > cqlshrc
options.password = option_with_default(rawcredentials.get,
'plain_text_auth', 'password', password_from_cqlshrc)
options.password = password_from_cqlshrc{code}
These corrections have been made in accordance with
https://issues.apache.org/jira/browse/CASSANDRA-16983 and
https://issues.apache.org/jira/browse/CASSANDRA-16456.
The documentation does not indicate that AuthProviders can be used in the
cqlshrc and credentials files.
I propose to return the ability to use the legacy option of specifying the user
and password in the credentials file in the [plain_text_auth] section.
It is also required to describe the rules for using the credentials file in the
documentation.
I can make a corresponding pull request.
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
>
[jira] [Assigned] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic reassigned CASSANDRA-19498:
-
Assignee: Stefan Miklosovic
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Summary: support legacy [plain_text_auth] in credentials file (was: Error
reading data from credential file)
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845839#comment-17845839
]
Stefan Miklosovic commented on CASSANDRA-18322:
---
Thanks for the approval on the PR, [~blerer] . I think we will get to this
post-5.0 again.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19604:
---
Test and Documentation Plan: The patch add unit tests that cover the new
functionality.
Status: Patch Available (was: In Progress)
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
