[jira] [Comment Edited] (CASSANDRA-17879) It is not possible to autocomplete "WITH" when creating materialized view

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-17879 at 9/28/22 5:41 AM:


Thanks [~bschoeni] for the patch.

I tried it and the issues I ran into were:

1) it stopped to work when the primary key was composite, if primary key was 
just a simple column, "(mycolumn)", it autocompleted "WITH". But as soon as the 
key was "((col1), col2)" and I wanted to autocomplete "WITH CLUSTERING ORDER BY 
(col2 DESC);" it did not offer "WITH".

2) I was expecting that it will offer me all properties which I can use for 
regular tables. For example, "WITH comment = 'this is my view'" or any other 
property for that matter. 

For 2), this is where I am not completely sure if we are doing the right thing. 
Are mv allowed to go wild with other properties? Like you can have one 
gc_grace_seconds for base table but other for a mv? What does that mean in 
practice? Or compression, compaction and so on ... that's why I asked 
[~brandon.williams] if this makes sense to add into mv too. 


was (Author: smiklosovic):
Thanks [~bschoeni] for the patch.

I tried it and the issues I ran into were:

1) it stopped to work when the primary key was composite, if primary key was 
just a simple column, "(mycolumn)", it autocompleted "WITH". But as soon as the 
key was "((col1), col2)" and I wanted to autocomplete "WITH CLUSTERING ORDER BY 
(col2 DESC);" it did not offer "WITH".

2) I was expecting that it will offer me all properties which I can use for 
regular tables. For example, "WITH comment = 'this is my view'" or any other 
property for that matter. 

For 2), this is where I am not completely sure if we are doing the right thing. 
Are mv allowed to go wild with other properties? Like you can have one 
gc_grace_seconds for base table but other from mv? What does that mean in 
practice? Or compression, compaction and so on ... that's why I asked 
[~brandon.williams] if this makes sense to add into mv too. 

> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1 
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2) 
> {code}
> nothing happens after pressing tab, there should be options shown as for 
> table case.



--
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-17879) It is not possible to autocomplete "WITH" when creating materialized view

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-17879 at 9/28/22 5:40 AM:


Thanks [~bschoeni] for the patch.

I tried it and the issues I ran into were:

1) it stopped to work when the primary key was composite, if primary key was 
just a simple column, "(mycolumn)", it autocompleted "WITH". But as soon as the 
key was "((col1), col2)" and I wanted to autocomplete "WITH CLUSTERING ORDER BY 
(col2 DESC);" it did not offer "WITH".

2) I was expecting that it will offer me all properties which I can use for 
regular tables. For example, "WITH comment = 'this is my view'" or any other 
property for that matter. 

For 2), this is where I am not completely sure if we are doing the right thing. 
Are mv allowed to go wild with other properties? Like you can have one 
gc_grace_seconds for base table but other from mv? What does that mean in 
practice? Or compression, compaction and so on ... that's why I asked 
[~brandon.williams] if this makes sense to add into mv too. 


was (Author: smiklosovic):
Thanks [~bschoeni] for the patch.

I tried it and the issues I ran into were:

1) it stopped to work when the primary key was composite, if primary key was 
just a simple column, "(mycolumn)", it autocompleted "WITH". But as soon as the 
key was "((col1), col2)" and I wanted to autocomplete "WITH CLUSTERING ORDER BY 
(col2 DESC);" it did not offered "WITH".

2) I was expecting that it will offer me all properties which I can use for 
regular tables. For example, "WITH comment = 'this is my view'" or any other 
property for that matter. 

For 2), this is where I am not completely sure if we are doing the right thing. 
Are mv allowed to go wild with other properties? Like you can have one 
gc_grace_seconds for base table but other from mv? What does that mean in 
practice? Or compression, compaction and so on ... that's why I asked 
[~brandon.williams] if this makes sense to add into mv too. 

> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1 
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2) 
> {code}
> nothing happens after pressing tab, there should be options shown as for 
> table case.



--
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-17879) It is not possible to autocomplete "WITH" when creating materialized view

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-17879:
---

Thanks [~bschoeni] for the patch.

I tried it and the issues I ran into were:

1) it stopped to work when the primary key was composite, if primary key was 
just a simple column, "(mycolumn)", it autocompleted "WITH". But as soon as the 
key was "((col1), col2)" and I wanted to autocomplete "WITH CLUSTERING ORDER BY 
(col2 DESC);" it did not offered "WITH".

2) I was expecting that it will offer me all properties which I can use for 
regular tables. For example, "WITH comment = 'this is my view'" or any other 
property for that matter. 

For 2), this is where I am not completely sure if we are doing the right thing. 
Are mv allowed to go wild with other properties? Like you can have one 
gc_grace_seconds for base table but other from mv? What does that mean in 
practice? Or compression, compaction and so on ... that's why I asked 
[~brandon.williams] if this makes sense to add into mv too. 

> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1 
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2) 
> {code}
> nothing happens after pressing tab, there should be options shown as for 
> table case.



--
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-17879) It is not possible to autocomplete "WITH" when creating materialized view

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-17879:
--
Reviewers: Stefan Miklosovic, Stefan Miklosovic
   Stefan Miklosovic, Stefan Miklosovic  (was: Stefan Miklosovic)
   Status: Review In Progress  (was: Patch Available)

> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1 
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2) 
> {code}
> nothing happens after pressing tab, there should be options shown as for 
> table case.



--
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-website] branch asf-staging updated (25b1376ed -> eccb9eccb)

[git-site-role]

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

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


 discard 25b1376ed generate docs for 2db0aea2
 new eccb9eccb generate docs for 2db0aea2

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

 * -- * -- B -- O -- O -- O   (25b1376ed)
\
 N -- N -- N   refs/heads/asf-staging (eccb9eccb)

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

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

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


Summary of changes:
 .../cassandra/tools/nodetool/clearsnapshot.html|  11 ++-
 .../cassandra/tools/nodetool/clearsnapshot.html|  11 ++-
 site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078 
bytes
 3 files changed, 20 insertions(+), 2 deletions(-)


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

[jira] [Commented] (CASSANDRA-17879) It is not possible to autocomplete "WITH" when creating materialized view

[Brad Schoening (Jira)]

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

Brad Schoening commented on CASSANDRA-17879:


[~smiklosovic] this required a bit more thought than it seemed at first. If you 
get the BNF syntax a little off, it just stops autocompleting. 

This was definitely a bug as the  production rules were copied 
from the select statement syntax and not syntactically correct for creating 
materialized view.  E.g. you can't specify 'distinct' or 'as' aliases with a 
materialized view.

Also, I found that unit tests are missing for six other CQLSH commands, 
including 'create index' as reported in CASSANDRA-16640.

> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1 
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2) 
> {code}
> nothing happens after pressing tab, there should be options shown as for 
> table case.



--
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-17879) It is not possible to autocomplete "WITH" when creating materialized view

[Brad Schoening (Jira)]

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

Brad Schoening updated CASSANDRA-17879:
---
Test and Documentation Plan: 
1. updated and ran the unit test:

pytest test_cqlsh_completion.py -k test_complete_in_create_materializedview

2. validated with live CQLSH session also
 Status: Patch Available  (was: Open)

> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1 
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2) 
> {code}
> nothing happens after pressing tab, there should be options shown as for 
> table case.



--
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-17879) It is not possible to autocomplete "WITH" when creating materialized view

[Brad Schoening (Jira)]

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

Brad Schoening updated CASSANDRA-17879:
---
 Bug Category: Parent values: Correctness(12982)Level 1 values: API / 
Semantic Implementation(12988)
   Complexity: Low Hanging Fruit
Discovered By: User Report
 Severity: Low
   Status: Open  (was: Triage Needed)

> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1 
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2) 
> {code}
> nothing happens after pressing tab, there should be options shown as for 
> table case.



--
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-17879) It is not possible to autocomplete "WITH" when creating materialized view

[Brad Schoening (Jira)]

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

Brad Schoening updated CASSANDRA-17879:
---
Component/s: CQL/Interpreter

> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1 
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2) 
> {code}
> nothing happens after pressing tab, there should be options shown as for 
> table case.



--
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-16861) Fix flaky test test_compression_cql_options

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova reassigned CASSANDRA-16861:
---

Assignee: (was: Ekaterina Dimitrova)

> Fix flaky test test_compression_cql_options
> ---
>
> Key: CASSANDRA-16861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16861
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.x
>
>
> While working on another ticket, I saw test_compression_cql_options failing 
> (which is not the case in Jenkins) but the Circle CI multiplexer showed it as 
> being flaky:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0]
> {code:java}
> sstables = self.get_sstables(table='compression_opts_table', 
> indexes=list())
> sstable_paths = self.get_table_paths('compression_opts_table')
> found = False
> for sstable_path in sstable_paths:
> sstable = os.path.join(sstable_path, 
> sstables['compression_opts_table'][1])
> if os.path.exists(sstable):
> assert 'DEFLATE' == self._get_compression_type(sstable)
> found = True
> >   assert found
> E   assert False
> compression_test.py:118: AssertionError
> {code}
>  
>  



--
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-16861) Fix flaky test test_compression_cql_options

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova reassigned CASSANDRA-16861:
---

Assignee: Ekaterina Dimitrova

> Fix flaky test test_compression_cql_options
> ---
>
> Key: CASSANDRA-16861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16861
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.x
>
>
> While working on another ticket, I saw test_compression_cql_options failing 
> (which is not the case in Jenkins) but the Circle CI multiplexer showed it as 
> being flaky:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0]
> {code:java}
> sstables = self.get_sstables(table='compression_opts_table', 
> indexes=list())
> sstable_paths = self.get_table_paths('compression_opts_table')
> found = False
> for sstable_path in sstable_paths:
> sstable = os.path.join(sstable_path, 
> sstables['compression_opts_table'][1])
> if os.path.exists(sstable):
> assert 'DEFLATE' == self._get_compression_type(sstable)
> found = True
> >   assert found
> E   assert False
> compression_test.py:118: AssertionError
> {code}
>  
>  



--
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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-17928 at 9/27/22 10:56 PM:
---

As the test exists in 4.0, I tried to reproduce the failure in both 4.0 and 4.1
Managed to reproduce it when run with compression twice in 5000 times:
 - 
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1964/workflows/de6b4aa9-0a50-4488-b8fd-5e0da2718507/jobs/15521/tests#failed-test-0]
But I didn't manage in 10 000 runs on 4.0 - 
[j8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1966/workflows/d616e242-28f3-46d0-b345-30faf2f3ec24],
 
[j11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1966/workflows/38a3ca64-97fe-4477-a05d-3aed705131b1]

Just with the regular _ant testsome_ target I didn't manage to reproduce it 
5000 times on both branches. 


was (Author: e.dimitrova):
As the test exists in 4.0, I tried to reproduce the failure in both 4.0 and 4.1
Managed to reproduce it when run with compression twice in 5000 times:
 - 
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1964/workflows/de6b4aa9-0a50-4488-b8fd-5e0da2718507/jobs/15521/tests#failed-test-0]
But I didn't manage in 10 000 runs on 4.0 - 
[j8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1966/workflows/d616e242-28f3-46d0-b345-30faf2f3ec24],
 
[j11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1966/workflows/38a3ca64-97fe-4477-a05d-3aed705131b1]

Just with the regular ant test some target I didn't manage to reproduce it 5000 
times on both branches. 

