[jira] [Commented] (CASSANDRA-16782) Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window
[ https://issues.apache.org/jira/browse/CASSANDRA-16782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378350#comment-17378350 ] Aleksei Zotov commented on CASSANDRA-16782: --- Hi [~marcuse] I checked the code and put a few comments to [https://github.com/krummas/cassandra/commit/5736260cc0095b64101ba05d5d7f2cdd9bd7aff9]. Please, let me know your thoughts. I'm apologizing in advance if some comments make no sense to you :) PS: I'm trying to follow Benjamin's call seeking for reviewers. Definitely a non-committer review does not let it be merged, but I hope it is still useful. > Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window > > > Key: CASSANDRA-16782 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16782 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction/LCS, Local/Compaction/TWCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > The goal when being behind in L0 should always be to get the number of > sstables down to a reasonable level as soon as possible. Currently it is > common that we run compactions on the large sstables but leave thousands of > tiny sstables behind. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16770) Avoid sending cdc column in serialization header to 3.0 nodes
[ https://issues.apache.org/jira/browse/CASSANDRA-16770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378351#comment-17378351 ] Aleksei Zotov commented on CASSANDRA-16770: --- Hi [~marcuse] I checked the change, it looks good and clear to me. The only question: is there a way to write tests for this fix? I feel we can either cover _convertSchemaToMutations_ method with tests or make _makeUpdateForSchema_ method package private and then cover with tests. > Avoid sending cdc column in serialization header to 3.0 nodes > - > > Key: CASSANDRA-16770 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16770 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.11.x > > > We try to not send the cdc column to any 3.0 nodes, but it is still there in > the SerializationHeader -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16776) modify SecondaryIndexManager#indexPartition() to retrieve only columns for which indexes are actually being built
[
https://issues.apache.org/jira/browse/CASSANDRA-16776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378348#comment-17378348
]
Caleb Rackliffe commented on CASSANDRA-16776:
-
Thanks [~azotcsit]. Definitely appreciated!
> modify SecondaryIndexManager#indexPartition() to retrieve only columns for
> which indexes are actually being built
> -
>
> Key: CASSANDRA-16776
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16776
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Attachments: index1.png, index2.png
>
>
> Secondary indexes are (for the moment) built as special compaction tasks via
> {{SecondaryIndexBuilder}}. From a profiling perspective, the fun begins in
> {{SecondaryIndexManager.indexPartition()}}. The work above it in
> {{SecondaryIndexBuilder}} is just key iteration.
> !index1.png!
> Two basic things happen in {{indexPartition()}}. First, we read a single
> partition in its entirety, and then we send individual rows to the
> {{Indexer}}. When we read these partitions, we use {{ColumnFilter.all()}},
> which ends up materializing full rows, even when we’re indexing a single
> column (or at least fewer columns than we need for all the indexes
> participating in the build). If we narrowed this to fetch only the necessary
> columns, we might be able to create less garbage in
> {{AbstractBTreePartition#searchIterator()}} when we create a copy of the
> underlying full row from disk.
> In some initial testing, I’ve been using a simple schema with fairly narrow
> rows.
> {noformat}
> CREATE TABLE tlp_stress.allow_filtering (
> partition_id text,
> row_id int,
> payload text,
> value int,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> {noformat}
> The price of deserializing these rows is still visible, however, in the
> results of some basic sampling profiling.
> !index2.png!
> The possible optimization above to avoid unnecessary copying of a row’s
> columns would also narrow cell deserialization only to indexed cells, which
> would probably be very beneficial for index builds with very wide rows. One
> minor wrinkle in all of this is that since 3.0, it has been possible to
> create indexes one entire rows, rather than single columns, so we’d have to
> keep that case in mind.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16776) modify SecondaryIndexManager#indexPartition() to retrieve only columns for which indexes are actually being built
[
https://issues.apache.org/jira/browse/CASSANDRA-16776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16776:
Reviewers: Aleksei Zotov
> modify SecondaryIndexManager#indexPartition() to retrieve only columns for
> which indexes are actually being built
> -
>
> Key: CASSANDRA-16776
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16776
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Attachments: index1.png, index2.png
>
>
> Secondary indexes are (for the moment) built as special compaction tasks via
> {{SecondaryIndexBuilder}}. From a profiling perspective, the fun begins in
> {{SecondaryIndexManager.indexPartition()}}. The work above it in
> {{SecondaryIndexBuilder}} is just key iteration.
> !index1.png!
> Two basic things happen in {{indexPartition()}}. First, we read a single
> partition in its entirety, and then we send individual rows to the
> {{Indexer}}. When we read these partitions, we use {{ColumnFilter.all()}},
> which ends up materializing full rows, even when we’re indexing a single
> column (or at least fewer columns than we need for all the indexes
> participating in the build). If we narrowed this to fetch only the necessary
> columns, we might be able to create less garbage in
> {{AbstractBTreePartition#searchIterator()}} when we create a copy of the
> underlying full row from disk.
> In some initial testing, I’ve been using a simple schema with fairly narrow
> rows.
> {noformat}
> CREATE TABLE tlp_stress.allow_filtering (
> partition_id text,
> row_id int,
> payload text,
> value int,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> {noformat}
> The price of deserializing these rows is still visible, however, in the
> results of some basic sampling profiling.
> !index2.png!
> The possible optimization above to avoid unnecessary copying of a row’s
> columns would also narrow cell deserialization only to indexed cells, which
> would probably be very beneficial for index builds with very wide rows. One
> minor wrinkle in all of this is that since 3.0, it has been possible to
> create indexes one entire rows, rather than single columns, so we’d have to
> keep that case in mind.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16725) Implement nodetool getauditlog command
[ https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378326#comment-17378326 ] Ekaterina Dimitrova commented on CASSANDRA-16725: - I rebased the branch and pushed Jenkins CI run: [patch |https://github.com/ekaterinadimitrova2/cassandra/commits/CASSANDRA-16725-review] | [CI |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/916/] > Implement nodetool getauditlog command > -- > > Key: CASSANDRA-16725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16725 > Project: Cassandra > Issue Type: New Feature > Components: Tool/auditlogging >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is getfullquerylog already, there is not any reason why getauditlog > should not be there too. A user can not retrieve runtime configuration of > Audit log, it might be only enabled and disabled via jmx but its state can > not be queried in runtime. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16725) Implement nodetool getauditlog command
[ https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16725: Status: Review In Progress (was: Patch Available) > Implement nodetool getauditlog command > -- > > Key: CASSANDRA-16725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16725 > Project: Cassandra > Issue Type: New Feature > Components: Tool/auditlogging >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is getfullquerylog already, there is not any reason why getauditlog > should not be there too. A user can not retrieve runtime configuration of > Audit log, it might be only enabled and disabled via jmx but its state can > not be queried in runtime. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16776) modify SecondaryIndexManager#indexPartition() to retrieve only columns for which indexes are actually being built
[
https://issues.apache.org/jira/browse/CASSANDRA-16776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378319#comment-17378319
]
Aleksei Zotov edited comment on CASSANDRA-16776 at 7/9/21, 9:44 PM:
Hi [~maedhroz]
I checked the PR and the code looks good to me (I put a couple of minor
comments). I'm definitely not an expert in that part of code, but logically
your changes are clear and make perfect sense to me.
PS:
I'm trying to follow Benjamin's call seeking for reviewers. Definitely a
non-committer review does not let it be merged, but I hope it is still useful.
was (Author: azotcsit):
Hi [~maedhroz]
I checked the PR and the code looks good to me. I'm definitely not an expert in
that part of code, but logically your changes are clear and make perfect sense
to me.
PS:
I'm trying to follow Benjamin's call seeking for reviewers. Definitely a
non-committer review does not let it be merged, but I hope it is still useful.
> modify SecondaryIndexManager#indexPartition() to retrieve only columns for
> which indexes are actually being built
> -
>
> Key: CASSANDRA-16776
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16776
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Attachments: index1.png, index2.png
>
>
> Secondary indexes are (for the moment) built as special compaction tasks via
> {{SecondaryIndexBuilder}}. From a profiling perspective, the fun begins in
> {{SecondaryIndexManager.indexPartition()}}. The work above it in
> {{SecondaryIndexBuilder}} is just key iteration.
> !index1.png!
> Two basic things happen in {{indexPartition()}}. First, we read a single
> partition in its entirety, and then we send individual rows to the
> {{Indexer}}. When we read these partitions, we use {{ColumnFilter.all()}},
> which ends up materializing full rows, even when we’re indexing a single
> column (or at least fewer columns than we need for all the indexes
> participating in the build). If we narrowed this to fetch only the necessary
> columns, we might be able to create less garbage in
> {{AbstractBTreePartition#searchIterator()}} when we create a copy of the
> underlying full row from disk.
> In some initial testing, I’ve been using a simple schema with fairly narrow
> rows.
> {noformat}
> CREATE TABLE tlp_stress.allow_filtering (
> partition_id text,
> row_id int,
> payload text,
> value int,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> {noformat}
> The price of deserializing these rows is still visible, however, in the
> results of some basic sampling profiling.
> !index2.png!
> The possible optimization above to avoid unnecessary copying of a row’s
> columns would also narrow cell deserialization only to indexed cells, which
> would probably be very beneficial for index builds with very wide rows. One
> minor wrinkle in all of this is that since 3.0, it has been possible to
> create indexes one entire rows, rather than single columns, so we’d have to
> keep that case in mind.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16776) modify SecondaryIndexManager#indexPartition() to retrieve only columns for which indexes are actually being built
[
https://issues.apache.org/jira/browse/CASSANDRA-16776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378319#comment-17378319
]
Aleksei Zotov commented on CASSANDRA-16776:
---
Hi [~maedhroz]
I checked the PR and the code looks good to me. I'm definitely not an expert in
that part of code, but logically your changes are clear and make perfect sense
to me.
PS:
I'm trying to follow Benjamin's call seeking for reviewers. Definitely a
non-committer review does not let it be merged, but I hope it is still useful.
> modify SecondaryIndexManager#indexPartition() to retrieve only columns for
> which indexes are actually being built
> -
>
> Key: CASSANDRA-16776
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16776
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Attachments: index1.png, index2.png
>
>
> Secondary indexes are (for the moment) built as special compaction tasks via
> {{SecondaryIndexBuilder}}. From a profiling perspective, the fun begins in
> {{SecondaryIndexManager.indexPartition()}}. The work above it in
> {{SecondaryIndexBuilder}} is just key iteration.
> !index1.png!
> Two basic things happen in {{indexPartition()}}. First, we read a single
> partition in its entirety, and then we send individual rows to the
> {{Indexer}}. When we read these partitions, we use {{ColumnFilter.all()}},
> which ends up materializing full rows, even when we’re indexing a single
> column (or at least fewer columns than we need for all the indexes
> participating in the build). If we narrowed this to fetch only the necessary
> columns, we might be able to create less garbage in
> {{AbstractBTreePartition#searchIterator()}} when we create a copy of the
> underlying full row from disk.
> In some initial testing, I’ve been using a simple schema with fairly narrow
> rows.
> {noformat}
> CREATE TABLE tlp_stress.allow_filtering (
> partition_id text,
> row_id int,
> payload text,
> value int,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> {noformat}
> The price of deserializing these rows is still visible, however, in the
> results of some basic sampling profiling.
> !index2.png!
> The possible optimization above to avoid unnecessary copying of a row’s
> columns would also narrow cell deserialization only to indexed cells, which
> would probably be very beneficial for index builds with very wide rows. One
> minor wrinkle in all of this is that since 3.0, it has been possible to
> create indexes one entire rows, rather than single columns, so we’d have to
> keep that case in mind.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.0.0-tentative deleted (was a46146f)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 4.0.0-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. *** WARNING: tag 4.0.0-tentative was deleted! *** was a46146f Prepare debian changelog for 4.0.0 The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r48756 - /dev/cassandra/4.0.0/
Author: mck Date: Fri Jul 9 18:19:05 2021 New Revision: 48756 Log: dropping dev/cassandra/4.0.0 because of CASSANDRA-16794 Removed: dev/cassandra/4.0.0/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15663:
Reviewers: Andres de la Peña, Ekaterina Dimitrova, Ekaterina Dimitrova
(was: Andres de la Peña, Ekaterina Dimitrova)
Andres de la Peña, Ekaterina Dimitrova, Ekaterina Dimitrova
(was: Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16666) Make SSLContext creation pluggable/extensible
[ https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378107#comment-17378107 ] Stefan Miklosovic commented on CASSANDRA-1: --- I am taking it to CEP. > Make SSLContext creation pluggable/extensible > - > > Key: CASSANDRA-1 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Maulin Vasavada >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.x > > > Currently Cassandra creates the SSLContext via SSLFactory.java. SSLFactory is > a final class with static methods and not overridable. The SSLFactory loads > the keys and certs from the file based artifacts for the same. While this > works for many, in the industry where security is stricter and contextual, > this approach falls short. Many big organizations need flexibility to load > the SSL artifacts from a custom resource (like custom Key Management > Solution, HashiCorp Vault, Amazon KMS etc). While JSSE SecurityProvider > architecture allows us flexibility to build our custom mechanisms to validate > and process security artifacts, many times all we need is to build upon > Java's existing extensibility that Trust/Key Manager interfaces provide to > load keystores from various resources in the absence of any customized > requirements on the Keys/Certificate formats. > My proposal here is to make the SSLContext creation pluggable/extensible and > have the current SSLFactory.java implement an extensible interface. > I contributed a similar change that is live now in Apache Kafka (2.6.0) - > https://issues.apache.org/jira/browse/KAFKA-8890 > I can spare some time writing the pluggable interface and run by the required > reviewers. > > Created [CEP-9: Make SSLContext creation > pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable] > > > cc: [~dcapwell] [~djoshi] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378097#comment-17378097
]
Andres de la Peña commented on CASSANDRA-15663:
---
The patch with the last changes looks good to me. Running CI with the last
changes:
* 3.11:
[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/650/workflows/f8548311-fbde-4a5c-b8a1-4c3caa3a4675]
* 4.0.0:
[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/648/workflows/1587d081-bef0-4382-a38d-f3610f1c3b29]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/648/workflows/a7ba4f86-9bfd-4380-b771-e7ac9596fcc3]
* 4.0:
[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/647/workflows/43ac879b-b90a-48aa-8c22-7cf85d7992df]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/647/workflows/b9f131c2-39a3-41d6-8fe6-b11079632fc4]
* trunk:
[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/649/workflows/e1140c43-5cfc-4bef-b83a-a2dd32ac0db4]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/649/workflows/525320d2-bea6-43c1-aa3a-6bbd62e55041]
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14162) Backport 7950 (Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names)
[ https://issues.apache.org/jira/browse/CASSANDRA-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378073#comment-17378073 ] Stefan Miklosovic edited comment on CASSANDRA-14162 at 7/9/21, 1:43 PM: The backport contains yet another "feature" which is sorting of the output. This sorting was firstly introduced in 3.2 in https://issues.apache.org/jira/browse/CASSANDRA-10464 and since then it is sorted one way or the other but together with [~e.dimitrova] (thanks for spotting this) we actually think that it should not be the part of the backport as that would be the introduction of behaviour which would not address the original issue this ticket is trying to solve. Unless we agree that we may introduce sorting (either doing it directly in this ticket or creating new one just for 3.0.25), we drift towards removing sorting to be strictly just about solving the long names. However, I doubt that the introduction of sorting would be "bad". It only improve the user experience and I can not see any reason why a user would be suddenly "confused and angry" that we started to sort it for him since 3.0.25. The commit which deletes sorting is here: https://github.com/apache/cassandra/pull/1103/commits/415a029657fe9a3873cdd256d43fe2e9ca8be384 was (Author: stefan.miklosovic): The backport contains yet another "feature" which is sorting of the output. This sorting was firstly introduced in 3.2 in https://issues.apache.org/jira/browse/CASSANDRA-10464 and since then it is sorted one way or the other but together with [~e.dimitrova] (thanks for spotting this) we actually think that it should not be the part of the backport as that would be the introduction of behaviour which would not address the original issue this ticket is trying to solve. Unless we agree that we may introduce sorting (either doing it directly in this ticket or creating new one just for 3.0.25), we drift towards removing sorting to be strictly just about solving the long names. However, I doubt that the introduction of sorting would be "bad". It only improve the user experience and I can not see any reason why a user would be suddenly "confused and angry" that we started to sort it for him since 3.0.25. > Backport 7950 (Output of nodetool compactionstats and compactionhistory does > not work well with long keyspace and column family names) > -- > > Key: CASSANDRA-14162 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14162 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Kurt Greaves >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 3.0.25 > > Attachments: 14162-3.0.patch, Screenshot from 2018-01-11 > 01-02-02.png, Screenshot from 2018-01-11 01-02-46.png, Screenshot from > 2018-01-11 01-02-51.png > > > Colleagues have had issues with output of listsnapshots/compactionstats > because of things with really long names. Mostly cosmetic but I see no reason > we shouldn't backport CASSANDRA-7950 to 3.0. It's practically a bugfix. I've > attached a patch and a bunch of images to show the relevant commands working > as intended after applying the patch. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14162) Backport 7950 (Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names)
[ https://issues.apache.org/jira/browse/CASSANDRA-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378073#comment-17378073 ] Stefan Miklosovic commented on CASSANDRA-14162: --- The backport contains yet another "feature" which is sorting of the output. This sorting was firstly introduced in 3.2 in https://issues.apache.org/jira/browse/CASSANDRA-10464 and since then it is sorted one way or the other but together with [~e.dimitrova] (thanks for spotting this) we actually think that it should not be the part of the backport as that would be the introduction of behaviour which would not address the original issue this ticket is trying to solve. Unless we agree that we may introduce sorting (either doing it directly in this ticket or creating new one just for 3.0.25), we drift towards removing sorting to be strictly just about solving the long names. However, I doubt that the introduction of sorting would be "bad". It only improve the user experience and I can not see any reason why a user would be suddenly "confused and angry" that we started to sort it for him since 3.0.25. > Backport 7950 (Output of nodetool compactionstats and compactionhistory does > not work well with long keyspace and column family names) > -- > > Key: CASSANDRA-14162 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14162 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: Kurt Greaves >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 3.0.25 > > Attachments: 14162-3.0.patch, Screenshot from 2018-01-11 > 01-02-02.png, Screenshot from 2018-01-11 01-02-46.png, Screenshot from > 2018-01-11 01-02-51.png > > > Colleagues have had issues with output of listsnapshots/compactionstats > because of things with really long names. Mostly cosmetic but I see no reason > we shouldn't backport CASSANDRA-7950 to 3.0. It's practically a bugfix. I've > attached a patch and a bunch of images to show the relevant commands working > as intended after applying the patch. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16789) Add TTL support to nodetool snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378026#comment-17378026
]
Paulo Motta commented on CASSANDRA-16789:
-
Thanks for your patch update, looking good so far! Added a few comments to the
PR itself and below you can find some design comments:
I noticed the manifest file is being read in two places, which violates the
don't repeat yourself principle:
* [SnapshotDetails
constructor|https://github.com/apache/cassandra/pull/1046/files#diff-ad15ce2b3f9473fd99ec3f72362497ec43599c63b8f71b509e338677eeaca41aR40]
*
[SnapshotDetailsTabularData.from|https://github.com/apache/cassandra/pull/1046/files#diff-76d6ca8149019cb3e777d971489de8ba6c20d6caee2718f638ad044f7fddc3c9R87]
Another potential issue I spotted is that
{{Directories.getSnapshotManifestFile(snapshotName)}} is being used to find the
snapshot manifest location. As [~stefan.miklosovic] mentioned in an earlier
discussion, this method is only used to write snapshots, since it will pick one
of many data directories to write the manifest file. Using this same method for
reading can be a problem when using many data directories because a different
directory can be chosen from the one the manifest was written to, so the
manifest would not be found.
I think the best place to read the manifest is on
{{Directories.getSnapshotDetails}}, since this will already go through all the
data directories and you can try to find the manifest in all data directories.
We should probably merge the class {{SnapshotSizeDetails}} into
{{SnapshotDetails}} and use this single class to represent information about a
table snapshot, and this method would return {{SnapshotDetails}} instead of
{{SnapshotSizeDetails}}.
Please let me know if this makes sense to you or if you have any questions or
concerns.
> Add TTL support to nodetool snapshots
> -
>
> Key: CASSANDRA-16789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16789
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> Add new parameter {{--ttl}} to {{nodetool snapshot}} command. This parameter
> can be specified in human readable duration (ie. 30mins, 1h, 300d) and should
> not be lower than 1 minute.
> The expiration date should be added to the snapshot manifest in ISO format.
> A periodic thread should efficiently scan snapshots and automatically clear
> those past expiration date. The periodicity of the scan thread should be 1
> minute by default but be overridable via a system property.
> The command {{nodetool listsnapshots}} should display the expiration date
> when the snapshot contains a TTL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16789) Add TTL support to nodetool snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378004#comment-17378004
]
Abuli Palagashvili commented on CASSANDRA-16789:
Nice, I've updated PR, according to your comment.It remains to add new tests.
> Add TTL support to nodetool snapshots
> -
>
> Key: CASSANDRA-16789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16789
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> Add new parameter {{--ttl}} to {{nodetool snapshot}} command. This parameter
> can be specified in human readable duration (ie. 30mins, 1h, 300d) and should
> not be lower than 1 minute.
> The expiration date should be added to the snapshot manifest in ISO format.
> A periodic thread should efficiently scan snapshots and automatically clear
> those past expiration date. The periodicity of the scan thread should be 1
> minute by default but be overridable via a system property.
> The command {{nodetool listsnapshots}} should display the expiration date
> when the snapshot contains a TTL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16794) CassandraVersion compareTo does not order SNAPSHOT versions properly
[
https://issues.apache.org/jira/browse/CASSANDRA-16794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16794:
---
Reviewers: Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever)
Michael Semb Wever, Michael Semb Wever
Status: Review In Progress (was: Patch Available)
+1
> CassandraVersion compareTo does not order SNAPSHOT versions properly
>
>
> Key: CASSANDRA-16794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16794
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CassandraVersion::compareTo}} does not order {{SNAPSHOT}} versions properly
> in several scenario.
> It return wrong results for the 2 following usecases:
> 1. {{new CassandraVersion("4.0-rc2").compareTo(("4.0.0-SNAPSHOT")}}
> 2. {{new CassandraVersion("4.0-rc2").compareTo(("4.0-rc2-SNAPSHOT")}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] tag 0.0.8 created (now db3cdf5)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 0.0.8 in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git. at db3cdf5 (commit) No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16794) CassandraVersion compareTo does not order SNAPSHOT versions properly
[
https://issues.apache.org/jira/browse/CASSANDRA-16794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16794:
---
Test and Documentation Plan: The patch add some tests to cover the failling
usecases
Status: Patch Available (was: In Progress)
> CassandraVersion compareTo does not order SNAPSHOT versions properly
>
>
> Key: CASSANDRA-16794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16794
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CassandraVersion::compareTo}} does not order {{SNAPSHOT}} versions properly
> in several scenario.
> It return wrong results for the 2 following usecases:
> 1. {{new CassandraVersion("4.0-rc2").compareTo(("4.0.0-SNAPSHOT")}}
> 2. {{new CassandraVersion("4.0-rc2").compareTo(("4.0-rc2-SNAPSHOT")}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16794) CassandraVersion compareTo does not order SNAPSHOT versions properly
[
https://issues.apache.org/jira/browse/CASSANDRA-16794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377979#comment-17377979
]
Benjamin Lerer commented on CASSANDRA-16794:
|| Branch || CI ||
| [4.0.0|https://github.com/apache/cassandra/pull/1107] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/181/workflows/417d25ae-4dcf-41e3-ae81-8b61bba9a604],
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/181/workflows/b9f4d30d-2517-4767-a5c2-df3270967c01]|
> CassandraVersion compareTo does not order SNAPSHOT versions properly
>
>
> Key: CASSANDRA-16794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16794
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CassandraVersion::compareTo}} does not order {{SNAPSHOT}} versions properly
> in several scenario.
> It return wrong results for the 2 following usecases:
> 1. {{new CassandraVersion("4.0-rc2").compareTo(("4.0.0-SNAPSHOT")}}
> 2. {{new CassandraVersion("4.0-rc2").compareTo(("4.0-rc2-SNAPSHOT")}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] branch trunk updated: [maven-release-plugin] prepare for next development iteration
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git The following commit(s) were added to refs/heads/trunk by this push: new d79953d [maven-release-plugin] prepare for next development iteration d79953d is described below commit d79953dce96651f05e0ef943dfb868c03f24f171 Author: mck AuthorDate: Fri Jul 9 12:04:08 2021 +0200 [maven-release-plugin] prepare for next development iteration --- pom.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pom.xml b/pom.xml index 0529764..24b85e4 100644 --- a/pom.xml +++ b/pom.xml @@ -27,7 +27,7 @@ 4.0.0 org.apache.cassandra dtest-api -0.0.8 +0.0.9-SNAPSHOT In JVM Test API In JVM Test API - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] annotated tag dtest-api-0.0.8 created (now 738fc42)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to annotated tag dtest-api-0.0.8 in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git. at 738fc42 (tag) tagging db3cdf5823fbc49c6b5c53dc2b15330d3883fd09 (commit) replaces 0.0.7 by mck on Fri Jul 9 12:04:02 2021 +0200 - Log - [maven-release-plugin] copy for tag dtest-api-0.0.8 --- No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] annotated tag dtest-api-0.0.8 deleted (was 389e057)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to annotated tag dtest-api-0.0.8 in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git. *** WARNING: tag dtest-api-0.0.8 was deleted! *** tag was 389e057 The revisions that were on this annotated tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16794) CassandraVersion compareTo does not order SNAPSHOT versions properly
[
https://issues.apache.org/jira/browse/CASSANDRA-16794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16794:
---
Bug Category: Parent values: Code(13163)
Complexity: Normal
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> CassandraVersion compareTo does not order SNAPSHOT versions properly
>
>
> Key: CASSANDRA-16794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16794
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc3
>
>
> {{CassandraVersion::compareTo}} does not order {{SNAPSHOT}} versions properly
> in several scenario.
> It return wrong results for the 2 following usecases:
> 1. {{new CassandraVersion("4.0-rc2").compareTo(("4.0.0-SNAPSHOT")}}
> 2. {{new CassandraVersion("4.0-rc2").compareTo(("4.0-rc2-SNAPSHOT")}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16794) CassandraVersion compareTo does not order SNAPSHOT versions properly
[
https://issues.apache.org/jira/browse/CASSANDRA-16794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16794:
---
Fix Version/s: 4.0-rc3
> CassandraVersion compareTo does not order SNAPSHOT versions properly
>
>
> Key: CASSANDRA-16794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16794
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc3
>
>
> {{CassandraVersion::compareTo}} does not order {{SNAPSHOT}} versions properly
> in several scenario.
> It return wrong results for the 2 following usecases:
> 1. {{new CassandraVersion("4.0-rc2").compareTo(("4.0.0-SNAPSHOT")}}
> 2. {{new CassandraVersion("4.0-rc2").compareTo(("4.0-rc2-SNAPSHOT")}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] branch trunk updated: [maven-release-plugin] prepare release dtest-api-0.0.8
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git The following commit(s) were added to refs/heads/trunk by this push: new db3cdf5 [maven-release-plugin] prepare release dtest-api-0.0.8 db3cdf5 is described below commit db3cdf5823fbc49c6b5c53dc2b15330d3883fd09 Author: mck AuthorDate: Fri Jul 9 11:57:57 2021 +0200 [maven-release-plugin] prepare release dtest-api-0.0.8 --- pom.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pom.xml b/pom.xml index 84268f5..0529764 100644 --- a/pom.xml +++ b/pom.xml @@ -27,7 +27,7 @@ 4.0.0 org.apache.cassandra dtest-api -0.0.9-SNAPSHOT +0.0.8 In JVM Test API In JVM Test API @@ -158,7 +158,7 @@ scm:git:https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git scm:git:https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git -HEAD +dtest-api-0.0.8 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16794) CassandraVersion compareTo does not order SNAPSHOT versions properly
[
https://issues.apache.org/jira/browse/CASSANDRA-16794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-16794:
--
Assignee: Benjamin Lerer
> CassandraVersion compareTo does not order SNAPSHOT versions properly
>
>
> Key: CASSANDRA-16794
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16794
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> {{CassandraVersion::compareTo}} does not order {{SNAPSHOT}} versions properly
> in several scenario.
> It return wrong results for the 2 following usecases:
> 1. {{new CassandraVersion("4.0-rc2").compareTo(("4.0.0-SNAPSHOT")}}
> 2. {{new CassandraVersion("4.0-rc2").compareTo(("4.0-rc2-SNAPSHOT")}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16794) CassandraVersion compareTo does not order SNAPSHOT versions properly
Benjamin Lerer created CASSANDRA-16794:
--
Summary: CassandraVersion compareTo does not order SNAPSHOT
versions properly
Key: CASSANDRA-16794
URL: https://issues.apache.org/jira/browse/CASSANDRA-16794
Project: Cassandra
Issue Type: Bug
Components: Legacy/Core
Reporter: Benjamin Lerer
{{CassandraVersion::compareTo}} does not order {{SNAPSHOT}} versions properly
in several scenario.
It return wrong results for the 2 following usecases:
1. {{new CassandraVersion("4.0-rc2").compareTo(("4.0.0-SNAPSHOT")}}
2. {{new CassandraVersion("4.0-rc2").compareTo(("4.0-rc2-SNAPSHOT")}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] branch trunk updated: [maven-release-plugin] prepare for next development iteration
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git The following commit(s) were added to refs/heads/trunk by this push: new 9ea5dee [maven-release-plugin] prepare for next development iteration 9ea5dee is described below commit 9ea5dee0a26faebc0c98d2446e76eab9054717e4 Author: mck AuthorDate: Fri Jul 9 11:43:27 2021 +0200 [maven-release-plugin] prepare for next development iteration --- pom.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pom.xml b/pom.xml index 0529764..84268f5 100644 --- a/pom.xml +++ b/pom.xml @@ -27,7 +27,7 @@ 4.0.0 org.apache.cassandra dtest-api -0.0.8 +0.0.9-SNAPSHOT In JVM Test API In JVM Test API @@ -158,7 +158,7 @@ scm:git:https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git scm:git:https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git -dtest-api-0.0.8 +HEAD - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] annotated tag dtest-api-0.0.8 created (now 389e057)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to annotated tag dtest-api-0.0.8 in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git. at 389e057 (tag) tagging 72a6c424d3833a7b983124bccefe11ee27fdaa3f (commit) replaces 0.0.7 by mck on Fri Jul 9 11:43:22 2021 +0200 - Log - [maven-release-plugin] copy for tag dtest-api-0.0.8 --- No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] branch trunk updated: [maven-release-plugin] prepare release dtest-api-0.0.8
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git The following commit(s) were added to refs/heads/trunk by this push: new 72a6c42 [maven-release-plugin] prepare release dtest-api-0.0.8 72a6c42 is described below commit 72a6c424d3833a7b983124bccefe11ee27fdaa3f Author: mck AuthorDate: Fri Jul 9 11:43:17 2021 +0200 [maven-release-plugin] prepare release dtest-api-0.0.8 --- pom.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/pom.xml b/pom.xml index bfc2d8c..0529764 100644 --- a/pom.xml +++ b/pom.xml @@ -27,7 +27,7 @@ 4.0.0 org.apache.cassandra dtest-api -0.0.8-SNAPSHOT +0.0.8 In JVM Test API In JVM Test API @@ -158,6 +158,7 @@ scm:git:https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git scm:git:https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git +dtest-api-0.0.8 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16649) Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16649: --- Source Control Link: https://github.com/apache/cassandra-in-jvm-dtest-api/commit/8b17c8dfe3fa0d062af1e861b8b204c7bbeb275b https://github.com/apache/cassandra-in-jvm-dtest-api/commit/0a13871f9dc8261b3defc1183eb4eee92d9c4f72 Committed cassandra-in-jvm-dtest-api changes as [8b17c8dfe3fa0d062af1e861b8b204c7bbeb275b|https://github.com/apache/cassandra-in-jvm-dtest-api/commit/8b17c8dfe3fa0d062af1e861b8b204c7bbeb275b] and [0a13871f9dc8261b3defc1183eb4eee92d9c4f72|https://github.com/apache/cassandra-in-jvm-dtest-api/commit/0a13871f9dc8261b3defc1183eb4eee92d9c4f72]. Cutting and raising a vote for 0.0.8 now… > Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created) > -- > > Key: CASSANDRA-16649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16649 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/java >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x > > > - > https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649 > - > https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] branch trunk updated (d5174b1 -> 0a13871)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git. from d5174b1 [maven-release-plugin] prepare for next development iteration new 8b17c8d Update Versions for trunk as 4.1 and new release branch cassandra-4.0 new 0a13871 Introduce SemVer4j for version representation, parsing and handling The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .gitignore | 1 + pom.xml| 27 +--- .../cassandra/distributed/api/IInstanceConfig.java | 5 +- .../cassandra/distributed/shared/Versions.java | 147 - .../cassandra/distributed/shared/VersionsTest.java | 97 ++ 5 files changed, 159 insertions(+), 118 deletions(-) create mode 100644 src/test/java/org/apache/cassandra/distributed/shared/VersionsTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] 02/02: Introduce SemVer4j for version representation, parsing and handling
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git
commit 0a13871f9dc8261b3defc1183eb4eee92d9c4f72
Author: mck
AuthorDate: Sat May 15 23:53:38 2021 +0200
Introduce SemVer4j for version representation, parsing and handling
patch by Mick Semb Wever; reviewed by Alex Petrov for CASSANDRA-16649
---
pom.xml| 5 +
.../cassandra/distributed/api/IInstanceConfig.java | 5 +-
.../cassandra/distributed/shared/Versions.java | 134 +++--
.../cassandra/distributed/shared/VersionsTest.java | 4 +-
4 files changed, 54 insertions(+), 94 deletions(-)
diff --git a/pom.xml b/pom.xml
index 88cb573..bfc2d8c 100644
--- a/pom.xml
+++ b/pom.xml
@@ -50,6 +50,11 @@
slf4j-api
1.7.25
+
+com.vdurmont
+semver4j
+3.1.0
+
org.junit.jupiter
diff --git
a/src/main/java/org/apache/cassandra/distributed/api/IInstanceConfig.java
b/src/main/java/org/apache/cassandra/distributed/api/IInstanceConfig.java
index 7324816..ba1a09b 100644
--- a/src/main/java/org/apache/cassandra/distributed/api/IInstanceConfig.java
+++ b/src/main/java/org/apache/cassandra/distributed/api/IInstanceConfig.java
@@ -25,8 +25,9 @@ import java.util.Objects;
import java.util.UUID;
import java.util.function.Function;
+import com.vdurmont.semver4j.Semver;
+
import org.apache.cassandra.distributed.shared.NetworkTopology;
-import org.apache.cassandra.distributed.shared.Versions;
public interface IInstanceConfig
{
@@ -68,7 +69,7 @@ public interface IInstanceConfig
boolean has(Feature featureFlag);
-public IInstanceConfig forVersion(Versions.Major major);
+public IInstanceConfig forVersion(Semver series);
public static class ParameterizedClass
{
diff --git
a/src/main/java/org/apache/cassandra/distributed/shared/Versions.java
b/src/main/java/org/apache/cassandra/distributed/shared/Versions.java
index a49b7c7..1fb7149 100644
--- a/src/main/java/org/apache/cassandra/distributed/shared/Versions.java
+++ b/src/main/java/org/apache/cassandra/distributed/shared/Versions.java
@@ -24,7 +24,6 @@ import java.net.URL;
import java.nio.file.Paths;
import java.util.ArrayList;
import java.util.Collections;
-import java.util.Comparator;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
@@ -32,6 +31,8 @@ import java.util.regex.Matcher;
import java.util.regex.Pattern;
import java.util.stream.Collectors;
+import com.vdurmont.semver4j.Semver;
+import com.vdurmont.semver4j.Semver.SemverType;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -64,112 +65,64 @@ public final class Versions
return urls;
}
-public enum Major
+public static final class Version implements Comparable
{
-v22("2\\.2\\.([0-9]+)"),
-v30("3\\.0\\.([0-9]+)"),
-v3X("3\\.([1-9]|1[01])(\\.([0-9]+))?"),
-v40("4\\.0(?:\\.|-alpha|-beta|-rc)([0-9]+)(\\.([0-9]+))?"),
-v4X("4\\.([1-9][0-9]*)(\\.([0-9]+))?");
-final Pattern pattern;
-
-Major(String verify)
-{
-this.pattern = Pattern.compile(verify);
-}
-
-static Major fromFull(String version)
-{
-if (version.isEmpty())
-throw new IllegalArgumentException(version);
-switch (version.charAt(0))
-{
-case '2':
-if (version.startsWith("2.2"))
-return v22;
-throw new IllegalArgumentException(version);
-case '3':
-if (version.startsWith("3.0"))
-return v30;
-return v3X;
-case '4':
-if (version.startsWith("4.0"))
-return v40;
-return v4X;
-default:
-throw new IllegalArgumentException(version);
-}
-}
-
-// verify that the version string is valid for this major version
-boolean verify(String version)
-{
-return pattern.matcher(version).matches();
-}
-
-// sort two strings of the same major version as this enum instance
-int compare(String a, String b)
-{
-Matcher ma = pattern.matcher(a);
-Matcher mb = pattern.matcher(b);
-if (!ma.matches()) throw new IllegalArgumentException(a);
-if (!mb.matches()) throw new IllegalArgumentException(b);
-int result = Integer.compare(Integer.parseInt(ma.group(1)),
Integer.parseInt(mb.group(1)));
-if (result == 0 && this == v3X && (ma.group(3) != null ||
mb.group(3) != null))
-{
-if (ma.group(3) != null && mb.group(3) !=
[cassandra-in-jvm-dtest-api] 01/02: Update Versions for trunk as 4.1 and new release branch cassandra-4.0
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git
commit 8b17c8dfe3fa0d062af1e861b8b204c7bbeb275b
Author: mck
AuthorDate: Sun May 2 17:40:27 2021 +0200
Update Versions for trunk as 4.1 and new release branch cassandra-4.0
Includes VersionsTest, version regexp fix, and handling non-existant build
directory.
patch by Mick Semb Wever; reviewed by Alex Petrov for CASSANDRA-16649
---
.gitignore | 1 +
pom.xml| 22 -
.../cassandra/distributed/shared/Versions.java | 35
.../cassandra/distributed/shared/VersionsTest.java | 95 ++
4 files changed, 117 insertions(+), 36 deletions(-)
diff --git a/.gitignore b/.gitignore
index 41a9edb..e016fc5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -79,3 +79,4 @@ doc/source/tools/nodetool
# Python virtual environment
venv/
+/nbproject/
diff --git a/pom.xml b/pom.xml
index 4e206b4..88cb573 100644
--- a/pom.xml
+++ b/pom.xml
@@ -90,10 +90,6 @@
-
-maven-surefire-plugin
-2.22.2
-
@@ -122,7 +118,6 @@
org.apache.rat
apache-rat-plugin
-0.13
true
@@ -151,22 +146,6 @@
-
-org.apache.maven.plugins
-maven-javadoc-plugin
-3.0.1
-
-
-attach-javadocs
-
-jar
-
-
-none
-
-
-
-
@@ -174,7 +153,6 @@
scm:git:https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git
scm:git:https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git
https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git
- 0.0.6
diff --git
a/src/main/java/org/apache/cassandra/distributed/shared/Versions.java
b/src/main/java/org/apache/cassandra/distributed/shared/Versions.java
index 469022e..a49b7c7 100644
--- a/src/main/java/org/apache/cassandra/distributed/shared/Versions.java
+++ b/src/main/java/org/apache/cassandra/distributed/shared/Versions.java
@@ -35,7 +35,7 @@ import java.util.stream.Collectors;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
-public class Versions
+public final class Versions
{
private static final Logger logger =
LoggerFactory.getLogger(Versions.class);
@@ -69,7 +69,8 @@ public class Versions
v22("2\\.2\\.([0-9]+)"),
v30("3\\.0\\.([0-9]+)"),
v3X("3\\.([1-9]|1[01])(\\.([0-9]+))?"),
-v4("4\\.([0-9]+)");
+v40("4\\.0(?:\\.|-alpha|-beta|-rc)([0-9]+)(\\.([0-9]+))?"),
+v4X("4\\.([1-9][0-9]*)(\\.([0-9]+))?");
final Pattern pattern;
Major(String verify)
@@ -92,7 +93,9 @@ public class Versions
return v30;
return v3X;
case '4':
-return v4;
+if (version.startsWith("4.0"))
+return v40;
+return v4X;
default:
throw new IllegalArgumentException(version);
}
@@ -108,7 +111,7 @@ public class Versions
int compare(String a, String b)
{
Matcher ma = pattern.matcher(a);
-Matcher mb = pattern.matcher(a);
+Matcher mb = pattern.matcher(b);
if (!ma.matches()) throw new IllegalArgumentException(a);
if (!mb.matches()) throw new IllegalArgumentException(b);
int result = Integer.compare(Integer.parseInt(ma.group(1)),
Integer.parseInt(mb.group(1)));
@@ -116,6 +119,7 @@ public class Versions
{
if (ma.group(3) != null && mb.group(3) != null)
{
+// XXX likely wrong for alpha|beta|rc versions
result = Integer.compare(Integer.parseInt(ma.group(3)),
Integer.parseInt(mb.group(3)));
}
else
@@ -149,7 +153,7 @@ public class Versions
private final Map> versions;
-public Versions(Map> versions)
+private Versions(Map> versions)
{
this.versions = versions;
}
@@ -173,19 +177,22 @@ public class Versions
final String dtestJarDirectory = System.getProperty(PROPERTY_PREFIX +
"test.dtest_jar_path", "build");
final File sourceDirectory = new File(dtestJarDirectory);
[jira] [Commented] (CASSANDRA-16621) Replace spinAsserts code with Awaitility code
[ https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377948#comment-17377948 ] Berenguer Blasi commented on CASSANDRA-16621: - We're having problems with tests given we're cutting a 4.0.0 release and some code changes need to go through. I want to wait for things to stabilize. Apologies fro the noise, sthg that should be simple it's turning into sthg a bit more involved... Murphy... > Replace spinAsserts code with Awaitility code > - > > Key: CASSANDRA-16621 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16621 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Jogesh Anand >Priority: Normal > Labels: low-hanging-fruit > Fix For: 4.0.x > > > Currently spinAsserts does a similar thing to Awaitility which is being used > more and more. We have now 2 ways of doing the same thing so it would be good > to consolidate -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16621) Replace spinAsserts code with Awaitility code
[ https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377912#comment-17377912 ] Berenguer Blasi commented on CASSANDRA-16621: - Those failing tests are weird as they never have failed before. But there could be a bug lurking you never know... > Replace spinAsserts code with Awaitility code > - > > Key: CASSANDRA-16621 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16621 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Jogesh Anand >Priority: Normal > Labels: low-hanging-fruit > Fix For: 4.0.x > > > Currently spinAsserts does a similar thing to Awaitility which is being used > more and more. We have now 2 ways of doing the same thing so it would be good > to consolidate -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16621) Replace spinAsserts code with Awaitility code
[ https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377878#comment-17377878 ] Jogesh Anand commented on CASSANDRA-16621: -- [~bereng] - thanks! I have also been trying out some changes (unrelated to the awaitility fix for this ticket) to fix the failing tests. Looks like something similar was mentioned in CASSANDRA-16670. Regardless, will let keep you posted if I get those tests working. > Replace spinAsserts code with Awaitility code > - > > Key: CASSANDRA-16621 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16621 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Jogesh Anand >Priority: Normal > Labels: low-hanging-fruit > Fix For: 4.0.x > > > Currently spinAsserts does a similar thing to Awaitility which is being used > more and more. We have now 2 ways of doing the same thing so it would be good > to consolidate -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