> Test Failure: 
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.1-beta
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO  [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took 
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO  [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took 
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO  [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 - 
> Configuration location: 
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
>   at 
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
>   at 
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
> {code}



--
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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-17928:
-

As the test exists in 4.0, I tried to reproduce the failure in both 4.0 and 4.1
Managed to reproduce it when run with compression twice in 5000 times:
 - 
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1964/workflows/de6b4aa9-0a50-4488-b8fd-5e0da2718507/jobs/15521/tests#failed-test-0]
But I didn't manage in 10 000 runs on 4.0 - 
[j8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1966/workflows/d616e242-28f3-46d0-b345-30faf2f3ec24],
 
[j11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1966/workflows/38a3ca64-97fe-4477-a05d-3aed705131b1]

Just with the regular ant test some target I didn't manage to reproduce it 5000 
times on both branches. 

> Test Failure: 
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.1-beta
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO  [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took 
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO  [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took 
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO  [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 - 
> Configuration location: 
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
>   at 
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
>   at 
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
> {code}



--
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-17221) Add Math functions

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova updated CASSANDRA-17221:

Status: Review In Progress  (was: Needs Committer)

> Add Math functions 
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
>  Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised 
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to 
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in 
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar 
> to {{TimeFctsTest}} 



--
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-17221) Add Math functions

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-17221:
-

[~xvade], after some recent changes in CASSANDRA-17750 adding dependencies 
happens out of build.xml.
It seems during rebase the previously added dependency got lost and the code is 
not compiling.
I added the dependency 
[here|https://github.com/ekaterinadimitrova2/cassandra/tree/math_fcts_review] 
as per the new instructions, unfortunately they are still in review 
[here|https://github.com/apache/cassandra-website/pull/170/files] but I am 
linking the commit for your reference if you are curious to see what changed.

Feel free to cherry-pick the last commit on that branch.

On a very quick skim I didn't see anything else lost during rebase, code-wise.

Unfortunately, our discussions got lost somewhere down the road but I will try 
to look at it one more time with fresh eyes. For now, leaving it to Benjamin, 
let's see what he as an expert in that area has to say :)  

> Add Math functions 
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
>  Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised 
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to 
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in 
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar 
> to {{TimeFctsTest}} 



--
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-16860) Add --older-than option to nodetool clearsnapshot

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-16860:
--
  Fix Version/s: 4.2
 (was: 4.x)
Source Control Link: 
https://github.com/apache/cassandra/commit/872e34c2d613a43b2c2be75efa016b6943bf87ad
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.2
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> h1. Summary
> Opening this issue in reference to [this WIP 
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc, 
> based on a TTL. This is to address the problem of snapshots accumulating. For 
> example, an organization I work for aims to keep snapshots for 30 days, 
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in: 
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be 
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the 
> following options:
> NAME
>  nodetool expiresnapshots - Removes snapshots that are older than a TTL
>  in days
> SYNOPSIS
>  nodetool [(-h  | --host )] [(-p  | --port )]
>  [(-pw  | --password )]
>  [(-pwf  | --password-file )]
>  [(-u  | --username )] expiresnapshots [--dry-run]
>  (-t  | --ttl )
> OPTIONS
>  --dry-run
>  Run without actually clearing snapshots
> -h , --host 
>  Node hostname or ip address
> -p , --port 
>  Remote jmx agent port number
> -pw , --password 
>  Remote jmx agent password
> -pwf , --password-file 
>  Path to the JMX password file
> -t , --ttl 
>  TTL (in days) to expire snapshots
> -u , --username 
>  Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps 
> (epoch time in miliseconds). For this reason, snapshot names that don't 
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a 
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
>  Snapshot Details:
>  Snapshot name Keyspace name Column family name True size Size on disk
>  1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
>  Starting simulated cleanup of snapshots older than 30 days
>  Clearing (dry run): 1529173922063
>  Clearing (dry run): 1599173922063
>  Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit 
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
>  Starting cleanup of snapshots older than 30 days
>  Clearing: 1529173922063
>  Clearing: 1599173922063
>  Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still 
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
>  Snapshot Details:
>  Snapshot name Keyspace name Column family name True size Size on disk
>  1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
>  - Tests
>  - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after 
> reading the contribution guide  Any advice on the following would be greatly 
> appreciated!
>  - What branch would this type of change be merged into? Currently, I'm 
> targeting {{apache:trunk}} by default
>  - Is there a test strategy/pattern for this type of change? I was not able 
> to find any existing tests for similar {{nodetool}} commands
> Thanks! 



--
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: 

[cassandra] branch trunk updated (526f41899a -> 872e34c2d6)

[smiklosovic]

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

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


from 526f41899a Merge branch 'cassandra-4.1' into trunk
 add 872e34c2d6 add --older-than and --older-than-timestamp options for 
nodetool clearsnapshot

No new revisions were added by this update.

Summary of changes:
 CHANGES.txt|   1 +
 NEWS.txt   |   4 +
 .../apache/cassandra/service/StorageService.java   |  45 +++-
 .../cassandra/service/StorageServiceMBean.java |  14 ++
 .../cassandra/service/snapshot/TableSnapshot.java  |  15 +-
 src/java/org/apache/cassandra/tools/NodeProbe.java |  24 +-
 .../cassandra/tools/nodetool/ClearSnapshot.java|  66 -
 .../apache/cassandra/db/SystemKeyspaceTest.java|   8 +-
 .../service/snapshot/TableSnapshotTest.java|  81 +-
 .../tools/nodetool/ClearSnapshotTest.java  | 279 ++---
 10 files changed, 480 insertions(+), 57 deletions(-)


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

[jira] [Commented] (CASSANDRA-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Josh McKenzie (Jira)]

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

Josh McKenzie commented on CASSANDRA-17930:
---

Either way - no need to really make it cumbersome, I just want to optimize for 
unblocking our release process based on whatever we land on. If we end up going 
w/circle I'd advocate for us doing that first, if ASF, that, etc. :)

> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
>  [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
> test images reside and the Jenkins build scripts, which I already referred 
> to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> [https://github.com/apache/cassandra/tree/trunk/.circleci]
>  



--
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-17915) Confusing error message when using ? with functions

[Natnael Adere (Jira)]

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

Natnael Adere reassigned CASSANDRA-17915:
-

Assignee: Natnael Adere

> Confusing error message when using ? with functions
> ---
>
> Key: CASSANDRA-17915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17915
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Natnael Adere
>Priority: Normal
>
> {code}
> INSERT INTO %S (a, b, c) VALUES (? + 1, ?, ?)
> {code}
> Errors saying
> {code}
> Ambiguous '+' operation with args ? and 1: use type casts to disambiguate
> {code}
> Now, if you google “type casts CQL” you get 
> https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/refCqlFunction.html
>  which says to do
> {code}
> CAST( selector AS to_type )
> {code}
> But this also fails!
> {code}
> InvalidRequestException: Ambiguous call to function system.castAsFloat (can 
> be matched by following signatures: system."castAsFloat" : (bigint) -> float, 
> system."castAsFloat" : (counter) -> float, system."castAsFloat" : (double) -> 
> float, system."castAsFloat" : (int) -> float, system."castAsFloat" : 
> (tinyint) -> float, system."castAsFloat" : (varint) -> float, 
> system."castAsFloat" : (decimal) -> float, system."castAsFloat" : (smallint) 
> -> float): use type casts to disambiguate
> {code}
> What we have to do is 
> {code}
> INSERT INTO %S (a, b, c) VALUES ((int) ? + 1, ?, ?)
> {code}
> We should improve the error message to show the expected syntax (or fix CAST 
> to work in this case).



--
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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova updated CASSANDRA-17928:

Description: 
[Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]

Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%

Stacktrace
{code:java}
java.lang.NullPointerException
at 
org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.lang.Thread.run(Thread.java:829)
{code}



{code:java}
Standard Output
INFO  [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took 
1221 ms to scan 8 urls, producing 1756 keys and 6922 values
INFO  [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took 
907 ms to scan 8 urls, producing 1756 keys and 6922 values
INFO  [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 - 
Configuration location: 
file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
...[truncated 35568 chars]...
.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
at 
org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
at 
org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
{code}


  was:
[Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]

Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%

Stacktrace
{code}
java.lang.NullPointerException
at 
org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.lang.Thread.run(Thread.java:829)
{code}


> Test Failure: 
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.1-beta
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO  [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took 
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO  [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took 
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO  

[jira] [Commented] (CASSANDRA-17352) CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs

[Jeremy Hanna (Jira)]

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

Jeremy Hanna commented on CASSANDRA-17352:
--

[~marcuse] do you have any thoughts on the flags that were used here?  Am I 
misunderstanding intent of having two flags?

> CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs
> -
>
> Key: CASSANDRA-17352
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17352
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/UDF
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
>
> When running Apache Cassandra with the following configuration:
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> enable_user_defined_functions_threads: false 
> it is possible for an attacker to execute arbitrary code on the host. The 
> attacker would need to have enough permissions to create user defined 
> functions in the cluster to be able to exploit this. Note that this 
> configuration is documented as unsafe, and will continue to be considered 
> unsafe after this CVE.
> This issue is being tracked as CASSANDRA-17352
> Mitigation:
> Set `enable_user_defined_functions_threads: true` (this is default)
> or
> 3.0 users should upgrade to 3.0.26
> 3.11 users should upgrade to 3.11.12
> 4.0 users should upgrade to 4.0.2
> Credit:
> This issue was discovered by Omer Kaspi of the JFrog Security vulnerability 
> research team.



--
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-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-17930 at 9/27/22 7:28 PM:
--

One idea on my mind is first to review and sanitize the plan - what is needed. 
And then the actual work done in one, two or more as [~dchenbecker] see fit 
tasks. But I would leave it to him to decide after he gets acquainted with the 
environment and the scope of work. 


was (Author: e.dimitrova):
One idea on my mind is first to review and sanitize the plan - what is needed. 
And then the actual work done in one, two or more as [~dchenbecker] see fit 
tasks. But I would leave it to him to decide after he gets acquainted with the 
environment.

> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
>  [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
> test images reside and the Jenkins build scripts, which I already referred 
> to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> [https://github.com/apache/cassandra/tree/trunk/.circleci]
>  



--
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-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-17930:
-

One idea on my mind is first to review and sanitize the plan - what is needed. 
And then the actual work done in one, two or more as [~dchenbecker] see fit 
tasks. But I would leave it to him to decide after he gets acquainted with the 
environment.

> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
>  [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
> test images reside and the Jenkins build scripts, which I already referred 
> to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> [https://github.com/apache/cassandra/tree/trunk/.circleci]
>  



--
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-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-17930 at 9/27/22 7:26 PM:
--

I think they overlap but I think we can do the work in subtasks (as small or as 
big as people feel comfortable and they think that much time they can dedicate 
to that), this one being the final goal. Thus also someone else interested can 
join the effort maybe? 

Like there is  CASSANDRA-17145 for example


was (Author: e.dimitrova):
I think they overlap but I think we can do the work in subtasks, this one being 
the final goal. Thus also someone else interested can join the effort maybe? 

Like there is  CASSANDRA-17145 for example

> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
>  [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
> test images reside and the Jenkins build scripts, which I already referred 
> to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> [https://github.com/apache/cassandra/tree/trunk/.circleci]
>  



--
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-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-17930:
-

I think they overlap but I think we can do the work in subtasks, this one being 
the final goal. Thus also someone else interested can join the effort maybe? 

Like there is  CASSANDRA-17145 for example

> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
>  [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
> test images reside and the Jenkins build scripts, which I already referred 
> to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> [https://github.com/apache/cassandra/tree/trunk/.circleci]
>  



--
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-17248) Fix Prepared Statements behaviours after 15252

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17248:
--
Resolution: (was: Fixed)
Status: Open  (was: Resolved)

> Fix Prepared Statements behaviours after 15252
> --
>
> Key: CASSANDRA-17248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17248
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
>
> [CASSANDRA-15252] has fixed an important issue: unwanted hash changes when 
> preparing fully qualified prepared statements which was causing 
> cluster-killing re-prepare loops. However, the fix introduced a regression: 
> non-qualified statements can get prepared against one keyspace but then 
> executed on another under some circumstances. This patch reconciles all 
> behaviours.



--
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-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Josh McKenzie (Jira)]

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

Josh McKenzie commented on CASSANDRA-17930:
---

How would you feel about splitting this up into 2 tasks - 1 being "get Circle 
to run all necessary tests to validate a release" and the other being "bring 
ASF CI into parity with Circle"?

> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
>  [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
> test images reside and the Jenkins build scripts, which I already referred 
> to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> [https://github.com/apache/cassandra/tree/trunk/.circleci]
>  



--
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-17931) Augment our disk space checks for compaction

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17931:
--
Test and Documentation Plan: New unit and in-jvm dtests
 Status: Patch Available  (was: Open)

> Augment our disk space checks for compaction
> 
>
> Key: CASSANDRA-17931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17931
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> There are a few things we can augment in how we handle compactions locally to 
> improve upon the very simple "keep X Mebibytes free on disk" we currently 
> have:
>  # Allow specification of free space available in percent rather than raw size
>  # Do this on a per-disk basis based on what's going on with compactions
>  # Include an estimate of the disk space of active compactions in flight when 
> we do the above calculation check so we don't blow past our limits due to 
> concurrent runs
>  



--
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-17931) Augment our disk space checks for compaction

[Josh McKenzie (Jira)]

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

Josh McKenzie commented on CASSANDRA-17931:
---

||Item|Link||
|PR|[link|https://github.com/apache/cassandra/pull/1888]|
|JDK8 
CI|[link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/307/workflows/79e7bec4-f50c-4d1e-b173-ef024994a92e]|
|JDK11 
CI|[link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/307/workflows/a5744fa0-b838-445e-8ee4-e743fe8c212e]|

> Augment our disk space checks for compaction
> 
>
> Key: CASSANDRA-17931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17931
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> There are a few things we can augment in how we handle compactions locally to 
> improve upon the very simple "keep X Mebibytes free on disk" we currently 
> have:
>  # Allow specification of free space available in percent rather than raw size
>  # Do this on a per-disk basis based on what's going on with compactions
>  # Include an estimate of the disk space of active compactions in flight when 
> we do the above calculation check so we don't blow past our limits due to 
> concurrent runs
>  



--
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-17931) Augment our disk space checks for compaction

[Josh McKenzie (Jira)]

Josh McKenzie created CASSANDRA-17931:
-

 Summary: Augment our disk space checks for compaction
 Key: CASSANDRA-17931
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17931
 Project: Cassandra
  Issue Type: Improvement
  Components: Local/Compaction
Reporter: Josh McKenzie
Assignee: Josh McKenzie


There are a few things we can augment in how we handle compactions locally to 
improve upon the very simple "keep X Mebibytes free on disk" we currently have:
 # Allow specification of free space available in percent rather than raw size
 # Do this on a per-disk basis based on what's going on with compactions
 # Include an estimate of the disk space of active compactions in flight when 
we do the above calculation check so we don't blow past our limits due to 
concurrent runs

 



--
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-17931) Augment our disk space checks for compaction

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17931:
--
Change Category: Operability
 Complexity: Normal
  Fix Version/s: 4.x
 Status: Open  (was: Triage Needed)

> Augment our disk space checks for compaction
> 
>
> Key: CASSANDRA-17931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17931
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Compaction
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> There are a few things we can augment in how we handle compactions locally to 
> improve upon the very simple "keep X Mebibytes free on disk" we currently 
> have:
>  # Allow specification of free space available in percent rather than raw size
>  # Do this on a per-disk basis based on what's going on with compactions
>  # Include an estimate of the disk space of active compactions in flight when 
> we do the above calculation check so we don't blow past our limits due to 
> concurrent runs
>  



--
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-17248) Fix Prepared Statements behaviours after 15252

[Jaydeepkumar Chovatia (Jira)]

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

Jaydeepkumar Chovatia edited comment on CASSANDRA-17248 at 9/27/22 6:38 PM:


[~ifesdjeen] I've created a patch (on 3.0 for now) that includes the following:
 # It Fixes the potential root cause in which we should never ever prepare a 
statement for non-fully qualified queries with null keyspace
 # With this patch, collision for two keyspaces having the same schema should 
never ever occur. Let's say in the worst scenario, it does happen, then it is a 
bug on the Cassandra server we need to investigate. Cassandra should never 
silently ignore it as it leads to a *{color:#de350b}disastrous{color}* 
situation to be in. This patch throws an exception back to the user instead of 
silently ignoring it.
 # Additional stats that tell us prepared statement behavior, such as cache 
used, empty prepared statements, etc.
 # Last but not least, unit test cases that would cover collision scenarios. 
The test cases added in this diff passed with 3.0.14 - fails with 3.0.26 (w/o 
this patch) - but passed with this patch

Please find the 3.0 Patch here: 
[https://github.com/jaydeepkumar1984/cassandra/pull/1/commits/37e60cac04df6c7042f4a83f50c046effc60ac04|https://github.com/apache/cassandra/pull/1872/commits/758bc4a89d7ca9d0bfe27e6f41000484724261bc]

Please review it and then I will create more patches for 3.11, 4.0, and trunk.


was (Author: chovatia.jayd...@gmail.com):
[~ifesdjeen] I've created a patch (on 3.0 for now) that includes the following:
 # It Fixes the potential root cause in which we should never ever prepare a 
statement for non-fully qualified queries with null keyspace
 # With this patch, collision for two keyspaces having the same schema should 
never ever occur. Let's say in the worst scenario, it does happen, then it is a 
bug on the Cassandra server we need to investigate. Cassandra should never 
silently ignore it as it leads to a *{color:#de350b}disastrous{color}* 
situation to be in. This patch throws an exception back to the user instead of 
silently ignoring it.
 # Additional stats that tell us prepared statement behavior, such as cache 
used, empty prepared statements, etc.
 # Last but not least, unit test cases that would cover collision scenarios. 
The test cases added in this diff passed with 3.0.14 - fails with 3.0.26 (w/o 
this patch) - but passed with this patch

Please find the 3.0 Patch here: 
[https://github.com/jaydeepkumar1984/cassandra/pull/1/commits/37e60cac04df6c7042f4a83f50c046effc60ac04]

Please review it and then I will create more patches for 3.11, 4.0, and trunk.

> Fix Prepared Statements behaviours after 15252
> --
>
> Key: CASSANDRA-17248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17248
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
>
> [CASSANDRA-15252] has fixed an important issue: unwanted hash changes when 
> preparing fully qualified prepared statements which was causing 
> cluster-killing re-prepare loops. However, the fix introduced a regression: 
> non-qualified statements can get prepared against one keyspace but then 
> executed on another under some circumstances. This patch reconciles all 
> behaviours.



--
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-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova updated CASSANDRA-17930:

Description: 
As discussed in this 
[thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
Cassandra community wants to see CircleCI and ASF CI being aligned - running 
the same tests, configurations, all tests.

A few examples of discrepancies we already noticed:
 * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
 * dtest-large run only in Jenkins
 * simulator tests run only in CircleCI
 * In a quick skim I think I didn't see 
[these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
 runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
 * packaging is also only tested in Jenkins as far as I recall

And these are only a few examples on top of my mind. I am sure we will find 
more. We also need to verify the way we call those tests is correct and matches 
in both CIs. (I was looking to solve similar discrepancy in CASSANDRA-17912)

Some info on our tests suites here - 
[https://cassandra.apache.org/_/development/testing.html,]

 [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
test images reside and the Jenkins build scripts, which I already referred to. 

CircleCI info can be found in the readme which resides in the in-tree folder 
dedicated to configuration and scripts for Circle CI - 
[https://github.com/apache/cassandra/tree/trunk/.circleci]

 

  was:
As discussed in this 
[thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
Cassandra community wants to see CircleCI and ASF CI being aligned - running 
the same tests, configurations, all tests.

A few examples of discrepancies we already noticed:
 * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
 * dtest-large run only in Jenkins
 * simulator tests run only in CircleCI
 * In a quick skim I think I didn't see 
[these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
 runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
 * packaging is also only tested in Jenkins as far as I recall

And these are only a few examples on top of my mind. I am sure we will find 
more. We also need to verify the way we call those tests is correct and matches 
in both CIs. (I was looking to solve similar discrepancy in CASSANDRA-17912)

Some info on our tests suites here - 
[https://cassandra.apache.org/_/development/testing.html,]

 [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
test images reside and the Jenkins build scripts I already referred to. 

CircleCI info can be found in the readme which resides in the in-tree folder 
dedicated to configuration and scripts for Circle CI - 
[https://github.com/apache/cassandra/tree/trunk/.circleci]

 


> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
>  [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
> test images reside and the Jenkins build scripts, which I already referred 
> to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> [https://github.com/apache/cassandra/tree/trunk/.circleci]
>  



--
This message was sent by Atlassian 

[jira] [Updated] (CASSANDRA-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova updated CASSANDRA-17930:

Description: 
As discussed in this 
[thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
Cassandra community wants to see CircleCI and ASF CI being aligned - running 
the same tests, configurations, all tests.

A few examples of discrepancies we already noticed:
 * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
 * dtest-large run only in Jenkins
 * simulator tests run only in CircleCI
 * In a quick skim I think I didn't see 
[these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
 runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
 * packaging is also only tested in Jenkins as far as I recall

And these are only a few examples on top of my mind. I am sure we will find 
more. We also need to verify the way we call those tests is correct and matches 
in both CIs. (I was looking to solve similar discrepancy in CASSANDRA-17912)

Some info on our tests suites here - 
[https://cassandra.apache.org/_/development/testing.html,]

 [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
test images reside and the Jenkins build scripts I already referred to. 

CircleCI info can be found in the readme which resides in the in-tree folder 
dedicated to configuration and scripts for Circle CI - 
[https://github.com/apache/cassandra/tree/trunk/.circleci]

 

  was:
As discussed in this 
[thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
Cassandra community wants to see CircleCI and ASF CI being aligned - running 
the same tests, configurations, all tests.

A few examples of discrepancies we already noticed:
 * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
 * dtest-large run only in Jenkins
 * simulator tests run only in CircleCI
 * In a quick skim I think I didn't see 
[these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
 runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
 * packaging is also only tested in Jenkins as far as I recall

And these are only a few examples on top of my mind. I am sure we will find 
more. We also need to verify the way we call those tests is correct and matches 
in both CIs. (I was looking to solve similar discrepancy in CASSANDRA-17912)

Some info on our tests suites here - 
[https://cassandra.apache.org/_/development/testing.html,]

 [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
test image reside and the Jenkins build scripts I already referred to. 

CircleCI info can be found in the readme which resides in the in-tree folder 
dedicated to configuration and scripts for Circle CI - 
[https://github.com/apache/cassandra/tree/trunk/.circleci]

 


> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
>  [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
> test images reside and the Jenkins build scripts I already referred to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> [https://github.com/apache/cassandra/tree/trunk/.circleci]
>  



--
This message was sent by Atlassian Jira

[jira] [Updated] (CASSANDRA-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova updated CASSANDRA-17930:

Description: 
As discussed in this 
[thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
Cassandra community wants to see CircleCI and ASF CI being aligned - running 
the same tests, configurations, all tests.

A few examples of discrepancies we already noticed:
 * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
 * dtest-large run only in Jenkins
 * simulator tests run only in CircleCI
 * In a quick skim I think I didn't see 
[these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
 runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
 * packaging is also only tested in Jenkins as far as I recall

And these are only a few examples on top of my mind. I am sure we will find 
more. We also need to verify the way we call those tests is correct and matches 
in both CIs. (I was looking to solve similar discrepancy in CASSANDRA-17912)

Some info on our tests suites here - 
[https://cassandra.apache.org/_/development/testing.html,]

 [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
test image reside and the Jenkins build scripts I already referred to. 

CircleCI info can be found in the readme which resides in the in-tree folder 
dedicated to configuration and scripts for Circle CI - 
[https://github.com/apache/cassandra/tree/trunk/.circleci]

 

  was:
As discussed in this 
[thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
Cassandra community wants to see CircleCI and ASF CI being aligned - running 
the same tests, configurations, all tests.

A few examples of discrepancies we already noticed:
 * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
 * dtest-large run only in Jenkins
 * simulator tests run only in CircleCI
 * In a quick skim I think I didn't see 
[these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
 runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
 * packaging is also only tested in Jenkins as far as I recall

And these are only a few examples on top of my mind. I am sure we will find 
more. We also need to verify the way we call those tests is correct and matches 
in both CIs. (I was looking to solve similar discrepancy in CASSANDRA-17912)

Some info on our tests suites here - 
[https://cassandra.apache.org/_/development/testing.html,]

cassandra-builds repo where our test image reside and the Jenkins build scripts 
I already referred to. 

CircleCI info can be found in the readme which resides in the in-tree folder 
dedicated to configuration and scripts for Circle CI - 
https://github.com/apache/cassandra/tree/trunk/.circleci

 


> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
>  [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
> test image reside and the Jenkins build scripts I already referred to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> [https://github.com/apache/cassandra/tree/trunk/.circleci]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CASSANDRA-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova updated CASSANDRA-17930:

Fix Version/s: 4.x

> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
>  [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our 
> test images reside and the Jenkins build scripts, which I already referred 
> to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> [https://github.com/apache/cassandra/tree/trunk/.circleci]
>  



--
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-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova reassigned CASSANDRA-17930:
---

Assignee: Derek Chen-Becker

> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
> cassandra-builds repo where our test image reside and the Jenkins build 
> scripts I already referred to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> https://github.com/apache/cassandra/tree/trunk/.circleci
>  



--
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-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova updated CASSANDRA-17930:

Change Category: Quality Assurance
 Complexity: Normal
Component/s: CI
 Status: Open  (was: Triage Needed)

> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
> cassandra-builds repo where our test image reside and the Jenkins build 
> scripts I already referred to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> https://github.com/apache/cassandra/tree/trunk/.circleci
>  



--
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-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova updated CASSANDRA-17930:

Fix Version/s: 3.0.x
   3.11.x
   4.0.x
   4.1.x

> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
>  Issue Type: Task
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
>
> As discussed in this 
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
> Cassandra community wants to see CircleCI and ASF CI being aligned - running 
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
>  * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
>  * dtest-large run only in Jenkins
>  * simulator tests run only in CircleCI
>  * In a quick skim I think I didn't see 
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
>  runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
>  * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find 
> more. We also need to verify the way we call those tests is correct and 
> matches in both CIs. (I was looking to solve similar discrepancy in 
> CASSANDRA-17912)
> Some info on our tests suites here - 
> [https://cassandra.apache.org/_/development/testing.html,]
> cassandra-builds repo where our test image reside and the Jenkins build 
> scripts I already referred to. 
> CircleCI info can be found in the readme which resides in the in-tree folder 
> dedicated to configuration and scripts for Circle CI - 
> https://github.com/apache/cassandra/tree/trunk/.circleci
>  



--
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-17930) Ensure CircleCI and ASF Jenkins CI are aligned

[Ekaterina Dimitrova (Jira)]

Ekaterina Dimitrova created CASSANDRA-17930:
---

 Summary: Ensure CircleCI and ASF Jenkins CI are aligned
 Key: CASSANDRA-17930
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
 Project: Cassandra
  Issue Type: Task
Reporter: Ekaterina Dimitrova


As discussed in this 
[thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the 
Cassandra community wants to see CircleCI and ASF CI being aligned - running 
the same tests, configurations, all tests.

A few examples of discrepancies we already noticed:
 * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
 * dtest-large run only in Jenkins
 * simulator tests run only in CircleCI
 * In a quick skim I think I didn't see 
[these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
 runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
 * packaging is also only tested in Jenkins as far as I recall

And these are only a few examples on top of my mind. I am sure we will find 
more. We also need to verify the way we call those tests is correct and matches 
in both CIs. (I was looking to solve similar discrepancy in CASSANDRA-17912)

Some info on our tests suites here - 
[https://cassandra.apache.org/_/development/testing.html,]

cassandra-builds repo where our test image reside and the Jenkins build scripts 
I already referred to. 

CircleCI info can be found in the readme which resides in the in-tree folder 
dedicated to configuration and scripts for Circle CI - 
https://github.com/apache/cassandra/tree/trunk/.circleci

 



--
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-17885) Add solution for CASSANDRA-17581 to older branches for tests

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-17885:
--

[Here|https://app.circleci.com/pipelines/github/driftx/cassandra/652/workflows/08651048-223e-4af0-ba3a-5739f11c0f59/jobs/7367]
 is a passing run, finally.

> Add solution for CASSANDRA-17581 to older branches for tests
> 
>
> Key: CASSANDRA-17885
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17885
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tool/nodetool
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x
>
>
> Some of our tests use old branches for the purposes of testing upgrades and 
> behavior in mixed versions, but those lacking CASSANDRA-17581 will fail on 
> nodetool with a modern JDK.  We can port this fix to those branches and 
> adjust the tests to use the newest version of them to solve this going 
> forward.



--
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-website] branch asf-staging updated (5c3f8156a -> 25b1376ed)

[git-site-role]

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

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


 discard 5c3f8156a generate docs for 2db0aea2
 new 25b1376ed generate docs for 2db0aea2

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

 * -- * -- B -- O -- O -- O   (5c3f8156a)
\
 N -- N -- N   refs/heads/asf-staging (25b1376ed)

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

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

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


Summary of changes:
 content/search-index.js |   2 +-
 site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes
 2 files changed, 1 insertion(+), 1 deletion(-)


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

[jira] [Commented] (CASSANDRA-17925) Java source code should have sorted imports as defined in the codestyle

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-17925:
---

[~benedict] I am more than happy to revisit the code style on imports, yes. The 
order does not make sense to me either. I wanted to open discussion about it. I 
think I will bring it to the ML soon.

I can wait for 4.1 to be out, no rush. This can go in after 4.1 is shipped, for 
sure.

> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more 
> task remaining to be done - to add checkstyle for imports order and enforce 
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant 
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
> 
>   
> 
> 
> 
>  static="false" />
>  static="false" />
>  static="false" />
>  static="false" />
> 
> 
> 
> 
> 
> 
>   
> 
> {code}
> This code style is also mentioned in the web page here (minus some details 
> which are present in above configuration snippet but not on the web page): 
> [https://cassandra.apache.org/_/development/code_style.html] (at the very 
> bottom).
> However, when one runs "Optimise imports" in the context menu after 
> right-clicking on org.cassandra.apache package, it will refactor the imports 
> and it results with hundreds of changes.
> This means that the source code, as-is, does not adhere to the self-imposed 
> code style we ship for IDEA.
> If we fix this, we should add checkstyle for it like this:
> {code:java}
> 
>value="/(^java\.|javax)/,/(com\.google\.common|org\.apache\.log4j|org\.apache\.commons|org\.cliffc\.high_scale_lib|org\.junit|org\.slf4j)/"/>
>   
>   
>   
>   
>   
> 
> {code}
> This checkstyle on import order will pass on the source code we run the 
> import optimization in the context menu on.
> There is also no enforcement on "all star" imports (org.some.pkg.*). 
> Checkstyle has specific module for this: 
> [https://checkstyle.org/config_imports.html#AvoidStarImport] 
> I propose we should stop to use all-star imports. Same argument holds as 
> described there: Rationale: Importing all classes from a package or static 
> members from a class leads to tight coupling between packages or classes and 
> might lead to problems when a new version of a library introduces name 
> clashes.
> This should be applied to test checktyle as well and the source code should 
> be refactored on imports too.
> This should be done on cassandra-4.1 as well as for trunk.



--
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-17925) Java source code should have sorted imports as defined in the codestyle

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith edited comment on CASSANDRA-17925 at 9/27/22 3:45 PM:
-

If we're going to do this, perhaps we should fix the order that is defined by 
the code style, since it's really a silly order nobody has ever justified?


was (Author: benedict):
If we're going to do this, perhaps we should fix the order as defined in the 
code style, since it's really a silly order nobody has ever justified?

> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more 
> task remaining to be done - to add checkstyle for imports order and enforce 
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant 
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
> 
>   
> 
> 
> 
>  static="false" />
>  static="false" />
>  static="false" />
>  static="false" />
> 
> 
> 
> 
> 
> 
>   
> 
> {code}
> This code style is also mentioned in the web page here (minus some details 
> which are present in above configuration snippet but not on the web page): 
> [https://cassandra.apache.org/_/development/code_style.html] (at the very 
> bottom).
> However, when one runs "Optimise imports" in the context menu after 
> right-clicking on org.cassandra.apache package, it will refactor the imports 
> and it results with hundreds of changes.
> This means that the source code, as-is, does not adhere to the self-imposed 
> code style we ship for IDEA.
> If we fix this, we should add checkstyle for it like this:
> {code:java}
> 
>value="/(^java\.|javax)/,/(com\.google\.common|org\.apache\.log4j|org\.apache\.commons|org\.cliffc\.high_scale_lib|org\.junit|org\.slf4j)/"/>
>   
>   
>   
>   
>   
> 
> {code}
> This checkstyle on import order will pass on the source code we run the 
> import optimization in the context menu on.
> There is also no enforcement on "all star" imports (org.some.pkg.*). 
> Checkstyle has specific module for this: 
> [https://checkstyle.org/config_imports.html#AvoidStarImport] 
> I propose we should stop to use all-star imports. Same argument holds as 
> described there: Rationale: Importing all classes from a package or static 
> members from a class leads to tight coupling between packages or classes and 
> might lead to problems when a new version of a library introduces name 
> clashes.
> This should be applied to test checktyle as well and the source code should 
> be refactored on imports too.
> This should be done on cassandra-4.1 as well as for trunk.



--
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-17925) Java source code should have sorted imports as defined in the codestyle

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith edited comment on CASSANDRA-17925 at 9/27/22 3:45 PM:
-

If we're going to do this, perhaps we should first fix the order that is 
defined by the code style, since it's really a silly order nobody has ever 
justified?


was (Author: benedict):
If we're going to do this, perhaps we should fix the order that is defined by 
the code style, since it's really a silly order nobody has ever justified?

> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more 
> task remaining to be done - to add checkstyle for imports order and enforce 
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant 
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
> 
>   
> 
> 
> 
>  static="false" />
>  static="false" />
>  static="false" />
>  static="false" />
> 
> 
> 
> 
> 
> 
>   
> 
> {code}
> This code style is also mentioned in the web page here (minus some details 
> which are present in above configuration snippet but not on the web page): 
> [https://cassandra.apache.org/_/development/code_style.html] (at the very 
> bottom).
> However, when one runs "Optimise imports" in the context menu after 
> right-clicking on org.cassandra.apache package, it will refactor the imports 
> and it results with hundreds of changes.
> This means that the source code, as-is, does not adhere to the self-imposed 
> code style we ship for IDEA.
> If we fix this, we should add checkstyle for it like this:
> {code:java}
> 
>value="/(^java\.|javax)/,/(com\.google\.common|org\.apache\.log4j|org\.apache\.commons|org\.cliffc\.high_scale_lib|org\.junit|org\.slf4j)/"/>
>   
>   
>   
>   
>   
> 
> {code}
> This checkstyle on import order will pass on the source code we run the 
> import optimization in the context menu on.
> There is also no enforcement on "all star" imports (org.some.pkg.*). 
> Checkstyle has specific module for this: 
> [https://checkstyle.org/config_imports.html#AvoidStarImport] 
> I propose we should stop to use all-star imports. Same argument holds as 
> described there: Rationale: Importing all classes from a package or static 
> members from a class leads to tight coupling between packages or classes and 
> might lead to problems when a new version of a library introduces name 
> clashes.
> This should be applied to test checktyle as well and the source code should 
> be refactored on imports too.
> This should be done on cassandra-4.1 as well as for trunk.



--
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-17925) Java source code should have sorted imports as defined in the codestyle

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith commented on CASSANDRA-17925:


If we're going to do this, perhaps we should fix the order as defined in the 
code style, since it's really a silly order nobody has ever justified?

> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more 
> task remaining to be done - to add checkstyle for imports order and enforce 
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant 
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
> 
>   
> 
> 
> 
>  static="false" />
>  static="false" />
>  static="false" />
>  static="false" />
> 
> 
> 
> 
> 
> 
>   
> 
> {code}
> This code style is also mentioned in the web page here (minus some details 
> which are present in above configuration snippet but not on the web page): 
> [https://cassandra.apache.org/_/development/code_style.html] (at the very 
> bottom).
> However, when one runs "Optimise imports" in the context menu after 
> right-clicking on org.cassandra.apache package, it will refactor the imports 
> and it results with hundreds of changes.
> This means that the source code, as-is, does not adhere to the self-imposed 
> code style we ship for IDEA.
> If we fix this, we should add checkstyle for it like this:
> {code:java}
> 
>value="/(^java\.|javax)/,/(com\.google\.common|org\.apache\.log4j|org\.apache\.commons|org\.cliffc\.high_scale_lib|org\.junit|org\.slf4j)/"/>
>   
>   
>   
>   
>   
> 
> {code}
> This checkstyle on import order will pass on the source code we run the 
> import optimization in the context menu on.
> There is also no enforcement on "all star" imports (org.some.pkg.*). 
> Checkstyle has specific module for this: 
> [https://checkstyle.org/config_imports.html#AvoidStarImport] 
> I propose we should stop to use all-star imports. Same argument holds as 
> described there: Rationale: Importing all classes from a package or static 
> members from a class leads to tight coupling between packages or classes and 
> might lead to problems when a new version of a library introduces name 
> clashes.
> This should be applied to test checktyle as well and the source code should 
> be refactored on imports too.
> This should be done on cassandra-4.1 as well as for trunk.



--
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-17925) Java source code should have sorted imports as defined in the codestyle

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-17925:
--

It seems like a lot of delta for 4.1 at this point, but then again it's just 
imports so I think that's fine, and this looks good.

> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more 
> task remaining to be done - to add checkstyle for imports order and enforce 
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant 
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
> 
>   
> 
> 
> 
>  static="false" />
>  static="false" />
>  static="false" />
>  static="false" />
> 
> 
> 
> 
> 
> 
>   
> 
> {code}
> This code style is also mentioned in the web page here (minus some details 
> which are present in above configuration snippet but not on the web page): 
> [https://cassandra.apache.org/_/development/code_style.html] (at the very 
> bottom).
> However, when one runs "Optimise imports" in the context menu after 
> right-clicking on org.cassandra.apache package, it will refactor the imports 
> and it results with hundreds of changes.
> This means that the source code, as-is, does not adhere to the self-imposed 
> code style we ship for IDEA.
> If we fix this, we should add checkstyle for it like this:
> {code:java}
> 
>value="/(^java\.|javax)/,/(com\.google\.common|org\.apache\.log4j|org\.apache\.commons|org\.cliffc\.high_scale_lib|org\.junit|org\.slf4j)/"/>
>   
>   
>   
>   
>   
> 
> {code}
> This checkstyle on import order will pass on the source code we run the 
> import optimization in the context menu on.
> There is also no enforcement on "all star" imports (org.some.pkg.*). 
> Checkstyle has specific module for this: 
> [https://checkstyle.org/config_imports.html#AvoidStarImport] 
> I propose we should stop to use all-star imports. Same argument holds as 
> described there: Rationale: Importing all classes from a package or static 
> members from a class leads to tight coupling between packages or classes and 
> might lead to problems when a new version of a library introduces name 
> clashes.
> This should be applied to test checktyle as well and the source code should 
> be refactored on imports too.
> This should be done on cassandra-4.1 as well as for trunk.



--
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-17925) Java source code should have sorted imports as defined in the codestyle

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-17925:
--
Description: 
After we cleaned all unused imports in CASSANDRA-17876, there is one more task 
remaining to be done - to add checkstyle for imports order and enforce this on 
build time.

When the project is imported into IDEA, there is a helper target on Ant called 
"generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
{code:java}

  













  

{code}
This code style is also mentioned in the web page here (minus some details 
which are present in above configuration snippet but not on the web page): 
[https://cassandra.apache.org/_/development/code_style.html] (at the very 
bottom).

However, when one runs "Optimise imports" in the context menu after 
right-clicking on org.cassandra.apache package, it will refactor the imports 
and it results with hundreds of changes.

This means that the source code, as-is, does not adhere to the self-imposed 
code style we ship for IDEA.

If we fix this, we should add checkstyle for it like this:
{code:java}

  
  
  
  
  
  

{code}
This checkstyle on import order will pass on the source code we run the import 
optimization in the context menu on.

There is also no enforcement on "all star" imports (org.some.pkg.*). Checkstyle 
has specific module for this: 
[https://checkstyle.org/config_imports.html#AvoidStarImport] 

I propose we should stop to use all-star imports. Same argument holds as 
described there: Rationale: Importing all classes from a package or static 
members from a class leads to tight coupling between packages or classes and 
might lead to problems when a new version of a library introduces name clashes.

This should be applied to test checktyle as well and the source code should be 
refactored on imports too.

This should be done on cassandra-4.1 as well as for trunk.

  was:
After we cleaned all unused imports in CASSANDRA-17876, there is one more task 
remaining to be done - to add checkstyle for imports order and enforce this on 
build time.

When the project is imported into IDEA, there is a helper target on Ant called 
"generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
{code:java}

  













  

{code}
This code style is also mentioned in the web page here (minus some details 
which are present in above configuration snippet but not on the web page): 
[https://cassandra.apache.org/_/development/code_style.html] (at the very 
bottom).

However, when one runs "Optimise imports" in the context menu after 
right-clicking on org.cassandra.apache package, it will refactor all the 
imports which adheres to the above code style with hundreds changes.

This means that the source code, as-is, does not adhere to the self-imposed 
code style we ship for IDEA.

If we fix this, we should add checkstyle for it like this:
{code:java}

  
  
  
  
  
  

{code}
This checkstyle on import order will pass on the source code we run the import 
optimization in the context menu on.

There is also no enforcement on "all star" imports (org.some.pkg.*). Checkstyle 
has specific module for this: 
[https://checkstyle.org/config_imports.html#AvoidStarImport] 

I propose we should stop to use all-star imports. Same argument holds as 
described there: Rationale: Importing all classes from a package or static 
members from a class leads to tight coupling between packages or classes and 
might lead to problems when a new version of a library introduces name clashes.

This should be applied to test checktyle as well and the source code should be 
refactored on imports too.

This should be done on cassandra-4.1 as well as for trunk.


> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more 
> task remaining to be done - to add checkstyle for imports order and enforce 
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant 
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
> 

[jira] [Assigned] (CASSANDRA-17927) Test Failure: org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages[4/v4]-cdc

[Caleb Rackliffe (Jira)]

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

Caleb Rackliffe reassigned CASSANDRA-17927:
---

Assignee: Caleb Rackliffe

> Test Failure: 
> org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages[4/v4]-cdc
>  
> ---
>
> Key: CASSANDRA-17927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17927
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1-beta
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.transport/RateLimitingTest/shouldThrowOnOverloadSmallMessages_4_v4__cdc/]
> Failed 1 times in the last 30 runs. Flakiness: 6%, Stability: 96%
> Error Message
> expected:<0> but was:<316>
> StackTrace
> {code:java}
> junit.framework.AssertionFailedError: expected:<0> but was:<316>
>   at 
> org.apache.cassandra.transport.RateLimitingTest.testOverload(RateLimitingTest.java:198)
>   at 
> org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages(RateLimitingTest.java:111)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}



--
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-17925) Java source code should have sorted imports as defined in the codestyle

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-17925:
---

[~brandon.williams]  what do you think about this? Any opinions?

the branch for initial review is here: 
https://github.com/instaclustr/cassandra/tree/CASSANDRA-17925-4.1

> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more 
> task remaining to be done - to add checkstyle for imports order and enforce 
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant 
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
> 
>   
> 
> 
> 
>  static="false" />
>  static="false" />
>  static="false" />
>  static="false" />
> 
> 
> 
> 
> 
> 
>   
> 
> {code}
> This code style is also mentioned in the web page here (minus some details 
> which are present in above configuration snippet but not on the web page): 
> [https://cassandra.apache.org/_/development/code_style.html] (at the very 
> bottom).
> However, when one runs "Optimise imports" in the context menu after 
> right-clicking on org.cassandra.apache package, it will refactor all the 
> imports which adheres to the above code style with hundreds changes.
> This means that the source code, as-is, does not adhere to the self-imposed 
> code style we ship for IDEA.
> If we fix this, we should add checkstyle for it like this:
> {code:java}
> 
>value="/(^java\.|javax)/,/(com\.google\.common|org\.apache\.log4j|org\.apache\.commons|org\.cliffc\.high_scale_lib|org\.junit|org\.slf4j)/"/>
>   
>   
>   
>   
>   
> 
> {code}
> This checkstyle on import order will pass on the source code we run the 
> import optimization in the context menu on.
> There is also no enforcement on "all star" imports (org.some.pkg.*). 
> Checkstyle has specific module for this: 
> [https://checkstyle.org/config_imports.html#AvoidStarImport] 
> I propose we should stop to use all-star imports. Same argument holds as 
> described there: Rationale: Importing all classes from a package or static 
> members from a class leads to tight coupling between packages or classes and 
> might lead to problems when a new version of a library introduces name 
> clashes.
> This should be applied to test checktyle as well and the source code should 
> be refactored on imports too.
> This should be done on cassandra-4.1 as well as for trunk.



--
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-17926) Test Failure: dtest-novnode.transient_replication_test.TestTransientReplicationRepairLegacyStreaming.test_optimized_primary_range_repair

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17926:
--
Resolution: Duplicate
Status: Resolved  (was: Triage Needed)

> Test Failure: 
> dtest-novnode.transient_replication_test.TestTransientReplicationRepairLegacyStreaming.test_optimized_primary_range_repair
> 
>
> Key: CASSANDRA-17926
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17926
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/dtest-novnode.transient_replication_test/TestTransientReplicationRepairLegacyStreaming/test_optimized_primary_range_repair/]
> Failed 2 times in the last 30 runs. Flakiness: 10%, Stability: 93%
> Error Message
> {code}
> subprocess.CalledProcessError: Command 
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
>  'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 
> '--port', '8778', 'start', '12172')' returned non-zero exit status 1.
> {code}
> Stacktrace
> {code}
>  raise CalledProcessError(retcode, process.args,
> output=stdout, stderr=stderr)
> E   subprocess.CalledProcessError: Command 
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
>  'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 
> '--port', '8778', 'start', '12172')' returned non-zero exit status 1.
> {code}



--
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-16860) Add --older-than option to nodetool clearsnapshot

[Paulo Motta (Jira)]

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

Paulo Motta commented on CASSANDRA-16860:
-

LGTM, nice work!

Did a few manual tests:

* Clear all by timestamp
{noformat}
$ docker exec -it cassandra-server nodetool listsnapshots
Snapshot Details:
Snapshot name Keyspace name Column family name True size Size on disk Creation 
timeExpiration time
tag1  test  bla1 KiB 6 KiB
2022-09-27T15:02:48.089Z
tag2  test  bla1 KiB 6 KiB
2022-09-27T15:03:41.094Z
tag3  test  bla1 KiB 6 KiB
2022-09-27T15:03:51.528Z

Total TrueDiskSpaceUsed: 0 bytes

$ docker exec -it cassandra-server nodetool clearsnapshot 
--older-than-timestamp 2022-09-27T15:02:49.089Z --all
Requested clearing snapshot(s) for [all keyspaces] with [all snapshots] older 
than timestamp 2022-09-27T15:02:49.089Z

$ docker exec -it cassandra-server nodetool listsnapshots
Snapshot Details:
Snapshot name Keyspace name Column family name True size Size on disk Creation 
timeExpiration time
tag2  test  bla1 KiB 6 KiB
2022-09-27T15:03:41.094Z
tag3  test  bla1 KiB 6 KiB
2022-09-27T15:03:51.528Z

Total TrueDiskSpaceUsed: 0 bytes
{noformat}

* Clear all by duration
{noformat}
$ docker exec -it cassandra-server nodetool listsnapshots
Snapshot Details:
Snapshot name Keyspace name Column family name True size Size on disk Creation 
timeExpiration time
tag4  test  bla1 KiB 6 KiB
2022-09-27T15:07:43.631Z
tag2  test  bla1 KiB 6 KiB
2022-09-27T15:03:41.094Z
tag3  test  bla1 KiB 6 KiB
2022-09-27T15:03:51.528Z

Total TrueDiskSpaceUsed: 0 bytes

$ docker exec -it cassandra-server nodetool clearsnapshot --older-than 5m --all
Requested clearing snapshot(s) for [all keyspaces] with [all snapshots] older 
than 300 seconds.
$ docker exec -it cassandra-server nodetool listsnapshots
Snapshot Details:
Snapshot name Keyspace name Column family name True size Size on disk Creation 
timeExpiration time
tag4  test  bla1 KiB 6 KiB
2022-09-27T15:07:43.631Z
{noformat}

* Clear all by duration with TTL
{noformat}
$ docker exec -it cassandra-server nodetool listsnapshots
Snapshot Details:
Snapshot name Keyspace name Column family name True size Size on disk Creation 
timeExpiration time
tag6  test  bla1.02 KiB  6.02 KiB 
2022-09-27T15:11:15.323Z 2022-09-27T15:16:15.323Z
tag4  test  bla1 KiB 6 KiB
2022-09-27T15:07:43.631Z
tag5  test  bla1.02 KiB  6.02 KiB 
2022-09-27T15:10:01.710Z 2022-09-27T15:15:01.710Z

Total TrueDiskSpaceUsed: 0 bytes

$ docker exec -it cassandra-server nodetool clearsnapshot --older-than 1m --all
Requested clearing snapshot(s) for [all keyspaces] with [all snapshots] older 
than 60 seconds.
$ docker exec -it cassandra-server nodetool listsnapshots
Snapshot Details:
Snapshot name Keyspace name Column family name True size Size on disk Creation 
timeExpiration time
tag6  test  bla1.02 KiB  6.02 KiB 
2022-09-27T15:11:15.323Z 2022-09-27T15:16:15.323Z

Total TrueDiskSpaceUsed: 0 bytes
{noformat}

* Clear all by duration and keyspace
{noformat}
$ docker exec -it cassandra-server nodetool listsnapshots
Snapshot Details:
Snapshot name Keyspace name Column family name True size Size on disk Creation 
timeExpiration time
tag6  test2 bla1.02 KiB  5.99 KiB 
2022-09-27T15:22:14.868Z 2022-09-27T15:27:14.868Z
tag7  test  bla1 KiB 6 KiB
2022-09-27T15:22:32.051Z

Total TrueDiskSpaceUsed: 0 bytes

$ docker exec -it cassandra-server nodetool clearsnapshot --older-than 1m --all 
test2
Requested clearing snapshot(s) for [test2] with [all snapshots] older than 60 
seconds.

$ docker exec -it cassandra-server nodetool listsnapshots
Snapshot Details:
Snapshot name Keyspace name Column family name True size Size on disk Creation 
timeExpiration time
tag7  test  bla1 KiB 6 KiB
2022-09-27T15:22:32.051Z

Total TrueDiskSpaceUsed: 0 bytes
{noformat}



> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Local/Snapshots, Tool/nodetool
> 

[jira] [Updated] (CASSANDRA-16860) Add --older-than option to nodetool clearsnapshot

[Paulo Motta (Jira)]

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

Paulo Motta updated CASSANDRA-16860:

Status: Review In Progress  (was: Patch Available)

> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> h1. Summary
> Opening this issue in reference to [this WIP 
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc, 
> based on a TTL. This is to address the problem of snapshots accumulating. For 
> example, an organization I work for aims to keep snapshots for 30 days, 
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in: 
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be 
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the 
> following options:
> NAME
>  nodetool expiresnapshots - Removes snapshots that are older than a TTL
>  in days
> SYNOPSIS
>  nodetool [(-h  | --host )] [(-p  | --port )]
>  [(-pw  | --password )]
>  [(-pwf  | --password-file )]
>  [(-u  | --username )] expiresnapshots [--dry-run]
>  (-t  | --ttl )
> OPTIONS
>  --dry-run
>  Run without actually clearing snapshots
> -h , --host 
>  Node hostname or ip address
> -p , --port 
>  Remote jmx agent port number
> -pw , --password 
>  Remote jmx agent password
> -pwf , --password-file 
>  Path to the JMX password file
> -t , --ttl 
>  TTL (in days) to expire snapshots
> -u , --username 
>  Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps 
> (epoch time in miliseconds). For this reason, snapshot names that don't 
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a 
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
>  Snapshot Details:
>  Snapshot name Keyspace name Column family name True size Size on disk
>  1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
>  Starting simulated cleanup of snapshots older than 30 days
>  Clearing (dry run): 1529173922063
>  Clearing (dry run): 1599173922063
>  Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit 
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
>  Starting cleanup of snapshots older than 30 days
>  Clearing: 1529173922063
>  Clearing: 1599173922063
>  Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still 
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
>  Snapshot Details:
>  Snapshot name Keyspace name Column family name True size Size on disk
>  1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
>  - Tests
>  - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after 
> reading the contribution guide  Any advice on the following would be greatly 
> appreciated!
>  - What branch would this type of change be merged into? Currently, I'm 
> targeting {{apache:trunk}} by default
>  - Is there a test strategy/pattern for this type of change? I was not able 
> to find any existing tests for similar {{nodetool}} commands
> Thanks! 



--
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-17929) Test Failure: dtest-offheap.client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote.test_batch_and_slice

[Josh McKenzie (Jira)]

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

Josh McKenzie commented on CASSANDRA-17929:
---

Good call - thanks!

> Test Failure: 
> dtest-offheap.client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote.test_batch_and_slice
> -
>
> Key: CASSANDRA-17929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/dtest-offheap.client_request_metrics_local_remote_test/TestClientRequestMetricsLocalRemote/test_batch_and_slice/]
> Error Message
> {code}
> subprocess.CalledProcessError: Command 
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
>  'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 
> '--port', '8778', 'start', '2026')' returned non-zero exit status 1.
> {code}
> Stacktrace
> {code}
>if check and retcode:
>  raise CalledProcessError(retcode, process.args,
> output=stdout, stderr=stderr)
> E   subprocess.CalledProcessError: Command 
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
>  'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 
> '--port', '8778', 'start', '2026')' returned non-zero exit status 1.
> /usr/lib/python3.8/subprocess.py:516: CalledProcessError
> {code}



--
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-16860) Add --older-than option to nodetool clearsnapshot

[Paulo Motta (Jira)]

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

Paulo Motta updated CASSANDRA-16860:

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

> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> h1. Summary
> Opening this issue in reference to [this WIP 
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc, 
> based on a TTL. This is to address the problem of snapshots accumulating. For 
> example, an organization I work for aims to keep snapshots for 30 days, 
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in: 
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be 
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the 
> following options:
> NAME
>  nodetool expiresnapshots - Removes snapshots that are older than a TTL
>  in days
> SYNOPSIS
>  nodetool [(-h  | --host )] [(-p  | --port )]
>  [(-pw  | --password )]
>  [(-pwf  | --password-file )]
>  [(-u  | --username )] expiresnapshots [--dry-run]
>  (-t  | --ttl )
> OPTIONS
>  --dry-run
>  Run without actually clearing snapshots
> -h , --host 
>  Node hostname or ip address
> -p , --port 
>  Remote jmx agent port number
> -pw , --password 
>  Remote jmx agent password
> -pwf , --password-file 
>  Path to the JMX password file
> -t , --ttl 
>  TTL (in days) to expire snapshots
> -u , --username 
>  Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps 
> (epoch time in miliseconds). For this reason, snapshot names that don't 
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a 
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
>  Snapshot Details:
>  Snapshot name Keyspace name Column family name True size Size on disk
>  1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
>  Starting simulated cleanup of snapshots older than 30 days
>  Clearing (dry run): 1529173922063
>  Clearing (dry run): 1599173922063
>  Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit 
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
>  Starting cleanup of snapshots older than 30 days
>  Clearing: 1529173922063
>  Clearing: 1599173922063
>  Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still 
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
>  Snapshot Details:
>  Snapshot name Keyspace name Column family name True size Size on disk
>  1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
>  1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
>  - Tests
>  - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after 
> reading the contribution guide  Any advice on the following would be greatly 
> appreciated!
>  - What branch would this type of change be merged into? Currently, I'm 
> targeting {{apache:trunk}} by default
>  - Is there a test strategy/pattern for this type of change? I was not able 
> to find any existing tests for similar {{nodetool}} commands
> Thanks! 



--
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-17927) Test Failure: org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages[4/v4]-cdc

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17927:
--
Fix Version/s: 4.1-beta

> Test Failure: 
> org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages[4/v4]-cdc
>  
> ---
>
> Key: CASSANDRA-17927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17927
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.1-beta
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.transport/RateLimitingTest/shouldThrowOnOverloadSmallMessages_4_v4__cdc/]
> Failed 1 times in the last 30 runs. Flakiness: 6%, Stability: 96%
> Error Message
> expected:<0> but was:<316>
> StackTrace
> {code:java}
> junit.framework.AssertionFailedError: expected:<0> but was:<316>
>   at 
> org.apache.cassandra.transport.RateLimitingTest.testOverload(RateLimitingTest.java:198)
>   at 
> org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages(RateLimitingTest.java:111)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}



--
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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17928:
--
Fix Version/s: 4.1-beta

> Test Failure: 
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.1-beta
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code}
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> {code}



--
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-17929) Test Failure: dtest-offheap.client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote.test_batch_and_slice

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-17929:
-
Resolution: Duplicate
Status: Resolved  (was: Triage Needed)

> Test Failure: 
> dtest-offheap.client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote.test_batch_and_slice
> -
>
> Key: CASSANDRA-17929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/dtest-offheap.client_request_metrics_local_remote_test/TestClientRequestMetricsLocalRemote/test_batch_and_slice/]
> Error Message
> {code}
> subprocess.CalledProcessError: Command 
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
>  'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 
> '--port', '8778', 'start', '2026')' returned non-zero exit status 1.
> {code}
> Stacktrace
> {code}
>if check and retcode:
>  raise CalledProcessError(retcode, process.args,
> output=stdout, stderr=stderr)
> E   subprocess.CalledProcessError: Command 
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
>  'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 
> '--port', '8778', 'start', '2026')' returned non-zero exit status 1.
> /usr/lib/python3.8/subprocess.py:516: CalledProcessError
> {code}



--
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-17103) CEP-15 (C*): Messaging and storage engine integration

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17103:
--
Description: This work encompasses implementing Accord’s storage and 
networking interfaces within Cassandra, so that messages may be sent around the 
cluster and executed  (was: This work encompasses implementing Accord’s storage 
and networking interfaces within Cassandra, so that messages may be sent around 
the cluster and exectuted
)

> CEP-15 (C*): Messaging and storage engine integration
> -
>
> Key: CASSANDRA-17103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17103
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 5.x
>
>
> This work encompasses implementing Accord’s storage and networking interfaces 
> within Cassandra, so that messages may be sent around the cluster and executed



--
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-17929) Test Failure: dtest-offheap.client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote.test_batch_and_slice

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-17929 at 9/27/22 3:23 PM:
--

[~jmckenzie], I think this can be considered duplicate, same as 
CASSANDRA-17926. and the ticket [~brandonwilliams] opened to handle the general 
Jolokia issue yesterday - CASSANDRA-17922? 


was (Author: e.dimitrova):
I think this can be considered duplicate, same as CASSANDRA-17926. and the 
ticket [~brandonwilliams] opened to handle the general Jolokia issue yesterday 
- CASSANDRA-17922? 

> Test Failure: 
> dtest-offheap.client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote.test_batch_and_slice
> -
>
> Key: CASSANDRA-17929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/dtest-offheap.client_request_metrics_local_remote_test/TestClientRequestMetricsLocalRemote/test_batch_and_slice/]
> Error Message
> {code}
> subprocess.CalledProcessError: Command 
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
>  'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 
> '--port', '8778', 'start', '2026')' returned non-zero exit status 1.
> {code}
> Stacktrace
> {code}
>if check and retcode:
>  raise CalledProcessError(retcode, process.args,
> output=stdout, stderr=stderr)
> E   subprocess.CalledProcessError: Command 
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
>  'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 
> '--port', '8778', 'start', '2026')' returned non-zero exit status 1.
> /usr/lib/python3.8/subprocess.py:516: CalledProcessError
> {code}



--
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-17929) Test Failure: dtest-offheap.client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote.test_batch_and_slice

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-17929:
-

I think this can be considered duplicate, same as CASSANDRA-17926. and the 
ticket [~brandonwilliams] opened to handle the general Jolokia issue yesterday 
- CASSANDRA-17922? 

> Test Failure: 
> dtest-offheap.client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote.test_batch_and_slice
> -
>
> Key: CASSANDRA-17929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17929
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/dtest-offheap.client_request_metrics_local_remote_test/TestClientRequestMetricsLocalRemote/test_batch_and_slice/]
> Error Message
> {code}
> subprocess.CalledProcessError: Command 
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
>  'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 
> '--port', '8778', 'start', '2026')' returned non-zero exit status 1.
> {code}
> Stacktrace
> {code}
>if check and retcode:
>  raise CalledProcessError(retcode, process.args,
> output=stdout, stderr=stderr)
> E   subprocess.CalledProcessError: Command 
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
>  'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', 
> '--port', '8778', 'start', '2026')' returned non-zero exit status 1.
> /usr/lib/python3.8/subprocess.py:516: CalledProcessError
> {code}



--
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-17929) Test Failure: dtest-offheap.client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote.test_batch_and_slice

[Josh McKenzie (Jira)]

Josh McKenzie created CASSANDRA-17929:
-

 Summary: Test Failure: 
dtest-offheap.client_request_metrics_local_remote_test.TestClientRequestMetricsLocalRemote.test_batch_and_slice
 Key: CASSANDRA-17929
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17929
 Project: Cassandra
  Issue Type: Bug
  Components: Test/unit
Reporter: Josh McKenzie


[Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/dtest-offheap.client_request_metrics_local_remote_test/TestClientRequestMetricsLocalRemote/test_batch_and_slice/]

Error Message
{code}
subprocess.CalledProcessError: Command 
'('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
'/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
 'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', '--port', 
'8778', 'start', '2026')' returned non-zero exit status 1.
{code}

Stacktrace
{code}
   if check and retcode:
 raise CalledProcessError(retcode, process.args,
output=stdout, stderr=stderr)
E   subprocess.CalledProcessError: Command 
'('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
'/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
 'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', '--port', 
'8778', 'start', '2026')' returned non-zero exit status 1.

/usr/lib/python3.8/subprocess.py:516: CalledProcessError
{code}



--
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-17927) Test Failure: org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages[4/v4]-cdc

[Josh McKenzie (Jira)]

Josh McKenzie created CASSANDRA-17927:
-

 Summary: Test Failure: 
org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages[4/v4]-cdc
 
 Key: CASSANDRA-17927
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17927
 Project: Cassandra
  Issue Type: Bug
  Components: Test/unit
Reporter: Josh McKenzie


[Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.transport/RateLimitingTest/shouldThrowOnOverloadSmallMessages_4_v4__cdc/]

Failed 1 times in the last 30 runs. Flakiness: 6%, Stability: 96%

Error Message
expected:<0> but was:<316>

StackTrace
{code:java}
junit.framework.AssertionFailedError: expected:<0> but was:<316>
at 
org.apache.cassandra.transport.RateLimitingTest.testOverload(RateLimitingTest.java:198)
at 
org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages(RateLimitingTest.java:111)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}



--
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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression

[Josh McKenzie (Jira)]

Josh McKenzie created CASSANDRA-17928:
-

 Summary: Test Failure: 
org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
 Key: CASSANDRA-17928
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
 Project: Cassandra
  Issue Type: Bug
  Components: Test/unit
Reporter: Josh McKenzie


[Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]

Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%

Stacktrace
{code}
java.lang.NullPointerException
at 
org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.lang.Thread.run(Thread.java:829)
{code}



--
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-17926) Test Failure: dtest-novnode.transient_replication_test.TestTransientReplicationRepairLegacyStreaming.test_optimized_primary_range_repair

[Josh McKenzie (Jira)]

Josh McKenzie created CASSANDRA-17926:
-

 Summary: Test Failure: 
dtest-novnode.transient_replication_test.TestTransientReplicationRepairLegacyStreaming.test_optimized_primary_range_repair
 Key: CASSANDRA-17926
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17926
 Project: Cassandra
  Issue Type: Bug
  Components: Test/dtest/python
Reporter: Josh McKenzie


[Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/dtest-novnode.transient_replication_test/TestTransientReplicationRepairLegacyStreaming/test_optimized_primary_range_repair/]

Failed 2 times in the last 30 runs. Flakiness: 10%, Stability: 93%

Error Message
{code}
subprocess.CalledProcessError: Command 
'('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
'/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
 'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', '--port', 
'8778', 'start', '12172')' returned non-zero exit status 1.
{code}

Stacktrace
{code}
 raise CalledProcessError(retcode, process.args,
output=stdout, stderr=stderr)
E   subprocess.CalledProcessError: Command 
'('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '-cp', 
'/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
 'org.jolokia.jvmagent.client.AgentLauncher', '--host', '127.0.0.1', '--port', 
'8778', 'start', '12172')' returned non-zero exit status 1.
{code}



--
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-17709) CQL.textile needs to be made current

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-17709:
--

+1 from me, there are some minor formatting fixes for which I left comments.

> CQL.textile needs to be made current
> 
>
> Key: CASSANDRA-17709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17709
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/CQL
>Reporter: Brandon Williams
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1-rc
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Per CASSANDRA-17570 
> https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile is 
> outdated, and the document we ship inside packages, so this should be made 
> current.



--
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-17880) RPM noboolean packages deployed in place of others

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-17880:
---
  Fix Version/s: 4.0.7
 4.1-beta
 4.1
 4.2
Source Control Link: 
https://github.com/apache/cassandra-builds/commit/c07e4728a1f21b77f9a4fcdf255c434ec6716aaa
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed as 
[c07e4728a1f21b77f9a4fcdf255c434ec6716aaa|https://github.com/apache/cassandra-builds/commit/c07e4728a1f21b77f9a4fcdf255c434ec6716aaa].

> RPM noboolean packages deployed in place of others
> --
>
> Key: CASSANDRA-17880
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17880
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Brandon Williams
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.7, 4.1-beta, 4.1, 4.2
>
>
> In CASSANDRA-17765 we created the 'noboolean' packages for distros unable to 
> understand boolean dependency logic, but it appears these are the only 
> packages deployed for download - once as noboolean packages, and once as 
> standard packages.



--
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-17880) RPM noboolean packages deployed in place of others

[Michael Semb Wever (Jira)]

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

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

> RPM noboolean packages deployed in place of others
> --
>
> Key: CASSANDRA-17880
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17880
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Brandon Williams
>Assignee: Michael Semb Wever
>Priority: Normal
>
> In CASSANDRA-17765 we created the 'noboolean' packages for distros unable to 
> understand boolean dependency logic, but it appears these are the only 
> packages deployed for download - once as noboolean packages, and once as 
> standard packages.



--
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-17880) RPM noboolean packages deployed in place of others

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-17880:
---
Reviewers: Brandon Williams, Michael Semb Wever  (was: Brandon Williams)
   Status: Review In Progress  (was: Patch Available)

> RPM noboolean packages deployed in place of others
> --
>
> Key: CASSANDRA-17880
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17880
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Brandon Williams
>Assignee: Michael Semb Wever
>Priority: Normal
>
> In CASSANDRA-17765 we created the 'noboolean' packages for distros unable to 
> understand boolean dependency logic, but it appears these are the only 
> packages deployed for download - once as noboolean packages, and once as 
> standard packages.



--
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-builds] branch trunk updated: When cutting a release, and having built rpm noboolean packages, copy files separately

[mck]

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new c07e472  When cutting a release, and having built rpm noboolean 
packages, copy files separately
c07e472 is described below

commit c07e4728a1f21b77f9a4fcdf255c434ec6716aaa
Author: Mick Semb Wever 
AuthorDate: Tue Sep 13 00:34:24 2022 +0200

When cutting a release, and having built rpm noboolean packages, copy files 
separately

 patch by Mick Semb Wever; reviewed by Brandon Williams for CASSANDRA-17880
---
 cassandra-release/prepare_release.sh | 36 
 1 file changed, 16 insertions(+), 20 deletions(-)

diff --git a/cassandra-release/prepare_release.sh 
b/cassandra-release/prepare_release.sh
index b3666e9..6beedff 100755
--- a/cassandra-release/prepare_release.sh
+++ b/cassandra-release/prepare_release.sh
@@ -325,6 +325,8 @@ then
 execute "mkdir -p $rpm_package_dir"
 execute "cd $rpm_package_dir"
 
+echo "Building redhat packages ..." 1>&3 2>&4
+
 [ $fake_mode -eq 1 ] && echo ">> declare -x 
rpm_dir=$rpm_package_dir/cassandra_${release}_rpm"
 declare -x rpm_dir=$rpm_package_dir/cassandra_${release}_rpm
 [ ! -e "$rpm_dir" ] || rm -rf $rpm_dir
@@ -334,6 +336,16 @@ then
 
 execute "rpmsign --addsign ${rpm_dir}/*.rpm"
 
+# build repositories
+echo "Building redhat repository ..." 1>&3 2>&4
+execute "mkdir $tmp_dir/cassandra-dist-dev/${release}/redhat"
+execute "cp ${rpm_dir}/*.rpm  
$tmp_dir/cassandra-dist-dev/${release}/redhat/"
+execute "cd $tmp_dir/cassandra-dist-dev/${release}/redhat/"
+execute "createrepo ."
+# FIXME - put into execute "…"
+[ $fake_mode -eq 1 ] || for f in repodata/repomd.xml repodata/*.bz2 
repodata/*.gz ; do gpg --detach-sign --armor $f ; done
+
+
 # noboolean RPMs
 if [ -d "$current_dir/redhat/noboolean" ]; then
 execute "cd $tmp_dir"
@@ -341,6 +353,8 @@ then
 execute "mkdir -p $rpmnoboolean_package_dir"
 execute "cd $rpmnoboolean_package_dir"
 
+echo "Building redhat noboolean packages ..." 1>&3 2>&4
+
 [ $fake_mode -eq 1 ] && echo ">> declare -x 
rpm_dir=$rpmnoboolean_package_dir/cassandra_${release}_rpmnoboolean"
 declare -x 
rpm_dir=$rpmnoboolean_package_dir/cassandra_${release}_rpmnoboolean
 [ ! -e "$rpm_dir" ] || rm -rf $rpm_dir
@@ -349,31 +363,13 @@ then
 execute 
"${cassandra_builds_dir}/build-scripts/cassandra-rpm-packaging.sh 
${release}-tentative 8 noboolean"
 
 execute "rpmsign --addsign ${rpm_dir}/*.rpm"
-fi
-
-# build repositories
-execute "cd $tmp_dir"
 
-execute "mkdir $tmp_dir/cassandra-dist-dev/${release}/redhat"
-execute "cp ${rpm_dir}/*.rpm  
$tmp_dir/cassandra-dist-dev/${release}/redhat/"
-
-if [ -d "$current_dir/redhat/noboolean" ]; then
+# build repositories
+echo "Building redhat noboolean repository ..." 1>&3 2>&4
 execute "mkdir $tmp_dir/cassandra-dist-dev/${release}/redhat/noboolean"
 execute "cp ${rpm_dir}/*.rpm  
$tmp_dir/cassandra-dist-dev/${release}/redhat/noboolean"
-fi
-
-echo "Building redhat repository ..." 1>&3 2>&4
-
-execute "cd $tmp_dir/cassandra-dist-dev/${release}/redhat/"
-execute "createrepo ."
-
-# FIXME - put into execute "…"
-[ $fake_mode -eq 1 ] || for f in repodata/repomd.xml repodata/*.bz2 
repodata/*.gz ; do gpg --detach-sign --armor $f ; done
-
-if [ -d "$current_dir/redhat/noboolean" ]; then
 execute "cd $tmp_dir/cassandra-dist-dev/${release}/redhat/noboolean"
 execute "createrepo ."
-
 # FIXME - put into execute "…"
 [ $fake_mode -eq 1 ] || for f in repodata/repomd.xml repodata/*.bz2 
repodata/*.gz ; do gpg --detach-sign --armor $f ; done
 fi


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

[jira] [Updated] (CASSANDRA-17709) CQL.textile needs to be made current

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-17709:
-
Reviewers: Brandon Williams, Brandon Williams
   Brandon Williams, Brandon Williams  (was: Brandon Williams)
   Status: Review In Progress  (was: Patch Available)

> CQL.textile needs to be made current
> 
>
> Key: CASSANDRA-17709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17709
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/CQL
>Reporter: Brandon Williams
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1-rc
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Per CASSANDRA-17570 
> https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile is 
> outdated, and the document we ship inside packages, so this should be made 
> current.



--
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-17880) RPM noboolean packages deployed in place of others

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-17880:
--

Verified the deployment of the 4.1 test artifacts, everything is correct.

> RPM noboolean packages deployed in place of others
> --
>
> Key: CASSANDRA-17880
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17880
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Brandon Williams
>Assignee: Michael Semb Wever
>Priority: Normal
>
> In CASSANDRA-17765 we created the 'noboolean' packages for distros unable to 
> understand boolean dependency logic, but it appears these are the only 
> packages deployed for download - once as noboolean packages, and once as 
> standard packages.



--
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-17880) RPM noboolean packages deployed in place of others

[Michael Semb Wever (Jira)]

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

Michael Semb Wever updated CASSANDRA-17880:
---
Test and Documentation Plan: tested with the cut of 4.1-beta1
 Status: Patch Available  (was: In Progress)

> RPM noboolean packages deployed in place of others
> --
>
> Key: CASSANDRA-17880
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17880
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Brandon Williams
>Assignee: Michael Semb Wever
>Priority: Normal
>
> In CASSANDRA-17765 we created the 'noboolean' packages for distros unable to 
> understand boolean dependency logic, but it appears these are the only 
> packages deployed for download - once as noboolean packages, and once as 
> standard packages.



--
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-17884) Test failure: o.a.c.repair.RepairJobTest.testNoTreesRetainedAfterDifference

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-17884 at 9/27/22 12:53 PM:
---

-I actually tried an unreleased in maven central jamm jar with the mid 
resources and this time I didn't see the issue. I will try one more run to 
confirm that the issue was solved and I am not missing anything.-

This is the 
[branch|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:17884-4.0-hack]
 where I added a jar including [this 
commit|https://github.com/jbellis/jamm/commit/33d78c1035211e5f9e69ad9247f3a0f6ef75c923]
 (this is not the latest work in the repo though) which was supposed to solve 
that issues with JDK11 according to the author commit message in the jamm repo.

It seems it didn't and we are missing something else to filter. - 
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1955/workflows/20b3aa2c-fefd-42df-8ad0-b787add2fbb1/jobs/15494/steps]
I added annoying print in the jamm code and verified it is printed in the 
CircleCI logs to ensure nothing went wrong and we use the new jar I plugged in.

I also think we need to get back to the repo 
[TreePrint|https://github.com/ekaterinadimitrova2/jamm/blob/33d78c1035211e5f9e69ad9247f3a0f6ef75c923/src/org/github/jamm/TreePrinter.java]
 class as I think it is really useful for debugging. Others think in the same 
way. If we feel it lacks some testing, better to add that than to remove it 
completely.


was (Author: e.dimitrova):
I actually tried an unreleased in maven central jamm jar with the mid resources 
and this time I didn't see the issue. I will try one more run to confirm that 
the issue was solved and I am not missing anything.

This is the 
[branch|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:17884-4.0-hack]
 where I added a jar including [this 
commit|https://github.com/jbellis/jamm/commit/33d78c1035211e5f9e69ad9247f3a0f6ef75c923]
 (this is not the latest work in the repo though) which was supposed to solve 
that issues with JDK11 according to the author commit message in the jamm repo. 

It seems it didn't and we are missing something else to filter. - 
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1955/workflows/20b3aa2c-fefd-42df-8ad0-b787add2fbb1/jobs/15494/steps
I added annoying print in the jamm code and verified it is printed in the 
CircleCI logs to ensure nothing went wrong and we use the new jar I plugged in.

I also think we need to get back to the repo 
[TreePrint|https://github.com/ekaterinadimitrova2/jamm/blob/33d78c1035211e5f9e69ad9247f3a0f6ef75c923/src/org/github/jamm/TreePrinter.java]
 class as I think it is really useful for debugging. Others think in the same 
way. If we feel it lacks some testing, better to add that than to remove it 
completely.  

> Test failure: o.a.c.repair.RepairJobTest.testNoTreesRetainedAfterDifference
> ---
>
> Key: CASSANDRA-17884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17884
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> The unit test 
> {{org.apache.cassandra.repair.RepairJobTest#testNoTreesRetainedAfterDifference}}
>  seems to be slightly flaky at least in 4.0. We haven't seen it failing on 
> Butler, but after [a failure on a patch 
> branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/281/workflows/e6094c00-b611-4772-9772-205f4c76ecba/jobs/2126/tests],
>  this repeated run shows a 0.28% flakiness:
> * 
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2076/workflows/8adbfe99-afb5-43af-84ad-43df2a2a86e2/jobs/20816/tests
> * 
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2076/workflows/e550d8c2-7c35-4326-bd95-6909978d344b/jobs/20817/tests
> {code}
> java.lang.reflect.InaccessibleObjectException: Unable to make field private 
> jdk.internal.platform.cgroupv1.SubSystem$MemorySubSystem 
> jdk.internal.platform.cgroupv1.Metrics.memory accessible: module java.base 
> does not "opens jdk.internal.platform.cgroupv1" to unnamed module @157853da
>   at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
>   at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
>   at 
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:176)
>   at java.base/java.lang.reflect.Field.setAccessible(Field.java:170)
>   at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:330)
>   at 

[jira] [Updated] (CASSANDRA-17709) CQL.textile needs to be made current

[Benjamin Lerer (Jira)]

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

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

> CQL.textile needs to be made current
> 
>
> Key: CASSANDRA-17709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17709
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/CQL
>Reporter: Brandon Williams
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Per CASSANDRA-17570 
> https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile is 
> outdated, and the document we ship inside packages, so this should be made 
> current.



--
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-17709) CQL.textile needs to be made current

[Benjamin Lerer (Jira)]

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

Benjamin Lerer updated CASSANDRA-17709:
---
Fix Version/s: 3.11.x

> CQL.textile needs to be made current
> 
>
> Key: CASSANDRA-17709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17709
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/CQL
>Reporter: Brandon Williams
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1-rc
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Per CASSANDRA-17570 
> https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile is 
> outdated, and the document we ship inside packages, so this should be made 
> current.



--
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-17709) CQL.textile needs to be made current

[Benjamin Lerer (Jira)]

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

Benjamin Lerer edited comment on CASSANDRA-17709 at 9/27/22 12:41 PM:
--

||Branch||
|[3.11|https://github.com/apache/cassandra/pull/1885]|
|[4.0|https://github.com/apache/cassandra/pull/1886]|
|[4.1|https://github.com/apache/cassandra/pull/1887]|


was (Author: blerer):
||Branch||
|​[3.11\|[https://github.com/apache/cassandra/pull/1885]]|
|[4.0|https://github.com/apache/cassandra/pull/1886]|
|[4.11|https://github.com/apache/cassandra/pull/1887]|

> CQL.textile needs to be made current
> 
>
> Key: CASSANDRA-17709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17709
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/CQL
>Reporter: Brandon Williams
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Per CASSANDRA-17570 
> https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile is 
> outdated, and the document we ship inside packages, so this should be made 
> current.



--
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-17709) CQL.textile needs to be made current

[Benjamin Lerer (Jira)]

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

Benjamin Lerer commented on CASSANDRA-17709:


||Branch||
|​[3.11\|[https://github.com/apache/cassandra/pull/1885]]|
|[4.0|https://github.com/apache/cassandra/pull/1886]|
|[4.11|https://github.com/apache/cassandra/pull/1887]|

> CQL.textile needs to be made current
> 
>
> Key: CASSANDRA-17709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17709
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/CQL
>Reporter: Brandon Williams
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Per CASSANDRA-17570 
> https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile is 
> outdated, and the document we ship inside packages, so this should be made 
> current.



--
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-17807) WEBSITE - Replace Plausible with Matomo (website analytics)

[Martijn Visser (Jira)]

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

Martijn Visser commented on CASSANDRA-17807:


I cam across this ticket accidentally, let me know if you need any help (I'm a 
volunteer who has worked on setting up Matomo for the ASF)

> WEBSITE - Replace Plausible with Matomo (website analytics)
> ---
>
> Key: CASSANDRA-17807
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17807
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Michael Semb Wever
>Priority: Normal
> Fix For: 4.x
>
>
> Our hosted Plausible can and should be replaced with ASF's hosted Matomo.
> See https://privacy.apache.org/
> Specifically
> - https://privacy.apache.org/policies/privacy-policy-public.html
> - https://privacy.apache.org/faq/committers.html
> - https://privacy.apache.org/matomo/



--
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-17884) Test failure: o.a.c.repair.RepairJobTest.testNoTreesRetainedAfterDifference

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-17884:
-

I actually tried an unreleased in maven central jamm jar with the mid resources 
and this time I didn't see the issue. I will try one more run to confirm that 
the issue was solved and I am not missing anything.

This is the 
[branch|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:17884-4.0-hack]
 where I added a jar including [this 
commit|https://github.com/jbellis/jamm/commit/33d78c1035211e5f9e69ad9247f3a0f6ef75c923]
 (this is not the latest work in the repo though) which was supposed to solve 
that issues with JDK11 according to the author commit message in the jamm repo. 

It seems it didn't and we are missing something else to filter. - 
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1955/workflows/20b3aa2c-fefd-42df-8ad0-b787add2fbb1/jobs/15494/steps
I added annoying print in the jamm code and verified it is printed in the 
CircleCI logs to ensure nothing went wrong and we use the new jar I plugged in.

I also think we need to get back to the repo 
[TreePrint|https://github.com/ekaterinadimitrova2/jamm/blob/33d78c1035211e5f9e69ad9247f3a0f6ef75c923/src/org/github/jamm/TreePrinter.java]
 class as I think it is really useful for debugging. Others think in the same 
way. If we feel it lacks some testing, better to add that than to remove it 
completely.  

> Test failure: o.a.c.repair.RepairJobTest.testNoTreesRetainedAfterDifference
> ---
>
> Key: CASSANDRA-17884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17884
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> The unit test 
> {{org.apache.cassandra.repair.RepairJobTest#testNoTreesRetainedAfterDifference}}
>  seems to be slightly flaky at least in 4.0. We haven't seen it failing on 
> Butler, but after [a failure on a patch 
> branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/281/workflows/e6094c00-b611-4772-9772-205f4c76ecba/jobs/2126/tests],
>  this repeated run shows a 0.28% flakiness:
> * 
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2076/workflows/8adbfe99-afb5-43af-84ad-43df2a2a86e2/jobs/20816/tests
> * 
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2076/workflows/e550d8c2-7c35-4326-bd95-6909978d344b/jobs/20817/tests
> {code}
> java.lang.reflect.InaccessibleObjectException: Unable to make field private 
> jdk.internal.platform.cgroupv1.SubSystem$MemorySubSystem 
> jdk.internal.platform.cgroupv1.Metrics.memory accessible: module java.base 
> does not "opens jdk.internal.platform.cgroupv1" to unnamed module @157853da
>   at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
>   at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
>   at 
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:176)
>   at java.base/java.lang.reflect.Field.setAccessible(Field.java:170)
>   at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:330)
>   at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:269)
>   at 
> org.apache.cassandra.utils.ObjectSizes.measureDeep(ObjectSizes.java:216)
>   at 
> org.apache.cassandra.repair.RepairJobTest.testNoTreesRetainedAfterDifference(RepairJobTest.java:271)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Flakiness is really low but the failure is clearly reproducible in j11.



--
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-website] branch asf-staging updated (8f1290ec3 -> 5c3f8156a)

[git-site-role]

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

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


 discard 8f1290ec3 generate docs for 2db0aea2
 new 5c3f8156a generate docs for 2db0aea2

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

 * -- * -- B -- O -- O -- O   (8f1290ec3)
\
 N -- N -- N   refs/heads/asf-staging (5c3f8156a)

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

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

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


Summary of changes:
 content/search-index.js |   2 +-
 site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes
 2 files changed, 1 insertion(+), 1 deletion(-)


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

[jira] [Updated] (CASSANDRA-17925) Java source code should have sorted imports as defined in the codestyle

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-17925:
--
Description: 
After we cleaned all unused imports in CASSANDRA-17876, there is one more task 
remaining to be done - to add checkstyle for imports order and enforce this on 
build time.

When the project is imported into IDEA, there is a helper target on Ant called 
"generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
{code:java}

  













  

{code}
This code style is also mentioned in the web page here (minus some details 
which are present in above configuration snippet but not on the web page): 
[https://cassandra.apache.org/_/development/code_style.html] (at the very 
bottom).

However, when one runs "Optimise imports" in the context menu after 
right-clicking on org.cassandra.apache package, it will refactor all the 
imports which adheres to the above code style with hundreds changes.

This means that the source code, as-is, does not adhere to the self-imposed 
code style we ship for IDEA.

If we fix this, we should add checkstyle for it like this:
{code:java}

  
  
  
  
  
  

{code}
This checkstyle on import order will pass on the source code we run the import 
optimization in the context menu on.

There is also no enforcement on "all star" imports (org.some.pkg.*). Checkstyle 
has specific module for this: 
[https://checkstyle.org/config_imports.html#AvoidStarImport] 

I propose we should stop to use all-star imports. Same argument holds as 
described there: Rationale: Importing all classes from a package or static 
members from a class leads to tight coupling between packages or classes and 
might lead to problems when a new version of a library introduces name clashes.

This should be applied to test checktyle as well and the source code should be 
refactored on imports too.

This should be done on cassandra-4.1 as well as for trunk.

  was:
After we cleaned all unused imports in CASSANDRA-17876, there is one more task 
remaining to be done - to add checkstyle for imports order and enforce this on 
build time.

When the project is imported into IDEA, there is a helper target on Ant called 
"generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
{code:java}

  













  

{code}
This code style is also mentioned in the webpage here (minus some details which 
are present in above configuration snippet but not on the webpage): 
[https://cassandra.apache.org/_/development/code_style.html] (at the very 
bottom).

However, when one runs "Optimise imports" in the context menu after 
right-clicking on org.cassandra.apache package, it will refactor all the 
imports which adheres to the above codestyle with hundreds or changes.

This means that the source code, as-is, does not adhere to the self-imposed 
code style we ship for IDEA.

If we fix this, we should add checkstyle for it like this:
{code:java}

  
  
  
  
  
  

{code}
This checkstyle on import order will pass on the source code we run the import 
optimization in the context menu on.

There is also no enforcement on "all star" imports (org.some.pkg.*). Checkstyle 
has specific module for this: 
[https://checkstyle.org/config_imports.html#AvoidStarImport] 

I propose we should stop to use all-star imports. Same argument holds as 
described there: Rationale: Importing all classes from a package or static 
members from a class leads to tight coupling between packages or classes and 
might lead to problems when a new version of a library introduces name clashes.

This should be applied to test checktyle as well and the source code should be 
refactored on imports too.

This should be done on cassandra-4.1 as well as for trunk.


> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more 
> task remaining to be done - to add checkstyle for imports order and enforce 
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant 
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:

[jira] [Updated] (CASSANDRA-17925) Java source code should have sorted imports as defined in the codestyle

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-17925:
--
Description: 
After we cleaned all unused imports in CASSANDRA-17876, there is one more task 
remaining to be done - to add checkstyle for imports order and enforce this on 
build time.

When the project is imported into IDEA, there is a helper target on Ant called 
"generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
{code:java}

  













  

{code}
This code style is also mentioned in the webpage here (minus some details which 
are present in above configuration snippet but not on the webpage): 
[https://cassandra.apache.org/_/development/code_style.html] (at the very 
bottom).

However, when one runs "Optimise imports" in the context menu after 
right-clicking on org.cassandra.apache package, it will refactor all the 
imports which adheres to the above codestyle with hundreds or changes.

This means that the source code, as-is, does not adhere to the self-imposed 
code style we ship for IDEA.

If we fix this, we should add checkstyle for it like this:
{code:java}

  
  
  
  
  
  

{code}
This checkstyle on import order will pass on the source code we run the import 
optimization in the context menu on.

There is also no enforcement on "all star" imports (org.some.pkg.*). Checkstyle 
has specific module for this: 
[https://checkstyle.org/config_imports.html#AvoidStarImport] 

I propose we should stop to use all-star imports. Same argument holds as 
described there: Rationale: Importing all classes from a package or static 
members from a class leads to tight coupling between packages or classes and 
might lead to problems when a new version of a library introduces name clashes.

This should be applied to test checktyle as well and the source code should be 
refactored on imports too.

This should be done on cassandra-4.1 as well as for trunk.

  was:
After we cleaned all unused imports in CASSANDRA-17876, there is one more task 
remaining to be done - to add checkstyle for imports order and enforce this on 
build time.

When the project is imported into IDEA, there is a helper target on Ant called 
"generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
{code:java}

  













  

{code}
However, when one runs "Optimise imports" in the context menu after 
right-clicking on org.cassandra.apache package, it will refactor all the 
imports which adheres to the above codestyle with hundreds or changes.

This means that the source code, as-is, does not adhere to the self-imposed 
code style we ship for IDEA.

If we fix this, we should add checkstyle for it like this:
{code:java}

  
  
  
  
  
  

{code}
This checkstyle on import order will pass on the source code we run the import 
optimisation in the context menu on.

This should be applied to test checktyle as well and the source code should be 
refactored on imports too.

This should be done on cassandra-4.1 as well as for trunk.


> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more 
> task remaining to be done - to add checkstyle for imports order and enforce 
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant 
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
> 
>   
> 
> 
> 
>  static="false" />
>  static="false" />
>  static="false" />
>  static="false" />
> 
> 
> 
> 
> 
> 
>   
> 
> {code}
> This code style is also mentioned in the webpage here (minus some details 
> which are present in above configuration snippet but not on the webpage): 
> [https://cassandra.apache.org/_/development/code_style.html] (at the very 
> bottom).
> However, when one runs "Optimise imports" in the context menu after 
> right-clicking on org.cassandra.apache package, it will refactor 

[jira] [Assigned] (CASSANDRA-17887) Further updates needed post CASSANDRA-12883 - removal of non-JavaScript scripted UDFs

[Benjamin Lerer (Jira)]

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

Benjamin Lerer reassigned CASSANDRA-17887:
--

Assignee: Benjamin Lerer

> Further updates needed post CASSANDRA-12883 - removal of non-JavaScript 
> scripted UDFs
> -
>
> Key: CASSANDRA-17887
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17887
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation, Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Benjamin Lerer
>Priority: Low
>
> Non-JavaScript scripted UDFs were removed as part of CASSANDRA-12883 but 
> several updates were missed which makes it confusing for users. To name a few 
> I found so far:
>  * cassandra.yaml  -  Enable this option to be able to use UDFs with 
> "language javascript" or any custom JSR-223 provider.
>  * docs [functions page 
> |https://cassandra.apache.org/doc/4.1/cassandra/cql/functions.html]  "Support 
> for other JSR 223 compliant scripting languages, such as Python, Ruby, and 
> Scala, is possible by adding a JAR to the classpath."
> I suspect we also need to update bin/cassandra.in.sh which still tries to 
> collect all JSR223 engines' jars in trunk



--
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-17281) Remove support for Javascript UDF from trunk

[Benjamin Lerer (Jira)]

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

Benjamin Lerer reassigned CASSANDRA-17281:
--

Assignee: Benjamin Lerer

> Remove support for Javascript UDF from trunk
> 
>
> Key: CASSANDRA-17281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17281
> Project: Cassandra
>  Issue Type: Task
>  Components: Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
>
> [Consensus |https://lists.apache.org/thread/mnxh94lg9v94bfntq88051z3ww16q2fk] 
>  was reached to remove JavaScript UDF with the next major release. 
> We need to leave an interface for those who would like to supply a UDF 
> implementation. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (CASSANDRA-17925) Java source code should have sorted imports as defined in the codestyle

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-17925:
--
Description: 
After we cleaned all unused imports in CASSANDRA-17876, there is one more task 
remaining to be done - to add checkstyle for imports order and enforce this on 
build time.

When the project is imported into IDEA, there is a helper target on Ant called 
"generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
{code:java}

  













  

{code}
However, when one runs "Optimise imports" in the context menu after 
right-clicking on org.cassandra.apache package, it will refactor all the 
imports which adheres to the above codestyle with hundreds or changes.

This means that the source code, as-is, does not adhere to the self-imposed 
code style we ship for IDEA.

If we fix this, we should add checkstyle for it like this:
{code:java}

  
  
  
  
  
  

{code}
This checkstyle on import order will pass on the source code we run the import 
optimisation in the context menu on.

This should be applied to test checktyle as well and the source code should be 
refactored on imports too.

This should be done on cassandra-4.1 as well as for trunk.

  was:
After we cleaned all unused imports in CASSANDRA-17876, there is one more task 
remaining to be done - to add checkstyle for imports order and enforce this on 
build time.

When the project is imported into IDEA, there is a helper target on Ant called 
"generate-idea-files". ide/idea/codeStyleSettings.xml contains this:

{code}

  













  

{code}

However, when one runs "Optimise imports" in the context menu after 
right-clicking on org.cassandra.apache package, it will refactor all the 
imports which adheres to the above codestyle with hundreds or changes.

This means that the source code, as-is, does not adhere to the self-imposed 
code style we ship for IDEA.

If we fix this, we should add checkstyle for it like this:

{code}

  
  
  
  
  
  

{code}

This checkstyle on import order will pass on the source code we run the import 
optimisation in the context menu.

This should be applied to test checktyle as well and the source code should be 
refactored on imports too.

This should be done on cassandra-4.1 as well as for trunk.


> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more 
> task remaining to be done - to add checkstyle for imports order and enforce 
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant 
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
> 
>   
> 
> 
> 
>  static="false" />
>  static="false" />
>  static="false" />
>  static="false" />
> 
> 
> 
> 
> 
> 
>   
> 
> {code}
> However, when one runs "Optimise imports" in the context menu after 
> right-clicking on org.cassandra.apache package, it will refactor all the 
> imports which adheres to the above codestyle with hundreds or changes.
> This means that the source code, as-is, does not adhere to the self-imposed 
> code style we ship for IDEA.
> If we fix this, we should add checkstyle for it like this:
> {code:java}
> 
>value="/(^java\.|javax)/,/(com\.google\.common|org\.apache\.log4j|org\.apache\.commons|org\.cliffc\.high_scale_lib|org\.junit|org\.slf4j)/"/>
>   
>   
>   
>   
>   
> 
> {code}
> This checkstyle on import order will pass on the source code we run the 
> import optimisation in the context menu on.
> This should be applied to test checktyle as well and the source code should 
> be refactored on imports too.
> This should be done on cassandra-4.1 as well as for trunk.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: 

[jira] [Created] (CASSANDRA-17925) Java source code should have sorted imports as defined in the codestyle

[Stefan Miklosovic (Jira)]

Stefan Miklosovic created CASSANDRA-17925:
-

 Summary: Java source code should have sorted imports as defined in 
the codestyle
 Key: CASSANDRA-17925
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
 Project: Cassandra
  Issue Type: Improvement
Reporter: Stefan Miklosovic


After we cleaned all unused imports in CASSANDRA-17876, there is one more task 
remaining to be done - to add checkstyle for imports order and enforce this on 
build time.

When the project is imported into IDEA, there is a helper target on Ant called 
"generate-idea-files". ide/idea/codeStyleSettings.xml contains this:

{code}

  













  

{code}

However, when one runs "Optimise imports" in the context menu after 
right-clicking on org.cassandra.apache package, it will refactor all the 
imports which adheres to the above codestyle with hundreds or changes.

This means that the source code, as-is, does not adhere to the self-imposed 
code style we ship for IDEA.

If we fix this, we should add checkstyle for it like this:

{code}

  
  
  
  
  
  

{code}

This checkstyle on import order will pass on the source code we run the import 
optimisation in the context menu.

This should be applied to test checktyle as well and the source code should be 
refactored on imports too.

This should be done on cassandra-4.1 as well as for trunk.



--
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-website] branch asf-staging updated (4974086c4 -> 8f1290ec3)

[git-site-role]

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

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


 discard 4974086c4 generate docs for 2db0aea2
 new 8f1290ec3 generate docs for 2db0aea2

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

 * -- * -- B -- O -- O -- O   (4974086c4)
\
 N -- N -- N   refs/heads/asf-staging (8f1290ec3)

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

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

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


Summary of changes:
 content/search-index.js |   2 +-
 site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes
 2 files changed, 1 insertion(+), 1 deletion(-)


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

[cassandra-website] branch asf-staging updated (ea2cfbe46 -> 4974086c4)

[git-site-role]

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

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


 discard ea2cfbe46 generate docs for 2db0aea2
 new 4974086c4 generate docs for 2db0aea2

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

 * -- * -- B -- O -- O -- O   (ea2cfbe46)
\
 N -- N -- N   refs/heads/asf-staging (4974086c4)

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

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

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


Summary of changes:
 site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)


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

[cassandra-website] branch asf-staging updated (f18980b52 -> ea2cfbe46)

[git-site-role]

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

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


 discard f18980b52 generate docs for 2db0aea2
 new ea2cfbe46 generate docs for 2db0aea2

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

 * -- * -- B -- O -- O -- O   (f18980b52)
\
 N -- N -- N   refs/heads/asf-staging (ea2cfbe46)

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

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

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


Summary of changes:
 site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)


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