[jira] [Updated] (CASSANDRA-17852) WEBSITE - Community page - encourage users to search answered questions on Stack Overflow, Stack Exchange

[Erick Ramirez (Jira)]

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

Erick Ramirez updated CASSANDRA-17852:
--
Change Category: Semantic
 Complexity: Normal
Component/s: Documentation/Website
  Fix Version/s: 4.0.x
 Status: Open  (was: Triage Needed)

> WEBSITE - Community page - encourage users to search answered questions on 
> Stack Overflow, Stack Exchange
> -
>
> Key: CASSANDRA-17852
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17852
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x
>
>
> We need to encourage users to first search the {{[cassandra]}} tag on [Stack 
> Overflow|http://stackoverflow.com/questions/tagged/cassandra] and [Stack 
> Exchange|https://dba.stackexchange.com/questions/tagged/cassandra] before 
> asking a question so contributors are not repeatedly asking the same 
> questions over and over.



--
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-17852) WEBSITE - Community page - encourage users to search answered questions on Stack Overflow, Stack Exchange

[Erick Ramirez (Jira)]

Erick Ramirez created CASSANDRA-17852:
-

 Summary: WEBSITE - Community page - encourage users to search 
answered questions on Stack Overflow, Stack Exchange
 Key: CASSANDRA-17852
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17852
 Project: Cassandra
  Issue Type: Task
Reporter: Erick Ramirez
Assignee: Erick Ramirez


We need to encourage users to first search the {{[cassandra]}} tag on [Stack 
Overflow|http://stackoverflow.com/questions/tagged/cassandra] and [Stack 
Exchange|https://dba.stackexchange.com/questions/tagged/cassandra] before 
asking a question so contributors are not repeatedly asking the same questions 
over and over.



--
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 (4aceb358 -> 0b926df5)

[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 4aceb358 generate docs for 8cf784cf
 new 0b926df5 generate docs for 8cf784cf

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   (4aceb358)
\
 N -- N -- N   refs/heads/asf-staging (0b926df5)

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-17823) WEBSITE – in-tree trunk should be marked as `prerelease: true`

[Milan Krisko (Jira)]

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

Milan Krisko commented on CASSANDRA-17823:
--

Created PR: https://github.com/apache/cassandra/pull/1814

> WEBSITE – in-tree trunk should be marked as `prerelease: true`
> --
>
> Key: CASSANDRA-17823
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17823
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Website
>Reporter: Michael Semb Wever
>Assignee: Milan Krisko
>Priority: Normal
>  Labels: lhf
> Fix For: 4.x
>
>
> this will avoid the "A newer version of this documentation is available." 
> banner displaying on the version docs for our latest released version.
> ref: https://docs.antora.org/antora/latest/component-prerelease/#true
> change is to be applied to 
> https://github.com/apache/cassandra/blob/trunk/doc/antora.yml 



--
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-17823) WEBSITE – in-tree trunk should be marked as `prerelease: true`

[Milan Krisko (Jira)]

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

Milan Krisko reassigned CASSANDRA-17823:


Assignee: Milan Krisko

> WEBSITE – in-tree trunk should be marked as `prerelease: true`
> --
>
> Key: CASSANDRA-17823
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17823
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Website
>Reporter: Michael Semb Wever
>Assignee: Milan Krisko
>Priority: Normal
>  Labels: lhf
> Fix For: 4.x
>
>
> this will avoid the "A newer version of this documentation is available." 
> banner displaying on the version docs for our latest released version.
> ref: https://docs.antora.org/antora/latest/component-prerelease/#true
> change is to be applied to 
> https://github.com/apache/cassandra/blob/trunk/doc/antora.yml 



--
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-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-17819:
-

Left some questions on the PR. I need to spend a bit more time on this. 

> Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
> --
>
> Key: CASSANDRA-17819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17819
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The test 
> {{{}org.apache.cassandra.distributed.test.SchemaTest.schemaReset{}}}, 
> recently introduced by CASSANDRA-17658, is flaky on 4.1 and trunk:
>  * 4.1: 
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/134/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
>  * trunk: 
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1265/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> {code:java}
> Error Message
> Condition with lambda expression in 
> org.apache.cassandra.distributed.test.SchemaTest that uses 
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> Stacktrace
> org.awaitility.core.ConditionTimeoutException: Condition with lambda 
> expression in org.apache.cassandra.distributed.test.SchemaTest that uses 
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
>   at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
>   at 
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
>   at 
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
>   at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
>   at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
>   at 
> org.apache.cassandra.distributed.test.SchemaTest.schemaReset(SchemaTest.java:115)
>   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)
> Standard Output
> INFO  [main]  2022-08-15 15:02:14,783 Reflections.java:219 - 
> Reflections took 1873 ms to scan 8 urls, producing 1754 keys and 6912 values
> INFO  [main]  2022-08-15 15:02:16,407 Reflections.java:219 - 
> Reflections took 1561 ms to scan 8 urls, producing 1754 keys and 6912 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2022-08-15 15:02:17,554 InternalLoggerFactory.ja
> ...[truncated 1761288 chars]...
> cutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
> INFO  [node2_isolatedExecutor:3] node2 2022-08-15 15:03:52,096 
> MessagingService.java:519 - Waiting for messaging service to quiesce
> {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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Stefan Miklosovic (Jira)]

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

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

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.2
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-17849:
--
Status: Ready to Commit  (was: Review In Progress)

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Stefan Miklosovic (Jira)]

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

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

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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] branch trunk updated: fix StandaloneUpgraderOnSStablesTest

[smiklosovic]

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 17810295ca fix StandaloneUpgraderOnSStablesTest
17810295ca is described below

commit 17810295ca3b05b011a0ff7061d27435b531ea32
Author: Stefan Miklosovic 
AuthorDate: Tue Aug 23 19:53:16 2022 +0200

fix StandaloneUpgraderOnSStablesTest

This is follow-up for CASSANDRA-13010 where a bug was introduced in Upgrader
which made StandaloneUpgraderOnSStablesTest flaky.

patch by Stefan Miklosovic; reviewed by Brandon Williams for CASSANDRA-17849
---
 src/java/org/apache/cassandra/db/compaction/Upgrader.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/java/org/apache/cassandra/db/compaction/Upgrader.java 
b/src/java/org/apache/cassandra/db/compaction/Upgrader.java
index d1a3677118..2bfb30b4e4 100644
--- a/src/java/org/apache/cassandra/db/compaction/Upgrader.java
+++ b/src/java/org/apache/cassandra/db/compaction/Upgrader.java
@@ -93,8 +93,8 @@ public class Upgrader
  CompactionIterator iter = new 
CompactionIterator(transaction.opType(), scanners.scanners, controller, 
nowInSec, nextTimeUUID()))
 {
 
writer.switchWriter(createCompactionWriter(sstable.getSSTableMetadata()));
+iter.setTargetDirectory(writer.currentWriter().getFilename());
 while (iter.hasNext())
-iter.setTargetDirectory(writer.currentWriter().getFilename());
 writer.append(iter.next());
 
 writer.finish();


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

[jira] [Commented] (CASSANDRA-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-17849:
---

both j8 and j11 precommit finished without any error
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1227/workflows/7c4a4f5a-2657-4606-b386-a218162820a2
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1227/workflows/18c4dcda-46a4-44a4-aba5-12ffacd770a8

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17753) Include GitSHA in nodetool version output

[Abe Ratnofsky (Jira)]

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

Abe Ratnofsky commented on CASSANDRA-17753:
---

[~mck] any other review feedback here, or is this ready to commit (pending 
unrelated test issues)?

> Include GitSHA in nodetool version output
> -
>
> Key: CASSANDRA-17753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17753
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tool/nodetool
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> It can be useful to see specifically which Git SHA a running instance of 
> Cassandra was built with, especially when running clusters in development for 
> soak testing.
>  
> I have a patch ready for this, and am preparing it now.



--
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 (b6b628fa -> 4aceb358)

[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


omit b6b628fa generate docs for 8cf784cf
 new 4aceb358 generate docs for 8cf784cf

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   (b6b628fa)
\
 N -- N -- N   refs/heads/asf-staging (4aceb358)

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

[jira] [Commented] (CASSANDRA-17750) Remove dependency on Maven Ant Tasks

[David Capwell (Jira)]

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

David Capwell commented on CASSANDRA-17750:
---

circle looks cleanish... the single test failing is also marked as failing in 
Butler... waiting on Jenkins to make progress before merging.

> Remove dependency on Maven Ant Tasks
> 
>
> Key: CASSANDRA-17750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17750
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build, Dependencies, Packaging
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> Apache Cassandra depends on Maven Ant Tasks (MAT) during build, for declaring 
> dependencies and generating POM files from within build.xml. MAT has long 
> been retired (no commits since maintenance in 2015), has registered CVEs in 
> dependencies (CVE-2017-1000487), and encourages migration to its successor, 
> Maven Artifact Resolver Ant Tasks (MARAT).
> As part of CASSANDRA-16391 
> , mck migrated 
> dependency resolution to MARAT, but MAT is still included in our build for 
> generating POMs since MARAT does not have an alternative to the writepom task 
> provided by MAT. I have a patch ready that removes MAT completely, with a 
> workaround for POM generation.
> I am not advocating for any kind of migration away from Ant to an alternative 
> like Gradle or Maven, just to be extra clear.



--
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-17750) Remove dependency on Maven Ant Tasks

[David Capwell (Jira)]

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

David Capwell commented on CASSANDRA-17750:
---

Messed up the Jenkins build, new link 
https://ci-cassandra.apache.org/job/Cassandra-devbranch/1889/

> Remove dependency on Maven Ant Tasks
> 
>
> Key: CASSANDRA-17750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17750
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build, Dependencies, Packaging
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> Apache Cassandra depends on Maven Ant Tasks (MAT) during build, for declaring 
> dependencies and generating POM files from within build.xml. MAT has long 
> been retired (no commits since maintenance in 2015), has registered CVEs in 
> dependencies (CVE-2017-1000487), and encourages migration to its successor, 
> Maven Artifact Resolver Ant Tasks (MARAT).
> As part of CASSANDRA-16391 
> , mck migrated 
> dependency resolution to MARAT, but MAT is still included in our build for 
> generating POMs since MARAT does not have an alternative to the writepom task 
> provided by MAT. I have a patch ready that removes MAT completely, with a 
> workaround for POM generation.
> I am not advocating for any kind of migration away from Ant to an alternative 
> like Gradle or Maven, just to be extra clear.



--
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-17851) Add interim prioritization logic for CompactionTasks

[Josh McKenzie (Jira)]

Josh McKenzie created CASSANDRA-17851:
-

 Summary: Add interim prioritization logic for CompactionTasks
 Key: CASSANDRA-17851
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17851
 Project: Cassandra
  Issue Type: Improvement
  Components: Local/Compaction
Reporter: Josh McKenzie
Assignee: Josh McKenzie


While ultimately we could serve to have a real scheduler and single entry point 
for compactions, for now some moderate progress seems in order. There are cases 
where, during expansions, you can end up in a state where you can't finish 
upgrading sstables as they keep getting aborted by Incremental Repair and other 
operations that ultimately should be lower priority and not have the ability to 
cancel these operations.

 The idea here is that tasks like {{upgradestables}} and {{cleanup}} (and other 
tasks that have the same priority) will get serialised since 
{{markAllCompacting}} is synchronising on data, and higher priority tasks will 
be able to still cancel others via {{runWithCompactionsDisabled}}.



--
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-17840) IndexOutOfBoundsException in Paging State Version Inference (V3 State Received on V4 Connection)

[Josh McKenzie (Jira)]

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

Josh McKenzie commented on CASSANDRA-17840:
---

||Item|Link||
|3.11 
branch|[Link|https://github.com/apache/cassandra/compare/trunk...josh-mckenzie:cassandra:CASSANDRA-17840/3.11?expand=1]|
|3.11 
CI|[Link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/284/workflows/103b3337-4ebd-4d3b-a7fb-e9628a535168]|
|trunk 
branch|[Link|https://github.com/josh-mckenzie/cassandra/commit/8545d2e79ff4d2aa70962275da7e78793a7a0f59]|
|trunk 
CI|[Link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/282/workflows/5858fe05-961f-43e0-ab0f-fe06fdec06d0]|

Patch merges cleanly from 4.0 -> trunk. Have some 3.11 specific things for the 
unit test; will probably apply there, apply 4.0 -s ours, and then merge up to 
trunk.


> IndexOutOfBoundsException in Paging State Version Inference (V3 State 
> Received on V4 Connection)
> 
>
> Key: CASSANDRA-17840
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17840
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> In {{PagingState.java}}, {{index}} is an integer field, and we add long 
> values to it without a {{Math.toIntExact}} check. While we’re checking for 
> negative return values returned by {{getUnsignedVInt}}, there's a chance that 
> the value returned by it is so large that addition operation would cause 
> integer overflow, or the value itself is large enough to cause overflow.



--
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-17840) IndexOutOfBoundsException in Paging State Version Inference (V3 State Received on V4 Connection)

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17840:
--
Test and Documentation Plan: New unit testing
 Status: Patch Available  (was: Open)

> IndexOutOfBoundsException in Paging State Version Inference (V3 State 
> Received on V4 Connection)
> 
>
> Key: CASSANDRA-17840
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17840
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Client
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> In {{PagingState.java}}, {{index}} is an integer field, and we add long 
> values to it without a {{Math.toIntExact}} check. While we’re checking for 
> negative return values returned by {{getUnsignedVInt}}, there's a chance that 
> the value returned by it is so large that addition operation would cause 
> integer overflow, or the value itself is large enough to cause overflow.



--
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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer edited comment on CASSANDRA-17783 at 8/23/22 7:03 PM:
--

Rebased on Trunk (twice - missed some changes the first time). Should be good 
to go, with current patch attached


was (Author: drohrer):
[^CASSANDRA-17783-rebased.patch]

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Fix For: 4.x
>
> Attachments: CASSANDRA-17783-rebased.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer updated CASSANDRA-17783:

Test and Documentation Plan: 
 

Now rebased on Trunk from 8/23/2022

Tested in {{CQLSSTableWriterClientTest}} as it requires this prop to be set, 
which is done via the moved property in {{CQLSSTableWriter}}

  was:
[^CASSANDRA-17783-rebased.patch]

Now rebased on Trunk from 8/23/2022

Tested in {{CQLSSTableWriterClientTest}} as it requires this prop to be set, 
which is done via the moved property in {{CQLSSTableWriter}}


> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Fix For: 4.x
>
> Attachments: CASSANDRA-17783-rebased.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer updated CASSANDRA-17783:

Test and Documentation Plan: 
[^CASSANDRA-17783-rebased.patch]

Now rebased on Trunk from 8/23/2022 (a second time)

Tested in {{CQLSSTableWriterClientTest}} as it requires this prop to be set, 
which is done via the moved property in {{CQLSSTableWriter}}

  was:
 

Now rebased on Trunk from 8/23/2022

Tested in {{CQLSSTableWriterClientTest}} as it requires this prop to be set, 
which is done via the moved property in {{CQLSSTableWriter}}


> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Fix For: 4.x
>
> Attachments: CASSANDRA-17783-rebased.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer updated CASSANDRA-17783:

Attachment: CASSANDRA-17783-rebased.patch

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Fix For: 4.x
>
> Attachments: CASSANDRA-17783-rebased.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer updated CASSANDRA-17783:

Attachment: (was: CASSANDRA-17783.patch)

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Fix For: 4.x
>
> Attachments: CASSANDRA-17783-rebased.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer updated CASSANDRA-17783:

Attachment: (was: CASSANDRA-17783-rebased.patch)

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Fix For: 4.x
>
> Attachments: CASSANDRA-17783-rebased.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer commented on CASSANDRA-17783:
-

[^CASSANDRA-17783-rebased.patch]

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Fix For: 4.x
>
> Attachments: CASSANDRA-17783-rebased.patch, CASSANDRA-17783.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer updated CASSANDRA-17783:

Test and Documentation Plan: 
[^CASSANDRA-17783-rebased.patch]

Now rebased on Trunk from 8/23/2022

Tested in {{CQLSSTableWriterClientTest}} as it requires this prop to be set, 
which is done via the moved property in {{CQLSSTableWriter}}

  was:
[^CASSANDRA-17783.patch]

(NOTE: Updated - missed a file in the first upload)

Tested in {{CQLSSTableWriterClientTest}} as it requires this prop to be set, 
which is done via the moved property in {{CQLSSTableWriter}}


> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Fix For: 4.x
>
> Attachments: CASSANDRA-17783-rebased.patch, CASSANDRA-17783.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer updated CASSANDRA-17783:

Attachment: CASSANDRA-17783-rebased.patch

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Fix For: 4.x
>
> Attachments: CASSANDRA-17783-rebased.patch, CASSANDRA-17783.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17850) Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without opening internals

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-17850 at 8/23/22 6:41 PM:
--

So far I haven't found anyone using something different than the reflection 
option and complaining about it. Opening here as a place holder for further 
future investigations how to refactor this in Cassandra. Open for ideas too


was (Author: e.dimitrova):
So far I haven't found anyone using something different than the reflection 
option and complaining about it. Opening here as a place holder for further 
future investigations. Open for ideas too

> Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without 
> opening internals
> ---
>
> Key: CASSANDRA-17850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17850
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> With Java 17 if we do not add below to the jvm17 server options:
> {code:java}
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED{code}
> we get on startup (considering I comment out the scripted UDFs and apply a 
> few changes to the startup scripts):
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:29:25,652 
> JVMStabilityInspector.java:68 - Exception in thread 
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: 
> Unable to make field private int java.io.FileDescriptor.fd accessible: module 
> java.base does not "opens java.io" to unnamed module @11d8ae8b
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:84)
> at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
> at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
> at 
> org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
> at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
> at 
> org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
> at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
> at 
> org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
> at org.apache.cassandra.service.StorageService.(StorageService.java:376)
> at 
> org.apache.cassandra.service.StorageService.(StorageService.java:226)
> at 
> org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
> at 
> org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
> at 
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field private int java.io.FileDescriptor.fd accessible: module java.base does 
> not "opens java.io" to unnamed module @11d8ae8b
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
> ... 20 common frames omitted
> {code}
> and 
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:31:18,443 
> JVMStabilityInspector.java:68 - Exception in thread 
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: 
> Unable to make field private final java.io.FileDescriptor 
> sun.nio.ch.FileChannelImpl.fd accessible: module java.base does not "opens 
> sun.nio.ch" to unnamed module @4c012563
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at 

[jira] [Commented] (CASSANDRA-17850) Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without opening internals

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-17850:
-

So far I haven't found anyone using something different than the reflection 
option and complaining about it. Opening here as a place holder for further 
future investigations. 

> Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without 
> opening internals
> ---
>
> Key: CASSANDRA-17850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17850
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> With Java 17 if we do not add below to the jvm17 server options:
> {code:java}
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED{code}
> we get on startup (considering I comment out the scripted UDFs and apply a 
> few changes to the startup scripts):
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:29:25,652 
> JVMStabilityInspector.java:68 - Exception in thread 
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: 
> Unable to make field private int java.io.FileDescriptor.fd accessible: module 
> java.base does not "opens java.io" to unnamed module @11d8ae8b
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:84)
> at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
> at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
> at 
> org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
> at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
> at 
> org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
> at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
> at 
> org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
> at org.apache.cassandra.service.StorageService.(StorageService.java:376)
> at 
> org.apache.cassandra.service.StorageService.(StorageService.java:226)
> at 
> org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
> at 
> org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
> at 
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field private int java.io.FileDescriptor.fd accessible: module java.base does 
> not "opens java.io" to unnamed module @11d8ae8b
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
> ... 20 common frames omitted
> {code}
> and 
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:31:18,443 
> JVMStabilityInspector.java:68 - Exception in thread 
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: 
> Unable to make field private final java.io.FileDescriptor 
> sun.nio.ch.FileChannelImpl.fd accessible: module java.base does not "opens 
> sun.nio.ch" to unnamed module @4c012563
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:87)
> at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
> at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
> at 
> org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
> at 

[jira] [Comment Edited] (CASSANDRA-17850) Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without opening internals

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-17850 at 8/23/22 6:39 PM:
--

So far I haven't found anyone using something different than the reflection 
option and complaining about it. Opening here as a place holder for further 
future investigations. Open for ideas too


was (Author: e.dimitrova):
So far I haven't found anyone using something different than the reflection 
option and complaining about it. Opening here as a place holder for further 
future investigations. 

> Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without 
> opening internals
> ---
>
> Key: CASSANDRA-17850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17850
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> With Java 17 if we do not add below to the jvm17 server options:
> {code:java}
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED{code}
> we get on startup (considering I comment out the scripted UDFs and apply a 
> few changes to the startup scripts):
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:29:25,652 
> JVMStabilityInspector.java:68 - Exception in thread 
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: 
> Unable to make field private int java.io.FileDescriptor.fd accessible: module 
> java.base does not "opens java.io" to unnamed module @11d8ae8b
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:84)
> at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
> at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
> at 
> org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
> at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
> at 
> org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
> at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
> at 
> org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
> at org.apache.cassandra.service.StorageService.(StorageService.java:376)
> at 
> org.apache.cassandra.service.StorageService.(StorageService.java:226)
> at 
> org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
> at 
> org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
> at 
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field private int java.io.FileDescriptor.fd accessible: module java.base does 
> not "opens java.io" to unnamed module @11d8ae8b
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
> ... 20 common frames omitted
> {code}
> and 
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:31:18,443 
> JVMStabilityInspector.java:68 - Exception in thread 
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: 
> Unable to make field private final java.io.FileDescriptor 
> sun.nio.ch.FileChannelImpl.fd accessible: module java.base does not "opens 
> sun.nio.ch" to unnamed module @4c012563
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:87)
> at 

[jira] [Updated] (CASSANDRA-17850) Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without opening internals

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova updated CASSANDRA-17850:

Description: 
With Java 17 if we do not add below to the jvm17 server options:
{code:java}
--add-opens java.base/sun.nio.ch=ALL-UNNAMED
--add-opens java.base/java.io=ALL-UNNAMED{code}
we get on startup (considering I comment out the scripted UDFs and apply a few 
changes to the startup scripts):
{code:java}
ERROR [ScheduledTasks:1] 2022-08-23 12:29:25,652 JVMStabilityInspector.java:68 
- Exception in thread Thread[ScheduledTasks:1,5,ScheduledTasks]
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable 
to make field private int java.io.FileDescriptor.fd accessible: module 
java.base does not "opens java.io" to unnamed module @11d8ae8b
at 
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:84)
at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
at 
org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
at 
org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
at org.apache.cassandra.service.StorageService.(StorageService.java:376)
at org.apache.cassandra.service.StorageService.(StorageService.java:226)
at 
org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
at 
org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
at 
org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at 
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field 
private int java.io.FileDescriptor.fd accessible: module java.base does not 
"opens java.io" to unnamed module @11d8ae8b
at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at 
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
... 20 common frames omitted
{code}
 

 

and 

 
{code:java}
ERROR [ScheduledTasks:1] 2022-08-23 12:31:18,443 JVMStabilityInspector.java:68 
- Exception in thread Thread[ScheduledTasks:1,5,ScheduledTasks]
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable 
to make field private final java.io.FileDescriptor 
sun.nio.ch.FileChannelImpl.fd accessible: module java.base does not "opens 
sun.nio.ch" to unnamed module @4c012563
at 
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:87)
at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
at 
org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
at 
org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
at org.apache.cassandra.service.StorageService.(StorageService.java:376)
at org.apache.cassandra.service.StorageService.(StorageService.java:226)
at 
org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
at 
org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
at 
org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at 

[jira] [Updated] (CASSANDRA-17850) Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without opening internals

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova updated CASSANDRA-17850:

Description: 
With Java 17 if we do not add below to the jvm17 server options:
{code:java}
--add-opens java.base/sun.nio.ch=ALL-UNNAMED
--add-opens java.base/java.io=ALL-UNNAMED{code}
we get on startup (considering I comment out the scripted UDFs and apply a few 
changes to the startup scripts):
{code:java}
ERROR [ScheduledTasks:1] 2022-08-23 12:29:25,652 JVMStabilityInspector.java:68 
- Exception in thread Thread[ScheduledTasks:1,5,ScheduledTasks]
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable 
to make field private int java.io.FileDescriptor.fd accessible: module 
java.base does not "opens java.io" to unnamed module @11d8ae8b
at 
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:84)
at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
at 
org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
at 
org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
at org.apache.cassandra.service.StorageService.(StorageService.java:376)
at org.apache.cassandra.service.StorageService.(StorageService.java:226)
at 
org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
at 
org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
at 
org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at 
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field 
private int java.io.FileDescriptor.fd accessible: module java.base does not 
"opens java.io" to unnamed module @11d8ae8b
at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at 
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
... 20 common frames omitted
{code}
and 
{code:java}
ERROR [ScheduledTasks:1] 2022-08-23 12:31:18,443 JVMStabilityInspector.java:68 
- Exception in thread Thread[ScheduledTasks:1,5,ScheduledTasks]
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable 
to make field private final java.io.FileDescriptor 
sun.nio.ch.FileChannelImpl.fd accessible: module java.base does not "opens 
sun.nio.ch" to unnamed module @4c012563
at 
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:87)
at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
at 
org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
at 
org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
at org.apache.cassandra.service.StorageService.(StorageService.java:376)
at org.apache.cassandra.service.StorageService.(StorageService.java:226)
at 
org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
at 
org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
at 
org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at 

[jira] [Updated] (CASSANDRA-17850) Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without opening internals

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova updated CASSANDRA-17850:

Fix Version/s: 4.x

> Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without 
> opening internals
> ---
>
> Key: CASSANDRA-17850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17850
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> With Java 17 if we do not add below to the jvm17 server options:
> {code:java}
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED{code}
> we get on startup (considering I comment out the scripted UDFs and apply a 
> few changes to the startup scripts):
>  
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:29:25,652 
> JVMStabilityInspector.java:68 - Exception in thread 
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: 
> Unable to make field private int java.io.FileDescriptor.fd accessible: module 
> java.base does not "opens java.io" to unnamed module @11d8ae8b
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:84)
> at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
> at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
> at 
> org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
> at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
> at 
> org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
> at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
> at 
> org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
> at org.apache.cassandra.service.StorageService.(StorageService.java:376)
> at 
> org.apache.cassandra.service.StorageService.(StorageService.java:226)
> at 
> org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
> at 
> org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
> at 
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field private int java.io.FileDescriptor.fd accessible: module java.base does 
> not "opens java.io" to unnamed module @11d8ae8b
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
> ... 20 common frames omitted
> {code}
>  
>  
> and 
>  
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:31:18,443 
> JVMStabilityInspector.java:68 - Exception in thread 
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: 
> Unable to make field private final java.io.FileDescriptor 
> sun.nio.ch.FileChannelImpl.fd accessible: module java.base does not "opens 
> sun.nio.ch" to unnamed module @4c012563
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:87)
> at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
> at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
> at 
> org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
> at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
> at 
> org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
> at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
> 

[jira] [Updated] (CASSANDRA-17850) Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without opening internals

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova updated CASSANDRA-17850:

Change Category: Semantic
 Complexity: Normal
Component/s: Build
 Status: Open  (was: Triage Needed)

> Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without 
> opening internals
> ---
>
> Key: CASSANDRA-17850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17850
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> With Java 17 if we do not add below to the jvm17 server options:
> {code:java}
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED{code}
> we get on startup (considering I comment out the scripted UDFs and apply a 
> few changes to the startup scripts):
>  
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:29:25,652 
> JVMStabilityInspector.java:68 - Exception in thread 
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: 
> Unable to make field private int java.io.FileDescriptor.fd accessible: module 
> java.base does not "opens java.io" to unnamed module @11d8ae8b
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:84)
> at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
> at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
> at 
> org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
> at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
> at 
> org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
> at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
> at 
> org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
> at org.apache.cassandra.service.StorageService.(StorageService.java:376)
> at 
> org.apache.cassandra.service.StorageService.(StorageService.java:226)
> at 
> org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
> at 
> org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
> at 
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> field private int java.io.FileDescriptor.fd accessible: module java.base does 
> not "opens java.io" to unnamed module @11d8ae8b
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
> ... 20 common frames omitted
> {code}
>  
>  
> and 
>  
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:31:18,443 
> JVMStabilityInspector.java:68 - Exception in thread 
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: 
> Unable to make field private final java.io.FileDescriptor 
> sun.nio.ch.FileChannelImpl.fd accessible: module java.base does not "opens 
> sun.nio.ch" to unnamed module @4c012563
> at 
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:87)
> at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
> at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
> at 
> org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
> at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
> at 
> 

[jira] [Created] (CASSANDRA-17850) Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without opening internals

[Ekaterina Dimitrova (Jira)]

Ekaterina Dimitrova created CASSANDRA-17850:
---

 Summary: Find a way to get FileDescriptor.fd and 
sun.nio.ch.FileChannelImpl.fd without opening internals
 Key: CASSANDRA-17850
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17850
 Project: Cassandra
  Issue Type: Improvement
Reporter: Ekaterina Dimitrova


With Java 17 if we do not add below to the jvm17 server options:
{code:java}
--add-opens java.base/sun.nio.ch=ALL-UNNAMED
--add-opens java.base/java.io=ALL-UNNAMED{code}
we get on startup (considering I comment out the scripted UDFs and apply a few 
changes to the startup scripts):

 
{code:java}
ERROR [ScheduledTasks:1] 2022-08-23 12:29:25,652 JVMStabilityInspector.java:68 
- Exception in thread Thread[ScheduledTasks:1,5,ScheduledTasks]
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable 
to make field private int java.io.FileDescriptor.fd accessible: module 
java.base does not "opens java.io" to unnamed module @11d8ae8b
at 
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:84)
at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
at 
org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
at 
org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
at org.apache.cassandra.service.StorageService.(StorageService.java:376)
at org.apache.cassandra.service.StorageService.(StorageService.java:226)
at 
org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
at 
org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
at 
org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at 
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field 
private int java.io.FileDescriptor.fd accessible: module java.base does not 
"opens java.io" to unnamed module @11d8ae8b
at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at 
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
... 20 common frames omitted
{code}
 

 

and 

 
{code:java}
ERROR [ScheduledTasks:1] 2022-08-23 12:31:18,443 JVMStabilityInspector.java:68 
- Exception in thread Thread[ScheduledTasks:1,5,ScheduledTasks]
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable 
to make field private final java.io.FileDescriptor 
sun.nio.ch.FileChannelImpl.fd accessible: module java.base does not "opens 
sun.nio.ch" to unnamed module @4c012563
at 
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:87)
at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
at 
org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
at 
org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
at org.apache.cassandra.service.StorageService.(StorageService.java:376)
at org.apache.cassandra.service.StorageService.(StorageService.java:226)
at 
org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
at 
org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
at 
org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
at 

[jira] [Commented] (CASSANDRA-17835) Upgrade ASM, ByteBuddy and Mockito on trunk

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-17835:
-

Fair point, thanks for pushing it :) 

> Upgrade ASM, ByteBuddy and Mockito on trunk
> ---
>
> Key: CASSANDRA-17835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17835
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> In preparation to support Java 17 I would like to update ASM, ByteBuddy and 
> Mockito on trunk.
>  * ASM - from 9.1 to 9.3; From the [release 
> notes|https://asm.ow2.io/versions.html] I don't see anything disturbing for 
> us; 
>  * ByteBuddy - 1.10.10 to 1.12.13; [Release 
> notes|https://github.com/raphw/byte-buddy/blob/master/release-notes.md]; they 
> support Java 17 since 1.12.0 but I did not see an issue updating to the 
> latest version; 
>  * Mockito - 3.2.4 to 4.7.0; [Release 
> notes|https://github.com/mockito/mockito/releases/]. The bump in the major 
> version was due to removing outdated deprecated APIs which it doesn't seem 
> that we use so this is not a breaking change for us. 



--
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-17835) Upgrade ASM, ByteBuddy and Mockito on trunk

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova edited comment on CASSANDRA-17835 at 8/23/22 6:23 PM:
--

Fair point, thanks for pushing it to CI :) 


was (Author: e.dimitrova):
Fair point, thanks for pushing it :) 

> Upgrade ASM, ByteBuddy and Mockito on trunk
> ---
>
> Key: CASSANDRA-17835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17835
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> In preparation to support Java 17 I would like to update ASM, ByteBuddy and 
> Mockito on trunk.
>  * ASM - from 9.1 to 9.3; From the [release 
> notes|https://asm.ow2.io/versions.html] I don't see anything disturbing for 
> us; 
>  * ByteBuddy - 1.10.10 to 1.12.13; [Release 
> notes|https://github.com/raphw/byte-buddy/blob/master/release-notes.md]; they 
> support Java 17 since 1.12.0 but I did not see an issue updating to the 
> latest version; 
>  * Mockito - 3.2.4 to 4.7.0; [Release 
> notes|https://github.com/mockito/mockito/releases/]. The bump in the major 
> version was due to removing outdated deprecated APIs which it doesn't seem 
> that we use so this is not a breaking change for us. 



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic updated CASSANDRA-17849:
--
Test and Documentation Plan: fixed failing tests
 Status: Patch Available  (was: In Progress)

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-17849:
--

No problem, I hadn't started yet, so thanks for the patch!  +1 assuming CI is 
happy.

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-17849 at 8/23/22 5:59 PM:


Sorry for hijacking this as Brandon is assigned to this but I just found the 
reason why that whole test class behaves flaky. It is obvious from the PR. Very 
trivial fix.

https://github.com/apache/cassandra/pull/1812
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1226/workflows/b38415da-be17-48cf-b4c9-36a4068bcc26


was (Author: smiklosovic):
Sorry for hijacking this as Brandon is assigned to this but I just found the 
reason why that whole test class behaves flaky. It is obvious from the PR. Very 
trivial fix.

https://github.com/apache/cassandra/pull/1812
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1225/workflows/c45d9015-16a8-4e00-9a20-563a52164ab4

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-17849:
-
Reviewers: Brandon Williams

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17750) Remove dependency on Maven Ant Tasks

[David Capwell (Jira)]

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

David Capwell updated CASSANDRA-17750:
--
Status: Ready to Commit  (was: Review In Progress)

> Remove dependency on Maven Ant Tasks
> 
>
> Key: CASSANDRA-17750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17750
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build, Dependencies, Packaging
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> Apache Cassandra depends on Maven Ant Tasks (MAT) during build, for declaring 
> dependencies and generating POM files from within build.xml. MAT has long 
> been retired (no commits since maintenance in 2015), has registered CVEs in 
> dependencies (CVE-2017-1000487), and encourages migration to its successor, 
> Maven Artifact Resolver Ant Tasks (MARAT).
> As part of CASSANDRA-16391 
> , mck migrated 
> dependency resolution to MARAT, but MAT is still included in our build for 
> generating POMs since MARAT does not have an alternative to the writepom task 
> provided by MAT. I have a patch ready that removes MAT completely, with a 
> workaround for POM generation.
> I am not advocating for any kind of migration away from Ant to an alternative 
> like Gradle or Maven, just to be extra clear.



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Brandon Williams (Jira)]

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

Brandon Williams reassigned CASSANDRA-17849:


Assignee: Stefan Miklosovic  (was: Brandon Williams)

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-17849:
---

Sorry for hijacking this as Brandon is assigned to this but I just found the 
reason why that whole test class behaves flaky. It is obvious from the PR. Very 
trivial fix.

https://github.com/apache/cassandra/pull/1812
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1225/workflows/c45d9015-16a8-4e00-9a20-563a52164ab4

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17750) Remove dependency on Maven Ant Tasks

[David Capwell (Jira)]

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

David Capwell edited comment on CASSANDRA-17750 at 8/23/22 5:54 PM:


Starting commit

CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17750-trunk-96419495-920E-4459-AED6-52E4CF36A1AF]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17750-trunk-96419495-920E-4459-AED6-52E4CF36A1AF]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1888/]|



was (Author: dcapwell):
Starting commit

CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17750-trunk-96419495-920E-4459-AED6-52E4CF36A1AF]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17750-trunk-96419495-920E-4459-AED6-52E4CF36A1AF]|[build|unknown]|


> Remove dependency on Maven Ant Tasks
> 
>
> Key: CASSANDRA-17750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17750
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build, Dependencies, Packaging
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> Apache Cassandra depends on Maven Ant Tasks (MAT) during build, for declaring 
> dependencies and generating POM files from within build.xml. MAT has long 
> been retired (no commits since maintenance in 2015), has registered CVEs in 
> dependencies (CVE-2017-1000487), and encourages migration to its successor, 
> Maven Artifact Resolver Ant Tasks (MARAT).
> As part of CASSANDRA-16391 
> , mck migrated 
> dependency resolution to MARAT, but MAT is still included in our build for 
> generating POMs since MARAT does not have an alternative to the writepom task 
> provided by MAT. I have a patch ready that removes MAT completely, with a 
> workaround for POM generation.
> I am not advocating for any kind of migration away from Ant to an alternative 
> like Gradle or Maven, just to be extra clear.



--
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-17835) Upgrade ASM, ByteBuddy and Mockito on trunk

[Brandon Williams (Jira)]

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

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

> Upgrade ASM, ByteBuddy and Mockito on trunk
> ---
>
> Key: CASSANDRA-17835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17835
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> In preparation to support Java 17 I would like to update ASM, ByteBuddy and 
> Mockito on trunk.
>  * ASM - from 9.1 to 9.3; From the [release 
> notes|https://asm.ow2.io/versions.html] I don't see anything disturbing for 
> us; 
>  * ByteBuddy - 1.10.10 to 1.12.13; [Release 
> notes|https://github.com/raphw/byte-buddy/blob/master/release-notes.md]; they 
> support Java 17 since 1.12.0 but I did not see an issue updating to the 
> latest version; 
>  * Mockito - 3.2.4 to 4.7.0; [Release 
> notes|https://github.com/mockito/mockito/releases/]. The bump in the major 
> version was due to removing outdated deprecated APIs which it doesn't seem 
> that we use so this is not a breaking change for us. 



--
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-17835) Upgrade ASM, ByteBuddy and Mockito on trunk

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-17835:
--

We should probably check with Jenkins too: 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1887/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1887/pipeline]


> Upgrade ASM, ByteBuddy and Mockito on trunk
> ---
>
> Key: CASSANDRA-17835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17835
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> In preparation to support Java 17 I would like to update ASM, ByteBuddy and 
> Mockito on trunk.
>  * ASM - from 9.1 to 9.3; From the [release 
> notes|https://asm.ow2.io/versions.html] I don't see anything disturbing for 
> us; 
>  * ByteBuddy - 1.10.10 to 1.12.13; [Release 
> notes|https://github.com/raphw/byte-buddy/blob/master/release-notes.md]; they 
> support Java 17 since 1.12.0 but I did not see an issue updating to the 
> latest version; 
>  * Mockito - 3.2.4 to 4.7.0; [Release 
> notes|https://github.com/mockito/mockito/releases/]. The bump in the major 
> version was due to removing outdated deprecated APIs which it doesn't seem 
> that we use so this is not a breaking change for us. 



--
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-17831) Add support in CQLSH for COPY FROM / TO in compact Parquet format

[David Capwell (Jira)]

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

David Capwell commented on CASSANDRA-17831:
---

bq.  "Note: Only use COPY FROM to import datasets that have less than 2 
million rows."
bq. Which leaves users in a quandary, use COPY FROM anyway on larger data sets 
or try to figure out how to install and configure a special purpose, one-off 
tool.

The file format is not the problem, its that large queries are a problem for 
Cassandra. If your use case is actually "larger datasets" than CQLSH and the 
CQL language may not be best for you, and I would recommend the Spark Bulk 
Reader or the MapReduce InputFormat.

bq. Moderate to large data sets don't have a good option for export/import, and 
it would be useful to have one that doesn't require installing another tool, 
but just works out of the box, even if it's a little slower. 

It may be "moderate" to you, but for Cassandra it may actually be "large".  The 
file written to isn't really an issue, its now costly the query gets...  Let's 
take the example you gave of a 1TB CSV file being 130GB in Parquet... now, if 
you used Postgres to do the same thing, would the query fail?  Most likely... 
there are other tools to work with such a large dataset that don't crash the 
server... in this case Cassandra offers MapReduce and Spark support to better 
work with the database, and those tools can export to Parquet today.

> Add support in CQLSH for COPY FROM / TO in compact Parquet format
> -
>
> Key: CASSANDRA-17831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17831
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/cqlsh
>Reporter: Brad Schoening
>Priority: Normal
>
> CQL supports only CSV as a format for import and export. A binary big data 
> format such as Avro and/or Parquet would be more compact and highly portable 
> to other platforms.
> Parquet does not require a schema, so it appears the easier format to support.
> The existing syntax supports adding key value pair options, such as FORMAT = 
> PARQUET
> {{     COPY table_name ... FROM 'file_name'[, 'file2_name', ...] }}
>                      {{[WITH option = 'value' [AND ...]]}}
> Side by side comparisons of CSV and Parquet show a 80% plus saving in disk 
> space.
> [https://towardsdatascience.com/csv-files-for-storage-no-thanks-theres-a-better-option-72c78a414d1d]



--
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-17750) Remove dependency on Maven Ant Tasks

[Michael Semb Wever (Jira)]

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

Michael Semb Wever commented on CASSANDRA-17750:


+1 from me, thanks [~dcapwell]

> Remove dependency on Maven Ant Tasks
> 
>
> Key: CASSANDRA-17750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17750
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build, Dependencies, Packaging
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> Apache Cassandra depends on Maven Ant Tasks (MAT) during build, for declaring 
> dependencies and generating POM files from within build.xml. MAT has long 
> been retired (no commits since maintenance in 2015), has registered CVEs in 
> dependencies (CVE-2017-1000487), and encourages migration to its successor, 
> Maven Artifact Resolver Ant Tasks (MARAT).
> As part of CASSANDRA-16391 
> , mck migrated 
> dependency resolution to MARAT, but MAT is still included in our build for 
> generating POMs since MARAT does not have an alternative to the writepom task 
> provided by MAT. I have a patch ready that removes MAT completely, with a 
> workaround for POM generation.
> I am not advocating for any kind of migration away from Ant to an alternative 
> like Gradle or Maven, just to be extra clear.



--
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-17750) Remove dependency on Maven Ant Tasks

[David Capwell (Jira)]

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

David Capwell commented on CASSANDRA-17750:
---

[~mck] since the patch got rebased on trunk, I will hold off merge until you 
get a chance to review again.

> Remove dependency on Maven Ant Tasks
> 
>
> Key: CASSANDRA-17750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17750
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build, Dependencies, Packaging
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> Apache Cassandra depends on Maven Ant Tasks (MAT) during build, for declaring 
> dependencies and generating POM files from within build.xml. MAT has long 
> been retired (no commits since maintenance in 2015), has registered CVEs in 
> dependencies (CVE-2017-1000487), and encourages migration to its successor, 
> Maven Artifact Resolver Ant Tasks (MARAT).
> As part of CASSANDRA-16391 
> , mck migrated 
> dependency resolution to MARAT, but MAT is still included in our build for 
> generating POMs since MARAT does not have an alternative to the writepom task 
> provided by MAT. I have a patch ready that removes MAT completely, with a 
> workaround for POM generation.
> I am not advocating for any kind of migration away from Ant to an alternative 
> like Gradle or Maven, just to be extra clear.



--
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-17750) Remove dependency on Maven Ant Tasks

[David Capwell (Jira)]

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

David Capwell commented on CASSANDRA-17750:
---

Starting commit

CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17750-trunk-96419495-920E-4459-AED6-52E4CF36A1AF]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17750-trunk-96419495-920E-4459-AED6-52E4CF36A1AF]|[build|unknown]|


> Remove dependency on Maven Ant Tasks
> 
>
> Key: CASSANDRA-17750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17750
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build, Dependencies, Packaging
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> Apache Cassandra depends on Maven Ant Tasks (MAT) during build, for declaring 
> dependencies and generating POM files from within build.xml. MAT has long 
> been retired (no commits since maintenance in 2015), has registered CVEs in 
> dependencies (CVE-2017-1000487), and encourages migration to its successor, 
> Maven Artifact Resolver Ant Tasks (MARAT).
> As part of CASSANDRA-16391 
> , mck migrated 
> dependency resolution to MARAT, but MAT is still included in our build for 
> generating POMs since MARAT does not have an alternative to the writepom task 
> provided by MAT. I have a patch ready that removes MAT completely, with a 
> workaround for POM generation.
> I am not advocating for any kind of migration away from Ant to an alternative 
> like Gradle or Maven, just to be extra clear.



--
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-17835) Upgrade ASM, ByteBuddy and Mockito on trunk

[Ekaterina Dimitrova (Jira)]

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

Ekaterina Dimitrova commented on CASSANDRA-17835:
-

Or maybe [~brandon.williams] , [~maedhroz] or [~mck] can take a look? :) 

> Upgrade ASM, ByteBuddy and Mockito on trunk
> ---
>
> Key: CASSANDRA-17835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17835
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> In preparation to support Java 17 I would like to update ASM, ByteBuddy and 
> Mockito on trunk.
>  * ASM - from 9.1 to 9.3; From the [release 
> notes|https://asm.ow2.io/versions.html] I don't see anything disturbing for 
> us; 
>  * ByteBuddy - 1.10.10 to 1.12.13; [Release 
> notes|https://github.com/raphw/byte-buddy/blob/master/release-notes.md]; they 
> support Java 17 since 1.12.0 but I did not see an issue updating to the 
> latest version; 
>  * Mockito - 3.2.4 to 4.7.0; [Release 
> notes|https://github.com/mockito/mockito/releases/]. The bump in the major 
> version was due to removing outdated deprecated APIs which it doesn't seem 
> that we use so this is not a breaking change for us. 



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Jira]

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

Andres de la Peña edited comment on CASSANDRA-17849 at 8/23/22 5:08 PM:


Git bisect points to CASSANDRA-13010 as the introducer of the test failure.

Its associated commit, 
[e7c9ac05f99cc8a5ee958169c49326e85ab4b25b|https://github.com/apache/cassandra/commit/e7c9ac05f99cc8a5ee958169c49326e85ab4b25b],
 consistently breaks CI for the tests, as it can bee seen in [this repeated 
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2008/workflows/2233dcbc-f0de-4888-b346-92a5bf1a0649].

Indeed, the pre-commit CI runs provided in CASSANDRA-13010 also hit the 
failure, 
[here|https://app.circleci.com/pipelines/github/instaclustr/cassandra/1216/workflows/19d0beb7-310b-4170-8863-608bff7adb40]
 and 
[here|https://app.circleci.com/pipelines/github/instaclustr/cassandra/1216/workflows/5ed6064f-f72d-4b44-bd0f-a47885e10de1].

The previous commit, 
[c4b1c0614e42b4ea2064822d31c28aa5d4f1450a|https://github.com/apache/cassandra/commit/c4b1c0614e42b4ea2064822d31c28aa5d4f1450a],
 doesn't break CI, as it can bee seen in [this repeated 
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2009/workflows/e32acbf3-05e2-4cdb-a60d-154aa4326f78].

The CircleCI config for the repeated runs has been generated with:
{code:java}
.circleci/generate.sh -m \
  -e REPEATED_UTEST_TARGET=testsome \
  -e REPEATED_UTEST_COUNT=100 \
  -e 
REPEATED_UTEST_CLASS=org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest
 \
  -e REPEATED_UTEST_METHODS=testUpgradeSnapshot
{code}
In case someone is curious, the full set of bisect runs can be seen 
[here|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=flaky-testUpgradeSnapshot-trunk-bisect].
 They have been generated with [this 
script|https://gist.github.com/adelapena/35463e5528873224c13f7e2d44a56922], 
with these arguments:
{code}
git bisect start
git bisect good 2c4eff0006cb583dde163b321680ffbc09f5ed52
git bisect bad 4b20ad797ca42643be77aa7d7cf7e35cf2480813
git bisect run ~/bisect.sh \
  -r origin \
  -b flaky-testUpgradeSnapshot-trunk-bisect \
  -m \
  -e REPEATED_UTEST_TARGET=testsome \
  -e REPEATED_UTEST_COUNT=100 \
  -e 
REPEATED_UTEST_CLASS=org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest
 \
  -e REPEATED_UTEST_METHODS=testUpgradeSnapshot
git bisect reset
{code}


was (Author: adelapena):
Git bisect points to CASSANDRA-13010 as the introducer of the test failure.

Its associated commit, 
[e7c9ac05f99cc8a5ee958169c49326e85ab4b25b|https://github.com/apache/cassandra/commit/e7c9ac05f99cc8a5ee958169c49326e85ab4b25b],
 consistently breaks CI for the tests, as it can bee seen in [this repeated 
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2008/workflows/2233dcbc-f0de-4888-b346-92a5bf1a0649].

Indeed, the pre-commit CI runs provided in CASSANDRA-13010 also hit the 
failure, 
[here|https://app.circleci.com/pipelines/github/instaclustr/cassandra/1216/workflows/19d0beb7-310b-4170-8863-608bff7adb40]
 and 
[here|https://app.circleci.com/pipelines/github/instaclustr/cassandra/1216/workflows/5ed6064f-f72d-4b44-bd0f-a47885e10de1].

The previous commit, 
[c4b1c0614e42b4ea2064822d31c28aa5d4f1450a|https://github.com/apache/cassandra/commit/c4b1c0614e42b4ea2064822d31c28aa5d4f1450a],
 doesn't break CI, as it can bee seen in [this repeated 
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2009/workflows/e32acbf3-05e2-4cdb-a60d-154aa4326f78].

The CircleCI config for the repeated runs has been generated with:
{code:java}
.circleci/generate.sh -m \
  -e REPEATED_UTEST_TARGET=testsome \
  -e REPEATED_UTEST_COUNT=100 \
  -e 
REPEATED_UTEST_CLASS=org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest
 \
  -e REPEATED_UTEST_METHODS=testUpgradeSnapshot
{code}
In case someone is curious, the full set of bisect runs can be seen 
[here|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=flaky-testUpgradeSnapshot-trunk-bisect].
 They have been generated with [this 
script|https://gist.github.com/adelapena/35463e5528873224c13f7e2d44a56922], 
with these arguments:
{code:java}
git bisect start
git bisect good 39e89fd636ee4343eb2201820da87881cbc749e2
git bisect bad b70fe08eab2ff31efb1fd4b4b2fa05a22b2cde1c
git bisect run ~/bisect.sh \
  -r origin \
  -b flaky-testUpgradeSnapshot-trunk-bisect \
  -m \
  -e REPEATED_UTEST_TARGET=testsome \
  -e REPEATED_UTEST_COUNT=100 \
  -e 
REPEATED_UTEST_CLASS=org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest
 \
  -e REPEATED_UTEST_METHODS=testUpgradeSnapshot
git bisect reset
{code}

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> 

[jira] [Comment Edited] (CASSANDRA-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Jira]

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

Andres de la Peña edited comment on CASSANDRA-17849 at 8/23/22 5:07 PM:


Git bisect points to CASSANDRA-13010 as the introducer of the test failure.

Its associated commit, 
[e7c9ac05f99cc8a5ee958169c49326e85ab4b25b|https://github.com/apache/cassandra/commit/e7c9ac05f99cc8a5ee958169c49326e85ab4b25b],
 consistently breaks CI for the tests, as it can bee seen in [this repeated 
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2008/workflows/2233dcbc-f0de-4888-b346-92a5bf1a0649].

Indeed, the pre-commit CI runs provided in CASSANDRA-13010 also hit the 
failure, 
[here|https://app.circleci.com/pipelines/github/instaclustr/cassandra/1216/workflows/19d0beb7-310b-4170-8863-608bff7adb40]
 and 
[here|https://app.circleci.com/pipelines/github/instaclustr/cassandra/1216/workflows/5ed6064f-f72d-4b44-bd0f-a47885e10de1].

The previous commit, 
[c4b1c0614e42b4ea2064822d31c28aa5d4f1450a|https://github.com/apache/cassandra/commit/c4b1c0614e42b4ea2064822d31c28aa5d4f1450a],
 doesn't break CI, as it can bee seen in [this repeated 
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2009/workflows/e32acbf3-05e2-4cdb-a60d-154aa4326f78].

The CircleCI config for the repeated runs has been generated with:
{code:java}
.circleci/generate.sh -m \
  -e REPEATED_UTEST_TARGET=testsome \
  -e REPEATED_UTEST_COUNT=100 \
  -e 
REPEATED_UTEST_CLASS=org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest
 \
  -e REPEATED_UTEST_METHODS=testUpgradeSnapshot
{code}
In case someone is curious, the full set of bisect runs can be seen 
[here|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=flaky-testUpgradeSnapshot-trunk-bisect].
 They have been generated with [this 
script|https://gist.github.com/adelapena/35463e5528873224c13f7e2d44a56922], 
with these arguments:
{code:java}
git bisect start
git bisect good 39e89fd636ee4343eb2201820da87881cbc749e2
git bisect bad b70fe08eab2ff31efb1fd4b4b2fa05a22b2cde1c
git bisect run ~/bisect.sh \
  -r origin \
  -b flaky-testUpgradeSnapshot-trunk-bisect \
  -m \
  -e REPEATED_UTEST_TARGET=testsome \
  -e REPEATED_UTEST_COUNT=100 \
  -e 
REPEATED_UTEST_CLASS=org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest
 \
  -e REPEATED_UTEST_METHODS=testUpgradeSnapshot
git bisect reset
{code}


was (Author: adelapena):
Git bisect points to CASSANDRA-13010 as the introducer of the test failure.

Its associated commit, 
[e7c9ac05f99cc8a5ee958169c49326e85ab4b25b|https://github.com/apache/cassandra/commit/e7c9ac05f99cc8a5ee958169c49326e85ab4b25b],
 consistently breaks CI for the tests, as it can bee seen in [this repeated 
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2008/workflows/2233dcbc-f0de-4888-b346-92a5bf1a0649].

Indeed, the pre-commit CI runs provided in CASSANDRA-13010 also hit the 
failure, 
[here|https://app.circleci.com/pipelines/github/instaclustr/cassandra/1216/workflows/19d0beb7-310b-4170-8863-608bff7adb40]
 and 
[here|https://app.circleci.com/pipelines/github/instaclustr/cassandra/1216/workflows/5ed6064f-f72d-4b44-bd0f-a47885e10de1].

The previous commit, 
[c4b1c0614e42b4ea2064822d31c28aa5d4f1450a|https://github.com/apache/cassandra/commit/c4b1c0614e42b4ea2064822d31c28aa5d4f1450a],
 doesn't break CI, as it can bee seen in [this repeated 
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2009/workflows/e32acbf3-05e2-4cdb-a60d-154aa4326f78].

The CircleCI config for the repeated runs has been generated with:
{code:java}
.circleci/generate.sh -m \
  -e REPEATED_UTEST_TARGET=testsome \
  -e REPEATED_UTEST_COUNT=100 \
  -e 
REPEATED_UTEST_CLASS=org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest
 \
  -e REPEATED_UTEST_METHODS=testUpgradeSnapshot
{code}
In case someone is curious, the full set of bisect runs can be seen 
[here|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=flaky-testUpgradeSnapshot-trunk-bisect].
 They have been generated with [this 
script|https://gist.github.com/adelapena/35463e5528873224c13f7e2d44a56922], 
with these arguments:
{code:java}
git bisect start
git bisect good 39e89fd636ee4343eb2201820da87881cbc749e2
git bisect bad b70fe08eab2ff31efb1fd4b4b2fa05a22b2cde1c
git bisect run ~/bisect.sh -l \
  -e REPEATED_UTEST_TARGET=testsome \
  -e REPEATED_UTEST_COUNT=10 \
  -e REPEATED_UTEST_CLASS=org.apache.cassandra.cql3.PagingTest \
  -e REPEATED_UTEST_METHODS=testPaging
git bisect reset
{code}

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>   

[jira] [Commented] (CASSANDRA-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer commented on CASSANDRA-17783:
-

FYI - was asked to re-run with a slightly different circle config to spare some 
resources... pushed a change to the config.yml and a new jdk8 build is running 
- let me know if there's anything else you need, and thanks again for taking a 
look.

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Fix For: 4.x
>
> Attachments: CASSANDRA-17783.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-13010) nodetool compactionstats should say which disk a compaction is writing to

[miklosovic (Jira)]

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

miklosovic updated CASSANDRA-13010:
---
Attachment: signature.asc

Interesting, I was thinking it is some flake as it was totally unrelated and 
was failing on timeout. I did a repeated run on this ticket though.

I take a look too.


Sent from ProtonMail mobile



\

> nodetool compactionstats should say which disk a compaction is writing to
> -
>
> Key: CASSANDRA-13010
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13010
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Local/Compaction, Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
>  Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.2
>
> Attachments: cleanup.png, multiple operations.png, signature.asc
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>




--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Brandon Williams (Jira)]

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

Brandon Williams reassigned CASSANDRA-17849:


Assignee: Brandon Williams

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-17849:
-
   Complexity: Normal
Discovered By: Unit Test
 Severity: Normal
   Status: Open  (was: Triage Needed)

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-17783:
-
Fix Version/s: 4.x

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Fix For: 4.x
>
> Attachments: CASSANDRA-17783.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-17783:
-
Status: Patch Available  (was: Open)

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Fix For: 4.x
>
> Attachments: CASSANDRA-17783.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17762) LWT IF col = NULL is inconsistent with SQL NULL

[Avi Kivity (Jira)]

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

Avi Kivity commented on CASSANDRA-17762:


One problem is that X = NULL is valid SQL, it just has a different meaning than 
CQL. (it means UNKNOWN or NULL). So the syntax can't be deprecated, just the 
interpretation. So I think it makes sense to have a config item indicate which 
interpretation to use, so applications can be migrated independently of the 
update schedule (and problems with mixed version clusters avoided).

> LWT IF col = NULL is inconsistent with SQL NULL
> ---
>
> Key: CASSANDRA-17762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17762
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Semantics
>Reporter: Avi Kivity
>Priority: Normal
> Fix For: 4.x
>
>
> In SQL, any comparison with NULL is NULL, which is interpreted as FALSE in a 
> condition. To test for NULLness, you use IS NULL or IS NOT NULL.
> But LWT uses IF col = NULL as a NULLness test. This is likely to confuse 
> people coming from SQL and hamper attempts to extend the dialect.



--
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-13010) nodetool compactionstats should say which disk a compaction is writing to

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-13010:
--

bq. one test is repeatedly failing (not related to this PR)

I unfortunately confused it with CASSANDRA-17804.

bq. I have opened CASSANDRA-17849 for it.

Thanks, I'll take a look.

> nodetool compactionstats should say which disk a compaction is writing to
> -
>
> Key: CASSANDRA-13010
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13010
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Local/Compaction, Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
>  Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.2
>
> Attachments: cleanup.png, multiple operations.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>




--
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-17831) Add support in CQLSH for COPY FROM / TO in compact Parquet format

[Brad Schoening (Jira)]

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

Brad Schoening reassigned CASSANDRA-17831:
--

Assignee: (was: Brad Schoening)

> Add support in CQLSH for COPY FROM / TO in compact Parquet format
> -
>
> Key: CASSANDRA-17831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17831
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/cqlsh
>Reporter: Brad Schoening
>Priority: Normal
>
> CQL supports only CSV as a format for import and export. A binary big data 
> format such as Avro and/or Parquet would be more compact and highly portable 
> to other platforms.
> Parquet does not require a schema, so it appears the easier format to support.
> The existing syntax supports adding key value pair options, such as FORMAT = 
> PARQUET
> {{     COPY table_name ... FROM 'file_name'[, 'file2_name', ...] }}
>                      {{[WITH option = 'value' [AND ...]]}}
> Side by side comparisons of CSV and Parquet show a 80% plus saving in disk 
> space.
> [https://towardsdatascience.com/csv-files-for-storage-no-thanks-theres-a-better-option-72c78a414d1d]



--
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-17831) Add support in CQLSH for COPY FROM / TO in compact Parquet format

[Abe Ratnofsky (Jira)]

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

Abe Ratnofsky commented on CASSANDRA-17831:
---

[~bschoeni] thanks for elaborating here.

> Which leaves users in a quandary, use COPY FROM anyway on larger data sets or 
> try to figure out how to install and configure a special purpose, one-off 
> tool.

Many users who depend on this kind of functionality in production use something 
like Spark, via the Spark Connector for example: 
[https://github.com/datastax/spark-cassandra-connector]

Users with large data sets often prefer integrations with tools like Spark, so 
this is the happy path out of that quandary. You can always use Spark to 
generate Parquet files, and the Spark Connector supports connection limiting, 
paging, and throughput limiting to avoid adverse impacts on your cluster.

I understand that it feels like there's a missing middle between COPY TO for 
small data, and Spark for large data. One reason for this is that often 
"medium-sized" datasets grow to large datasets soon enough, so the time for 
medium-tools is short.

Maybe this request would make more sense for DataStax's dsbulk to support 
output in Parquet, in addition to CSV and JSON? 
https://docs.datastax.com/en/dsbulk/docs/dsbulkSimpleUnload.html

 

> Add support in CQLSH for COPY FROM / TO in compact Parquet format
> -
>
> Key: CASSANDRA-17831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17831
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/cqlsh
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
>
> CQL supports only CSV as a format for import and export. A binary big data 
> format such as Avro and/or Parquet would be more compact and highly portable 
> to other platforms.
> Parquet does not require a schema, so it appears the easier format to support.
> The existing syntax supports adding key value pair options, such as FORMAT = 
> PARQUET
> {{     COPY table_name ... FROM 'file_name'[, 'file2_name', ...] }}
>                      {{[WITH option = 'value' [AND ...]]}}
> Side by side comparisons of CSV and Parquet show a 80% plus saving in disk 
> space.
> [https://towardsdatascience.com/csv-files-for-storage-no-thanks-theres-a-better-option-72c78a414d1d]



--
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-13010) nodetool compactionstats should say which disk a compaction is writing to

[Jira]

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

Andres de la Peña edited comment on CASSANDRA-13010 at 8/23/22 4:28 PM:


{quote}one test is repeatedly failing (not related to this PR)
{quote}
I guess that's 
{{{}org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot{}}}.
 It seems caused by this patch, since [repeated runs on 
CI|https://app.circleci.com/pipelines/github/adelapena/cassandra/2009/workflows/e32acbf3-05e2-4cdb-a60d-154aa4326f78]
 for [the immediately previous 
commit|https://github.com/adelapena/cassandra/commit/c4b1c0614e42b4ea2064822d31c28aa5d4f1450a]
 don't hit it.

I have opened CASSANDRA-17849 for it.


was (Author: adelapena):
{quote}one test is repeatedly failing (not related to this PR)
{quote}
I guess that's 
{{{}org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot{}}}.
 It seems caused by this patch, since [repeated runs on CI for the immediately 
previous 
commit|https://app.circleci.com/pipelines/github/adelapena/cassandra/2009/workflows/e32acbf3-05e2-4cdb-a60d-154aa4326f78]
 don't hit it.

I have opened CASSANDRA-17849 for it.

> nodetool compactionstats should say which disk a compaction is writing to
> -
>
> Key: CASSANDRA-13010
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13010
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Local/Compaction, Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
>  Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.2
>
> Attachments: cleanup.png, multiple operations.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>




--
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-13010) nodetool compactionstats should say which disk a compaction is writing to

[Jira]

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

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

{quote}one test is repeatedly failing (not related to this PR)
{quote}
I guess that's 
{{{}org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot{}}}.
 It seems caused by this patch, since [repeated runs on CI for the immediately 
previous 
commit|https://app.circleci.com/pipelines/github/adelapena/cassandra/2009/workflows/e32acbf3-05e2-4cdb-a60d-154aa4326f78]
 don't hit it.

I have opened CASSANDRA-17849 for it.

> nodetool compactionstats should say which disk a compaction is writing to
> -
>
> Key: CASSANDRA-13010
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13010
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Local/Compaction, Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
>  Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.2
>
> Attachments: cleanup.png, multiple operations.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>




--
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-17842) Add the ability for operators to allow intentional loosening of definition of "empty" in Gossip for specific edge case failure scenarios

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17842:
--
Reviewers: David Capwell
   Status: Review In Progress  (was: Patch Available)

> Add the ability for operators to allow intentional loosening of definition of 
> "empty" in Gossip for specific edge case failure scenarios
> 
>
> Key: CASSANDRA-17842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17842
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Gossip
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> Right now {{empty}} is very specific to a single edge case (i.e. in 
> {{isEmptyWithoutStatus()}} our usage of hbState() + applicationState), but 
> there are other failure cases which block host replacements and require 
> intrusive workarounds and human intervention to recover from when you have 
> something in hbState() you don't expect.
> If we allow opt-in to a more risky (i.e. we don’t know how we got there) 
> definition of empty, then host replacements can make progress even when 
> Gossip's gotten into a bad state. Which it does. All too often.
> This parameter will obviously need some NEWS.txt and other documentation 
> around it to explain the context for end users.
> Now that I think of it, general "how to troubleshoot Gossip problems" might 
> be worth writing up and including this as part of it for operators and users, 
> specifically on our 
> [Troubleshooting|https://cassandra.apache.org/doc/latest/cassandra/troubleshooting/index.html]
>  page. Probably create that as another ticket and defer that update to there 
> and rely on news.txt and the param documentation for this one just to get the 
> functionality into the system for operators who need it.
> A touch more context:
> {code}
> // In the very specific case where hbState.isEmpty and STATUS is missing, 
> this is known to be safe to "fake"
> // the data, as this happens when the gossip state isn't coming from the node 
> but instead from a peer who
> // restarted and is missing the node's state
> //
> // When hbState is *not* empty, then the node gossiped an empty STATUS, this 
> happens during bootstrap and it's not
> // possible to tell if this is ok or not (we can't really tell if the node is 
> dead or having networking issues);
> // for these cases we need to allow an external actor to verify and inform 
> Cassandra that it is safe; this is done by
> // updating the LOOSE_DEF_OF_EMPTY_ENABLED field.
> {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-17842) Add the ability for operators to allow intentional loosening of definition of "empty" in Gossip for specific edge case failure scenarios

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17842:
--
  Fix Version/s: 4.2
 (was: 4.x)
Source Control Link: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=d0b9532f2b87a17a0508d0637556f2f3e8d0fd94
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Add the ability for operators to allow intentional loosening of definition of 
> "empty" in Gossip for specific edge case failure scenarios
> 
>
> Key: CASSANDRA-17842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17842
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Gossip
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.2
>
>
> Right now {{empty}} is very specific to a single edge case (i.e. in 
> {{isEmptyWithoutStatus()}} our usage of hbState() + applicationState), but 
> there are other failure cases which block host replacements and require 
> intrusive workarounds and human intervention to recover from when you have 
> something in hbState() you don't expect.
> If we allow opt-in to a more risky (i.e. we don’t know how we got there) 
> definition of empty, then host replacements can make progress even when 
> Gossip's gotten into a bad state. Which it does. All too often.
> This parameter will obviously need some NEWS.txt and other documentation 
> around it to explain the context for end users.
> Now that I think of it, general "how to troubleshoot Gossip problems" might 
> be worth writing up and including this as part of it for operators and users, 
> specifically on our 
> [Troubleshooting|https://cassandra.apache.org/doc/latest/cassandra/troubleshooting/index.html]
>  page. Probably create that as another ticket and defer that update to there 
> and rely on news.txt and the param documentation for this one just to get the 
> functionality into the system for operators who need it.
> A touch more context:
> {code}
> // In the very specific case where hbState.isEmpty and STATUS is missing, 
> this is known to be safe to "fake"
> // the data, as this happens when the gossip state isn't coming from the node 
> but instead from a peer who
> // restarted and is missing the node's state
> //
> // When hbState is *not* empty, then the node gossiped an empty STATUS, this 
> happens during bootstrap and it's not
> // possible to tell if this is ok or not (we can't really tell if the node is 
> dead or having networking issues);
> // for these cases we need to allow an external actor to verify and inform 
> Cassandra that it is safe; this is done by
> // updating the LOOSE_DEF_OF_EMPTY_ENABLED field.
> {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-17842) Add the ability for operators to allow intentional loosening of definition of "empty" in Gossip for specific edge case failure scenarios

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17842:
--
Status: Ready to Commit  (was: Review In Progress)

> Add the ability for operators to allow intentional loosening of definition of 
> "empty" in Gossip for specific edge case failure scenarios
> 
>
> Key: CASSANDRA-17842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17842
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Cluster/Gossip
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> Right now {{empty}} is very specific to a single edge case (i.e. in 
> {{isEmptyWithoutStatus()}} our usage of hbState() + applicationState), but 
> there are other failure cases which block host replacements and require 
> intrusive workarounds and human intervention to recover from when you have 
> something in hbState() you don't expect.
> If we allow opt-in to a more risky (i.e. we don’t know how we got there) 
> definition of empty, then host replacements can make progress even when 
> Gossip's gotten into a bad state. Which it does. All too often.
> This parameter will obviously need some NEWS.txt and other documentation 
> around it to explain the context for end users.
> Now that I think of it, general "how to troubleshoot Gossip problems" might 
> be worth writing up and including this as part of it for operators and users, 
> specifically on our 
> [Troubleshooting|https://cassandra.apache.org/doc/latest/cassandra/troubleshooting/index.html]
>  page. Probably create that as another ticket and defer that update to there 
> and rely on news.txt and the param documentation for this one just to get the 
> functionality into the system for operators who need it.
> A touch more context:
> {code}
> // In the very specific case where hbState.isEmpty and STATUS is missing, 
> this is known to be safe to "fake"
> // the data, as this happens when the gossip state isn't coming from the node 
> but instead from a peer who
> // restarted and is missing the node's state
> //
> // When hbState is *not* empty, then the node gossiped an empty STATUS, this 
> happens during bootstrap and it's not
> // possible to tell if this is ok or not (we can't really tell if the node is 
> dead or having networking issues);
> // for these cases we need to allow an external actor to verify and inform 
> Cassandra that it is safe; this is done by
> // updating the LOOSE_DEF_OF_EMPTY_ENABLED field.
> {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

[cassandra] branch trunk updated: Add the ability for operators to loosen the definition of "empty" for edge cases

[jmckenzie]

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new d0b9532f2b Add the ability for operators to loosen the definition of 
"empty" for edge cases
d0b9532f2b is described below

commit d0b9532f2b87a17a0508d0637556f2f3e8d0fd94
Author: Josh McKenzie 
AuthorDate: Mon Aug 22 15:04:19 2022 -0400

Add the ability for operators to loosen the definition of "empty" for edge 
cases

Patch by David Capwell; reviewed by Josh McKenzie, Yifan Cai, and Sam 
Tunnicliffe for CASSANDRA-17842

Co-authored-by: David Capwell 
Co-authored-by: Josh McKenzie 
---
 CHANGES.txt|  1 +
 NEWS.txt   | 18 +-
 .../cassandra/config/CassandraRelevantProperties.java  |  3 +++
 src/java/org/apache/cassandra/gms/EndpointState.java   | 15 ++-
 src/java/org/apache/cassandra/gms/Gossiper.java| 13 +
 src/java/org/apache/cassandra/gms/GossiperMBean.java   |  3 +++
 6 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index 84975ef1b9..dee8a5e741 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.2
+ * Add the ability for operators to loosen the definition of "empty" for edge 
cases (CASSANDRA-17842)
  * Fix potential out of range exception on column index downsampling 
(CASSANDRA-17839)
  * Introduce target directory to vtable output for sstable_tasks and for 
compactionstats (CASSANDRA-13010)
  * Read/Write/Truncate throw RequestFailure in a race condition with callback 
timeouts, should return Timeout instead (CASSANDRA-17828)
diff --git a/NEWS.txt b/NEWS.txt
index fe87f0cd78..b488acbf20 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -77,12 +77,20 @@ New features
 - It is possible to list ephemeral snapshots by nodetool listsnaphots 
command when flag "-e" is specified.
 - Added a new flag to `nodetool profileload` and JMX endpoint to set up 
recurring profile load generation on specified
   intervals (see CASSANDRA-17821)
+- Added a new property, gossiper.loose_empty_enabled, to allow for a 
looser definition of "empty" when
+  considering the heartbeat state of another node in Gossip. This should 
only be used by knowledgeable
+  operators in the following scenarios:
+
+  Currently "empty" w/regards to heartbeat state in Gossip is very 
specific to a single edge case (i.e. in
+  isEmptyWithoutStatus() our usage of hbState() + applicationState), 
however there are other failure cases which
+  block host replacements and require intrusive workarounds and human 
intervention to recover from when you
+  have something in hbState() you don't expect. See CASSANDRA-17842 for 
further details.
 
 Upgrading
 -
 - Ephemeral marker files for snapshots done by repairs are not created 
anymore,
-  there is a dedicated flag in snapshot manifest instead. On upgrade of a 
node to version 4.2, on node's start, in case there 
-  are such ephemeral snapshots on disk, they will be deleted (same 
behaviour as before) and any new ephemeral snapshots 
+  there is a dedicated flag in snapshot manifest instead. On upgrade of a 
node to version 4.2, on node's start, in case there
+  are such ephemeral snapshots on disk, they will be deleted (same 
behaviour as before) and any new ephemeral snapshots
   will stop to create ephemeral marker files as flag in a snapshot 
manifest was introduced instead.
 
 Deprecation
@@ -427,7 +435,7 @@ Upgrading
 - Native protocol v5 is promoted from beta in this release. The wire 
format has changed
   significantly and users should take care to ensure client drivers are 
upgraded to a version
   with support for the final v5 format, if currently connecting over 
v5-beta. (CASSANDRA-15299, CASSANDRA-14973)
-- Cassandra removed support for the OldNetworkTopologyStrategy. Before 
upgrading you will need to change the 
+- Cassandra removed support for the OldNetworkTopologyStrategy. Before 
upgrading you will need to change the
   replication strategy for the keyspaces using this strategy to the 
NetworkTopologyStrategy. (CASSANDRA-13990)
 - Sstables for tables using with a frozen UDT written by C* 3.0 appear as 
corrupted.
 
@@ -625,7 +633,7 @@ Upgrading
   reason, a opt-in system property has been added to disable the fix:
 -Dcassandra.unsafe.disable-serial-reads-linearizability=true
   Use this flag at your own risk as it revert SERIAL reads to the 
incorrect behavior of
-  previous versions. See CASSANDRA-12126 for details. 
+  previous versions. See CASSANDRA-12126 for details.
 - SASI's `max_compaction_flush_memory_in_mb` setting was previously 
getting interpreted in bytes. From 3.11.8
   it is correctly 

[jira] [Updated] (CASSANDRA-17839) Out of range exception on column index downsampling

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17839:
--
  Fix Version/s: 4.2
  Since Version: 4.0
Source Control Link: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=0e855c4b7c157b7ba63bb7377bc441260d76556f
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Out of range exception on column index downsampling
> ---
>
> Key: CASSANDRA-17839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17839
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.2
>
>
> We've seen a histogram overflow exception in the wild; an 
> IllegalArgumentException w/{{{}Out of range{}}} on {{{}Ints.checkedCast{}}}. 
> Looks like we need to tune the {{defaultPartitionSizeHistogram}} a bit and be 
> more graceful about handling and degrading gracefully in {{SegmentedFile}}



--
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] branch trunk updated: Fix potential out of range exception on column index downsampling

[jmckenzie]

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 0e855c4b7c Fix potential out of range exception on column index 
downsampling
0e855c4b7c is described below

commit 0e855c4b7c157b7ba63bb7377bc441260d76556f
Author: Josh McKenzie 
AuthorDate: Mon Aug 22 14:28:50 2022 -0400

Fix potential out of range exception on column index downsampling

Patch by Marcus Eriksson; reviewed by Josh McKenzie, Jon Meredith, and 
Caleb Rackliffe for CASSANDRA-17839

Co-authored-by: Marcus Eriksson 
Co-authored-by: Josh McKenzie 
---
 CHANGES.txt|  1 +
 .../cassandra/io/sstable/format/big/BigTableWriter.java| 14 +-
 .../cassandra/io/sstable/metadata/MetadataCollector.java   |  5 +++--
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index 43b68541db..84975ef1b9 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.2
+ * Fix potential out of range exception on column index downsampling 
(CASSANDRA-17839)
  * Introduce target directory to vtable output for sstable_tasks and for 
compactionstats (CASSANDRA-13010)
  * Read/Write/Truncate throw RequestFailure in a race condition with callback 
timeouts, should return Timeout instead (CASSANDRA-17828)
  * Add ability to log load profiles at fixed intervals (CASSANDRA-17821)
diff --git 
a/src/java/org/apache/cassandra/io/sstable/format/big/BigTableWriter.java 
b/src/java/org/apache/cassandra/io/sstable/format/big/BigTableWriter.java
index e8dff32fbc..0adb9df227 100644
--- a/src/java/org/apache/cassandra/io/sstable/format/big/BigTableWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/format/big/BigTableWriter.java
@@ -356,7 +356,19 @@ public class BigTableWriter extends SSTableWriter
 ifile = 
iwriter.builder.bufferSize(indexBufferSize).complete(boundary.indexLength);
 if (compression)
 dbuilder.withCompressionMetadata(((CompressedSequentialWriter) 
dataFile).open(boundary.dataLength));
-int dataBufferSize = 
optimizationStrategy.bufferSize(stats.estimatedPartitionSize.percentile(DatabaseDescriptor.getDiskOptimizationEstimatePercentile()));
+
+EstimatedHistogram partitionSizeHistogram = 
stats.estimatedPartitionSize;
+
+if (partitionSizeHistogram.isOverflowed())
+{
+logger.warn("Estimated partition size histogram for '{}' is 
overflowed ({} values greater than {}). " +
+"Clearing the overflow bucket to allow for 
degraded mean and percentile calculations...",
+descriptor, 
partitionSizeHistogram.overflowCount(), 
partitionSizeHistogram.getLargestBucketOffset());
+
+partitionSizeHistogram.clearOverflow();
+}
+
+int dataBufferSize = 
optimizationStrategy.bufferSize(partitionSizeHistogram.percentile(DatabaseDescriptor.getDiskOptimizationEstimatePercentile()));
 dfile = 
dbuilder.bufferSize(dataBufferSize).complete(boundary.dataLength);
 invalidateCacheAtBoundary(dfile);
 sstable = SSTableReader.internalOpen(descriptor,
diff --git 
a/src/java/org/apache/cassandra/io/sstable/metadata/MetadataCollector.java 
b/src/java/org/apache/cassandra/io/sstable/metadata/MetadataCollector.java
index 1375331ce5..4786a1cbbc 100644
--- a/src/java/org/apache/cassandra/io/sstable/metadata/MetadataCollector.java
+++ b/src/java/org/apache/cassandra/io/sstable/metadata/MetadataCollector.java
@@ -58,8 +58,9 @@ public class MetadataCollector implements 
PartitionStatisticsCollector
 
 static EstimatedHistogram defaultPartitionSizeHistogram()
 {
-// EH of 150 can track a max value of 1697806495183, i.e., > 1.5PB
-return new EstimatedHistogram(150);
+// EH of 155 can track a max value of 3520571548412 i.e. 3.5TB
+return new EstimatedHistogram(155);
+
 }
 
 static TombstoneHistogram defaultTombstoneDropTimeHistogram()


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

[jira] [Commented] (CASSANDRA-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Jira]

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

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

Git bisect points to CASSANDRA-13010 as the introducer of the test failure.

Its associated commit, 
[e7c9ac05f99cc8a5ee958169c49326e85ab4b25b|https://github.com/apache/cassandra/commit/e7c9ac05f99cc8a5ee958169c49326e85ab4b25b],
 consistently breaks CI for the tests, as it can bee seen in [this repeated 
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2008/workflows/2233dcbc-f0de-4888-b346-92a5bf1a0649].

Indeed, the pre-commit CI runs provided in CASSANDRA-13010 also hit the 
failure, 
[here|https://app.circleci.com/pipelines/github/instaclustr/cassandra/1216/workflows/19d0beb7-310b-4170-8863-608bff7adb40]
 and 
[here|https://app.circleci.com/pipelines/github/instaclustr/cassandra/1216/workflows/5ed6064f-f72d-4b44-bd0f-a47885e10de1].

The previous commit, 
[c4b1c0614e42b4ea2064822d31c28aa5d4f1450a|https://github.com/apache/cassandra/commit/c4b1c0614e42b4ea2064822d31c28aa5d4f1450a],
 doesn't break CI, as it can bee seen in [this repeated 
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/2009/workflows/e32acbf3-05e2-4cdb-a60d-154aa4326f78].

The CircleCI config for the repeated runs has been generated with:
{code:java}
.circleci/generate.sh -m \
  -e REPEATED_UTEST_TARGET=testsome \
  -e REPEATED_UTEST_COUNT=100 \
  -e 
REPEATED_UTEST_CLASS=org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest
 \
  -e REPEATED_UTEST_METHODS=testUpgradeSnapshot
{code}
In case someone is curious, the full set of bisect runs can be seen 
[here|https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=flaky-testUpgradeSnapshot-trunk-bisect].
 They have been generated with [this 
script|https://gist.github.com/adelapena/35463e5528873224c13f7e2d44a56922], 
with these arguments:
{code:java}
git bisect start
git bisect good 39e89fd636ee4343eb2201820da87881cbc749e2
git bisect bad b70fe08eab2ff31efb1fd4b4b2fa05a22b2cde1c
git bisect run ~/bisect.sh -l \
  -e REPEATED_UTEST_TARGET=testsome \
  -e REPEATED_UTEST_COUNT=10 \
  -e REPEATED_UTEST_CLASS=org.apache.cassandra.cql3.PagingTest \
  -e REPEATED_UTEST_METHODS=testPaging
git bisect reset
{code}

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17841) Log anticompaction cancellation at INFO level

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17841:
--
  Fix Version/s: 4.2
 (was: 4.x)
Source Control Link: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=1c714e43e6bad82ca24e095385a24fe9b33dd4f4
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Log anticompaction cancellation at INFO level
> -
>
> Key: CASSANDRA-17841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17841
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.2
>
>
> If anticompaction can be interrupted after repair as a normal part of 
> operations we should log at INFO level rather than error.



--
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] branch trunk updated: Log anticompaction cancellation at INFO level

[jmckenzie]

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 1c714e43e6 Log anticompaction cancellation at INFO level
1c714e43e6 is described below

commit 1c714e43e6bad82ca24e095385a24fe9b33dd4f4
Author: Josh McKenzie 
AuthorDate: Mon Aug 22 14:16:30 2022 -0400

Log anticompaction cancellation at INFO level

Patch by Marcus Eriksson; reviewed by Caleb Rackliffe, David Capwell, and 
Josh McKenzie for CASSANDRA-17841

Co-authored-by: Marcus Eriksson 
Co-authored-by: Josh McKenzie 
---
 .../apache/cassandra/db/compaction/CompactionManager.java   | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java 
b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
index c843adfda0..5906ac294a 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
@@ -1756,10 +1756,17 @@ public class CompactionManager implements 
CompactionManagerMBean
 }
 catch (Throwable e)
 {
-if (e instanceof CompactionInterruptedException && 
isCancelled.getAsBoolean())
+if (e instanceof CompactionInterruptedException)
 {
-logger.info("Anticompaction has been canceled for session {}", 
pendingRepair);
-logger.trace(e.getMessage(), e);
+if (isCancelled.getAsBoolean())
+{
+logger.info("Anticompaction has been canceled for session 
{}", pendingRepair);
+logger.trace(e.getMessage(), e);
+}
+else
+{
+logger.info("Anticompaction for session {} has been 
stopped by request.", pendingRepair);
+}
 }
 else
 {


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

[jira] [Comment Edited] (CASSANDRA-17762) LWT IF col = NULL is inconsistent with SQL NULL

[Benjamin Lerer (Jira)]

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

Benjamin Lerer edited comment on CASSANDRA-17762 at 8/23/22 3:52 PM:
-

 

{quote}I'd be in favor of keeping the new syntax in line w/ SQL\{quote}

 

Even without looking at SQL we are also not consistent within CQL where we use 
x {{= null}} and  x != null for LWT but {{IS NOT NULL}} for Materialized views.

Utilizing {{IS NULL}} and {{IS NOT NULL}} everywhere including for column 
filtering (CASSANDRA-10715) make total sense in my opinion.

It should also be easy to support both syntaxes ({{{}x = null{}}}/{{{}X IS 
NULL{}}}) while warning the user that the first syntax is deprecated until the 
next major release.

 


was (Author: blerer):
{quote}I'd be in favor of keeping the new syntax in line w/ SQL\{quote}

Even without looking at SQL we are also not consistent within CQL where we use 
x {{= null}} and  x != null for LWT but {{IS NOT NULL}} for Materialized views.

Utilizing {{IS NULL}} and {{IS NOT NULL}} everywhere including for column 
filtering (CASSANDRA-10715) make total sense in my opinion.

It should also be easy to support both syntaxes (\{{x = null}}/\{{X IS NULL}}) 
while warning the user that the first syntax is deprecated until the next major 
release.

 

> LWT IF col = NULL is inconsistent with SQL NULL
> ---
>
> Key: CASSANDRA-17762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17762
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Semantics
>Reporter: Avi Kivity
>Priority: Normal
> Fix For: 4.x
>
>
> In SQL, any comparison with NULL is NULL, which is interpreted as FALSE in a 
> condition. To test for NULLness, you use IS NULL or IS NOT NULL.
> But LWT uses IF col = NULL as a NULLness test. This is likely to confuse 
> people coming from SQL and hamper attempts to extend the dialect.



--
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-17762) LWT IF col = NULL is inconsistent with SQL NULL

[Benjamin Lerer (Jira)]

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

Benjamin Lerer edited comment on CASSANDRA-17762 at 8/23/22 3:52 PM:
-

 
{quote}I'd be in favor of keeping the new syntax in line w/ SQL
{quote}
 

Even without looking at SQL we are also not consistent within CQL where we use 
x {{= null}} and  x != null for LWT but {{IS NOT NULL}} for Materialized views.

Utilizing {{IS NULL}} and {{IS NOT NULL}} everywhere including for column 
filtering (CASSANDRA-10715) make total sense in my opinion.

It should also be easy to support both syntaxes ({{{}x = null{}}}/{{{}X IS 
NULL{}}}) while warning the user that the first syntax is deprecated until the 
next major release.

 


was (Author: blerer):
 

{quote}I'd be in favor of keeping the new syntax in line w/ SQL\{quote}

 

Even without looking at SQL we are also not consistent within CQL where we use 
x {{= null}} and  x != null for LWT but {{IS NOT NULL}} for Materialized views.

Utilizing {{IS NULL}} and {{IS NOT NULL}} everywhere including for column 
filtering (CASSANDRA-10715) make total sense in my opinion.

It should also be easy to support both syntaxes ({{{}x = null{}}}/{{{}X IS 
NULL{}}}) while warning the user that the first syntax is deprecated until the 
next major release.

 

> LWT IF col = NULL is inconsistent with SQL NULL
> ---
>
> Key: CASSANDRA-17762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17762
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Semantics
>Reporter: Avi Kivity
>Priority: Normal
> Fix For: 4.x
>
>
> In SQL, any comparison with NULL is NULL, which is interpreted as FALSE in a 
> condition. To test for NULLness, you use IS NULL or IS NOT NULL.
> But LWT uses IF col = NULL as a NULLness test. This is likely to confuse 
> people coming from SQL and hamper attempts to extend the dialect.



--
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-17762) LWT IF col = NULL is inconsistent with SQL NULL

[Benjamin Lerer (Jira)]

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

Benjamin Lerer commented on CASSANDRA-17762:


{quote}I'd be in favor of keeping the new syntax in line w/ SQL\{quote}

Even without looking at SQL we are also not consistent within CQL where we use 
x {{= null}} and  x != null for LWT but {{IS NOT NULL}} for Materialized views.

Utilizing {{IS NULL}} and {{IS NOT NULL}} everywhere including for column 
filtering (CASSANDRA-10715) make total sense in my opinion.

It should also be easy to support both syntaxes (\{{x = null}}/\{{X IS NULL}}) 
while warning the user that the first syntax is deprecated until the next major 
release.

 

> LWT IF col = NULL is inconsistent with SQL NULL
> ---
>
> Key: CASSANDRA-17762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17762
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Semantics
>Reporter: Avi Kivity
>Priority: Normal
> Fix For: 4.x
>
>
> In SQL, any comparison with NULL is NULL, which is interpreted as FALSE in a 
> condition. To test for NULLness, you use IS NULL or IS NOT NULL.
> But LWT uses IF col = NULL as a NULLness test. This is likely to confuse 
> people coming from SQL and hamper attempts to extend the dialect.



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Jira]

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

Andres de la Peña updated CASSANDRA-17849:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test 
Failure(12990)

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Jira]

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

Andres de la Peña updated CASSANDRA-17849:
--
Fix Version/s: 4.x

> Test failure: 
> org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
> -
>
> Key: CASSANDRA-17849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> The test 
> {{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
>  is flaky on trunk, [as reported by 
> Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> * 
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
> {code}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at java.util.Vector.forEach(Vector.java:1277)
>   at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
>   at java.util.Vector.forEach(Vector.java:1277)
> {code}
> It seems that the test gets stuck until JUnit timeouts.



--
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-17849) Test failure: org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot

[Jira]

Andres de la Peña created CASSANDRA-17849:
-

 Summary: Test failure: 
org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot
 Key: CASSANDRA-17849
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17849
 Project: Cassandra
  Issue Type: Bug
  Components: Test/unit
Reporter: Andres de la Peña


The test 
{{org.apache.cassandra.tools.StandaloneUpgraderOnSStablesTest.testUpgradeSnapshot}}
 is flaky on trunk, [as reported by 
Butler|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot]:
* 
https://ci-cassandra.apache.org/job/Cassandra-trunk/1287/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
* 
https://ci-cassandra.apache.org/job/Cassandra-trunk/1286/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/
* 
https://ci-cassandra.apache.org/job/Cassandra-trunk/1285/testReport/org.apache.cassandra.tools/StandaloneUpgraderOnSStablesTest/testUpgradeSnapshot/

{code}
Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
Error Message
Timeout occurred. Please note the time in the report does not reflect the time 
until the timeout.
Stacktrace
junit.framework.AssertionFailedError: Timeout occurred. Please note the time in 
the report does not reflect the time until the timeout.
at java.util.Vector.forEach(Vector.java:1277)
at java.util.Vector.forEach(Vector.java:1277)
at java.util.Vector.forEach(Vector.java:1277)
at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
at java.util.Vector.forEach(Vector.java:1277)
{code}
It seems that the test gets stuck until JUnit timeouts.



--
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-17831) Add support in CQLSH for COPY FROM / TO in compact Parquet format

[Brad Schoening (Jira)]

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

Brad Schoening commented on CASSANDRA-17831:


[~aratnofsky] this Jira is aiming to address a problem described in the 
DataStax documentation on CQLSH 'COPY TO': 

     "{_}Note: Only use COPY FROM to import datasets that have less than 2 
million rows{_}."

Which leaves users in a quandary, use COPY FROM anyway on larger data sets or 
try to figure out how to install and configure a special purpose, one-off tool. 
 This feature would support users, not admins.  Users don't have access to 
SSTables and have authorized and authenticated access with roles and 
permissions over port 9042.  sstabledump doesn't really work in a DBaaS 
environment for users and, if you were to export sstables, with RF=3 you would 
have 3X the data volume.

Adding a big data friendly compact binary format for export in CQLSH would be 
both space and time efficient.  It would also be portable to other platforms, 
not a proprietary format.  Either Avro or Parquet would be a good choice, but 
it could be something else. 

This article [CSV Files for Storage? No Thanks. There’s a Better Option | by 
Dario Radečić | Towards Data 
Science|https://towardsdatascience.com/csv-files-for-storage-no-thanks-theres-a-better-option-72c78a414d1d]
 found 1TB of data in CSV files shrank to 130GB in parquet – and was 33X faster 
to read the data.

Vertica, for example, has an export to parquet in its SQL syntax:  

{{     EXPORT TO PARQUET ( directory = 'path') AS SELECT query‑expression;}}

          See: [EXPORT TO PARQUET 
(vertica.com)|https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/SQLReferenceManual/Statements/EXPORTTOPARQUET.htm]

Since CQSH has COPY FROM/TO with one format and Python offers great data 
wrangling libraries, implementation is mostly straightforward.  Yes, there are 
third party tools which can be setup, configured, and will be faster on very 
large data sets >TB, but it would be great to have a first-class, easy to use, 
efficient option to export data in moderate size  Add support in CQLSH for COPY FROM / TO in compact Parquet format
> -
>
> Key: CASSANDRA-17831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17831
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/cqlsh
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
>
> CQL supports only CSV as a format for import and export. A binary big data 
> format such as Avro and/or Parquet would be more compact and highly portable 
> to other platforms.
> Parquet does not require a schema, so it appears the easier format to support.
> The existing syntax supports adding key value pair options, such as FORMAT = 
> PARQUET
> {{     COPY table_name ... FROM 'file_name'[, 'file2_name', ...] }}
>                      {{[WITH option = 'value' [AND ...]]}}
> Side by side comparisons of CSV and Parquet show a 80% plus saving in disk 
> space.
> [https://towardsdatascience.com/csv-files-for-storage-no-thanks-theres-a-better-option-72c78a414d1d]



--
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-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset

[Jira]

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

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

It seems that {{org.apache.cassandra.distributed.test.SchemaTest.schemaReset}} 
for [the last version of the 
patch|https://github.com/apache/cassandra/pull/1804/commits/b66bcfc9cfe7114f6f372ef07711c40d2cc5cf64]
 is flaky in the runs right above 
([j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2002/workflows/afb88a8e-94e7-46c7-a3d9-b0a5e4f33ed6]
 
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2002/workflows/d60ab633-f080-4aa1-8348-6bc0de9ed11f]).
 It has been repeatedly run with its entire suite, instead of just running the 
{{schemaReset}} method in isolation:
{code:java}
.circleci/generate.sh -m \
  -e REPEATED_UTEST_TARGET=test-jvm-dtest-some \
  -e REPEATED_UTEST_COUNT=400 \
  -e REPEATED_UTEST_CLASS=org.apache.cassandra.distributed.test.SchemaTest
{code}

> Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
> --
>
> Key: CASSANDRA-17819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17819
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> The test 
> {{{}org.apache.cassandra.distributed.test.SchemaTest.schemaReset{}}}, 
> recently introduced by CASSANDRA-17658, is flaky on 4.1 and trunk:
>  * 4.1: 
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/134/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
>  * trunk: 
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1265/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> {code:java}
> Error Message
> Condition with lambda expression in 
> org.apache.cassandra.distributed.test.SchemaTest that uses 
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> Stacktrace
> org.awaitility.core.ConditionTimeoutException: Condition with lambda 
> expression in org.apache.cassandra.distributed.test.SchemaTest that uses 
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
>   at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
>   at 
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
>   at 
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
>   at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
>   at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
>   at 
> org.apache.cassandra.distributed.test.SchemaTest.schemaReset(SchemaTest.java:115)
>   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)
> Standard Output
> INFO  [main]  2022-08-15 15:02:14,783 Reflections.java:219 - 
> Reflections took 1873 ms to scan 8 urls, producing 1754 keys and 6912 values
> INFO  [main]  2022-08-15 15:02:16,407 Reflections.java:219 - 
> Reflections took 1561 ms to scan 8 urls, producing 1754 keys and 6912 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2022-08-15 15:02:17,554 InternalLoggerFactory.ja
> ...[truncated 1761288 chars]...
> cutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
> INFO  [node2_isolatedExecutor:3] node2 2022-08-15 15:03:52,096 
> MessagingService.java:519 - Waiting for messaging service to quiesce
> {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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer commented on CASSANDRA-17783:
-

[https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra?branch=CASSANDRA-17783]
 should have what we need for CI I believe... I kicked off the jdk11 and jdk8 
pre-commit tests.

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Attachments: CASSANDRA-17783.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer commented on CASSANDRA-17783:
-

I can rebase it on trunk and dust off my "make CI run faster" handbook and 
submit a PR so Circle can take a look... give me an hour or so and I can at 
least have a rebased patch.

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Attachments: CASSANDRA-17783.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset

[Jira]

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

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

Just started some additional repeated runs for all the modified tests:
||Test||CI||
|o.a.c.schema.SchemaTest|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2001/workflows/0fdc2c4a-3b6e-4908-b268-d8c70943d732]
 
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2001/workflows/71998f6e-e020-403d-a0b3-3ce8cef7990e]|
|o.a.c.distributed.test.SchemaTest|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2002/workflows/afb88a8e-94e7-46c7-a3d9-b0a5e4f33ed6]
 
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2002/workflows/d60ab633-f080-4aa1-8348-6bc0de9ed11f]|
|o.a.c.distributed.test.MigrationCoordinatorTest|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2003/workflows/d3b21034-f3e7-4c10-8e76-1edf5c18ca05]
 
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2003/workflows/dca2887b-47b2-45d0-ba92-c0f7ec07b2c0]|
|o.a.c.distributed.test.JMXGetterCheckTest|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2004/workflows/53d3d4b9-12b6-45a5-915b-30b6a9d9a53b]
 
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2004/workflows/ada12085-c1d9-450f-8261-feeae1b25143]|

> Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
> --
>
> Key: CASSANDRA-17819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17819
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> The test 
> {{{}org.apache.cassandra.distributed.test.SchemaTest.schemaReset{}}}, 
> recently introduced by CASSANDRA-17658, is flaky on 4.1 and trunk:
>  * 4.1: 
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/134/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
>  * trunk: 
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1265/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> {code:java}
> Error Message
> Condition with lambda expression in 
> org.apache.cassandra.distributed.test.SchemaTest that uses 
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> Stacktrace
> org.awaitility.core.ConditionTimeoutException: Condition with lambda 
> expression in org.apache.cassandra.distributed.test.SchemaTest that uses 
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
>   at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
>   at 
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
>   at 
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
>   at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
>   at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
>   at 
> org.apache.cassandra.distributed.test.SchemaTest.schemaReset(SchemaTest.java:115)
>   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)
> Standard Output
> INFO  [main]  2022-08-15 15:02:14,783 Reflections.java:219 - 
> Reflections took 1873 ms to scan 8 urls, producing 1754 keys and 6912 values
> INFO  [main]  2022-08-15 15:02:16,407 Reflections.java:219 - 
> Reflections took 1561 ms to scan 8 urls, producing 1754 keys and 6912 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2022-08-15 15:02:17,554 InternalLoggerFactory.ja
> ...[truncated 1761288 chars]...
> cutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
> INFO  [node2_isolatedExecutor:3] node2 2022-08-15 15:03:52,096 
> MessagingService.java:519 - Waiting for messaging service to quiesce
> {code}



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

-
To unsubscribe, e-mail: 

[jira] [Commented] (CASSANDRA-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-17783:
--

[~drohrer] it looks like your patch is against 4.1, is that correct? I was 
going to help this along with CI run but wanted to confirm that, and if so, a 
patch for trunk will also be needed (I don't think this merges cleanly.)

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Attachments: CASSANDRA-17783.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17783) Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}

[Doug Rohrer (Jira)]

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

Doug Rohrer commented on CASSANDRA-17783:
-

Just wanted to follow up on this and see if someone has some time to take a 
look - [~jlewandowski] you back and have a few spare cycles?

> Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} 
> to {{CassandraRelevantProps}}
> ---
>
> Key: CASSANDRA-17783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17783
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Startup and Shutdown
>Reporter: Doug Rohrer
>Priority: Low
> Attachments: CASSANDRA-17783.patch
>
>
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to 
> {{CassandraRelevantProps}} for two reasons. 
> # Generally speaking, this is where these kinds of things live. 
> # By having them in Schema, you can't actually use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static 
> initializers... and you want to use 
> {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before 
> the static initializer 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-17827) WEBSITE - Case Studies updates, August 2022

[Erick Ramirez (Jira)]

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

Erick Ramirez commented on CASSANDRA-17827:
---

I’ve completed final verification in staging and [published to 
production|https://github.com/apache/cassandra-website#merging-asf-staging-to-asf-site]:
{noformat}
$ git branch
* trunk

$ git fetch origin
$ git checkout asf-site
Branch ‘asf-site’ set up to track remote branch ‘asf-site’ from ‘origin’.
Switched to a new branch ‘asf-site’

$ git branch
* asf-site
  trunk

$ git reset --hard origin/asf-staging
HEAD is now at b6b628fa generate docs for 8cf784cf

$ git push -f origin asf-site
Username for ‘https://github.com’: erickramirezau
Password for ‘https://erickramire...@github.com’: 
Total 0 (delta 0), reused 0 (delta 0) 
To https://github.com/apache/cassandra-website.git
 + d00b9b52...b6b628fa asf-site -> asf-site (forced update)
{noformat}
The updated *Case Studies* pages are now live on the site –
* https://cassandra.apache.org/_/case-studies.html
* https://cassandra.apache.org/_/case-studies/backblaze.html
* https://cassandra.apache.org/_/case-studies/Instana.html

> WEBSITE - Case Studies updates, August 2022
> ---
>
> Key: CASSANDRA-17827
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17827
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0.x
>
> Attachments: c17827-01-case_studies.png, 
> c17827-02-case_studies-instana.png, c17827-03-case_studies-backblaze.png
>
>
> This ticket is to capture the work associated with updates to the Apache 
> Cassandra Website's Case Studies page to address typos and formatting issues.



--
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-site updated (d00b9b52 -> b6b628fa)

[erickramirezau]

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

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


 discard d00b9b52 generate docs for b3ea447a
 add 8cf784cf WEBSITE - Case Studies updates, August 2022
 add b6b628fa generate docs for 8cf784cf

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   (d00b9b52)
\
 N -- N -- N   refs/heads/asf-site (b6b628fa)

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.

No new revisions were added by this update.

Summary of changes:
 content/_/case-studies.html| 122 ++---
 content/_/case-studies/Instana.html|  20 +++-
 content/_/case-studies/backblaze.html  |  13 ++-
 content/search-index.js|   2 +-
 .../source/modules/ROOT/pages/case-studies.adoc| 122 ++---
 .../modules/ROOT/pages/case-studies/Instana.adoc   |   4 +-
 .../modules/ROOT/pages/case-studies/backblaze.adoc |   4 +-
 site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078 
bytes
 8 files changed, 155 insertions(+), 132 deletions(-)


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

[jira] [Commented] (CASSANDRA-17827) WEBSITE - Case Studies updates, August 2022

[Erick Ramirez (Jira)]

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

Erick Ramirez commented on CASSANDRA-17827:
---

The build completed in 14 minutes and the updated pages in *Case Studies* are 
now in staging –
 * [https://cassandra.staged.apache.org/_/case-studies.html]
 * [https://cassandra.staged.apache.org/_/case-studies/backblaze.html]
 * [https://cassandra.staged.apache.org/_/case-studies/Instana.html]

> WEBSITE - Case Studies updates, August 2022
> ---
>
> Key: CASSANDRA-17827
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17827
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0.x
>
> Attachments: c17827-01-case_studies.png, 
> c17827-02-case_studies-instana.png, c17827-03-case_studies-backblaze.png
>
>
> This ticket is to capture the work associated with updates to the Apache 
> Cassandra Website's Case Studies page to address typos and formatting issues.



--
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-17827) WEBSITE - Case Studies updates, August 2022

[Erick Ramirez (Jira)]

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

Erick Ramirez commented on CASSANDRA-17827:
---

The website content is getting built in staging:

||Branch||PR||Commit||Build||
|{{trunk}}|[#163|https://github.com/apache/cassandra-website/pull/163]|[8cf784c|https://github.com/apache/cassandra-website/commit/8cf784cff17958512a079d6dcac51449e932a83e]|[#544|https://ci-cassandra.apache.org/job/cassandra-website/544/]|

> WEBSITE - Case Studies updates, August 2022
> ---
>
> Key: CASSANDRA-17827
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17827
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0.x
>
> Attachments: c17827-01-case_studies.png, 
> c17827-02-case_studies-instana.png, c17827-03-case_studies-backblaze.png
>
>
> This ticket is to capture the work associated with updates to the Apache 
> Cassandra Website's Case Studies page to address typos and formatting issues.



--
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 (ad00ecaa -> b6b628fa)

[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 ad00ecaa generate docs for 8cf784cf
 new b6b628fa generate docs for 8cf784cf

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   (ad00ecaa)
\
 N -- N -- N   refs/heads/asf-staging (b6b628fa)

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 (d00b9b52 -> ad00ecaa)

[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


omit d00b9b52 generate docs for b3ea447a
 add 8cf784cf WEBSITE - Case Studies updates, August 2022
 new ad00ecaa generate docs for 8cf784cf

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   (d00b9b52)
\
 N -- N -- N   refs/heads/asf-staging (ad00ecaa)

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/_/case-studies.html| 122 ++---
 content/_/case-studies/Instana.html|  20 +++-
 content/_/case-studies/backblaze.html  |  13 ++-
 content/search-index.js|   2 +-
 .../source/modules/ROOT/pages/case-studies.adoc| 122 ++---
 .../modules/ROOT/pages/case-studies/Instana.adoc   |   4 +-
 .../modules/ROOT/pages/case-studies/backblaze.adoc |   4 +-
 site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078 
bytes
 8 files changed, 155 insertions(+), 132 deletions(-)


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

[jira] [Updated] (CASSANDRA-17841) Log anticompaction cancellation at INFO level

[Marcus Eriksson (Jira)]

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

Marcus Eriksson updated CASSANDRA-17841:

Reviewers: David Capwell, Marcus Eriksson
   Status: Review In Progress  (was: Patch Available)

> Log anticompaction cancellation at INFO level
> -
>
> Key: CASSANDRA-17841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17841
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> If anticompaction can be interrupted after repair as a normal part of 
> operations we should log at INFO level rather than error.



--
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-17841) Log anticompaction cancellation at INFO level

[Marcus Eriksson (Jira)]

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

Marcus Eriksson updated CASSANDRA-17841:

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

+1

> Log anticompaction cancellation at INFO level
> -
>
> Key: CASSANDRA-17841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17841
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Consistency/Repair
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> If anticompaction can be interrupted after repair as a normal part of 
> operations we should log at INFO level rather than error.



--
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-17827) WEBSITE - Case Studies updates, August 2022

[Erick Ramirez (Jira)]

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

Erick Ramirez updated CASSANDRA-17827:
--
  Fix Version/s: 4.0.x
Source Control Link: 
https://github.com/apache/cassandra-website/commit/8cf784cff17958512a079d6dcac51449e932a83e
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

Committed:

||Branch||PR||Commit||
|{{trunk}}|[#163|https://github.com/apache/cassandra-website/pull/163]|[8cf784c|https://github.com/apache/cassandra-website/commit/8cf784cff17958512a079d6dcac51449e932a83e]|

> WEBSITE - Case Studies updates, August 2022
> ---
>
> Key: CASSANDRA-17827
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17827
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
>  Labels: pull-request-available
> Fix For: 4.0.x
>
> Attachments: c17827-01-case_studies.png, 
> c17827-02-case_studies-instana.png, c17827-03-case_studies-backblaze.png
>
>
> This ticket is to capture the work associated with updates to the Apache 
> Cassandra Website's Case Studies page to address typos and formatting issues.



--
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 trunk updated: WEBSITE - Case Studies updates, August 2022

[erickramirezau]

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

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


The following commit(s) were added to refs/heads/trunk by this push:
 new 8cf784cf WEBSITE - Case Studies updates, August 2022
8cf784cf is described below

commit 8cf784cff17958512a079d6dcac51449e932a83e
Author: Diogenese Topper 
AuthorDate: Wed Aug 17 10:59:03 2022 -0700

WEBSITE - Case Studies updates, August 2022

patch by Diogenese Topper; reviewed by Erick Ramirez for CASSANDRA-17827

Co-authored by: Diogenese Topper 
---
 .../source/modules/ROOT/pages/case-studies.adoc| 122 ++---
 .../modules/ROOT/pages/case-studies/Instana.adoc   |   4 +-
 .../modules/ROOT/pages/case-studies/backblaze.adoc |   4 +-
 3 files changed, 66 insertions(+), 64 deletions(-)

diff --git a/site-content/source/modules/ROOT/pages/case-studies.adoc 
b/site-content/source/modules/ROOT/pages/case-studies.adoc
index ac9d704b..3c7b20d4 100644
--- a/site-content/source/modules/ROOT/pages/case-studies.adoc
+++ b/site-content/source/modules/ROOT/pages/case-studies.adoc
@@ -8,7 +8,7 @@
 
 [openblock,card-header]
 --
-image:companies/ably_full_logo.png[]
+image:companies/ably_full_logo.png[Ably]
 --
 [openblock,card-content]
 --
@@ -31,7 +31,7 @@ 
https://www.ably.io/blog/cassandra-counter-columns-nice-in-theory-hazardous-in-p
 
 [openblock,card-header]
 --
-image:companies/activision_black_text.png[]
+image:companies/activision_black_text.png[Activision]
 --
 [openblock,card-content]
 --
@@ -54,7 +54,7 @@ 
https://www.dataversity.net/case-study-cassandra-meets-call-of-duty/[Read More,w
 
 [openblock,card-header]
 --
-image:companies/adstage_full_white_text.jpg[]
+image:companies/adstage_full_white_text.jpg[AdStage]
 --
 [openblock,card-content]
 --
@@ -77,7 +77,7 @@ https://www.instaclustr.com/resource/adstage/[Read 
More,window=_blank]
 
 [openblock,card-header]
 --
-image:companies/urban_airship.jpg[]
+image:companies/urban_airship.jpg[Airship]
 --
 [openblock,card-content]
 --
@@ -126,7 +126,7 @@ 
https://www.techrepublic.com/article/apples-secret-nosql-sauce-includes-a-hefty-
 
 [openblock,card-header]
 --
-image:companies/backblaze.png[]
+image:companies/backblaze.png[Backblaze]
 --
 [openblock,card-content]
 --
@@ -149,12 +149,12 @@ xref:case-studies/backblaze.adoc[Read More]
 
 [openblock,card-header]
 --
-image:companies/bazaar_full.png[]
+image:companies/bazaar_full.png[Bazaarvoice]
 --
 [openblock,card-content]
 --
 [discrete]
-=== BazaarVoice
+=== Bazaarvoice
 
 EmoDB is an open source RESTful data store built on top of Cassandra that 
stores JSON documents and, most notably, offers a databus that allows 
subscribers to watch for changes to those documents in real time. 
 
@@ -172,7 +172,7 @@ https://www.youtube.com/watch?v=5jKZUnkhB50[Read 
More,window=_blank]
 
 [openblock,card-header]
 --
-image:companies/best_buy.png[]
+image:companies/best_buy.png[Best Buy]
 --
 [openblock,card-content]
 --
@@ -195,7 +195,7 @@ 
https://www.slideshare.net/joelcrabb/cassandra-and-riak-at-bestbuycom[Read More,
 
 [openblock,card-header]
 --
-image:companies/bigmate.png[]
+image:companies/bigmate.png[Bigmate]
 --
 [openblock,card-content]
 --
@@ -218,12 +218,12 @@ 
https://www.iotcentral.io/blog/how-open-source-apache-cassandra-solved-our-iot-s
 
 [openblock,card-header]
 --
-image:companies/blackberry_black_text.jpg[]
+image:companies/blackberry_black_text.jpg[BlackBerry]
 --
 [openblock,card-content]
 --
 [discrete]
-=== Blackberry
+=== BlackBerry
 
 BlackBerry deployed Apache Cassandra as the NoSQL database solution for its 
Internet of Things (IoT) platform. The BlackBerry IoT platform powers the 
BlackBerry Radar IoT solution designed to provide continuous visibility into an 
organization’s transportation fleet.
 
@@ -241,7 +241,7 @@ https://www.instaclustr.com/resource/blackberry/[Read 
More,window=_blank]
 
 [openblock,card-header]
 --
-image:companies/blackrock_logo.png[]
+image:companies/blackrock_logo.png[BlackRock]
 --
 [openblock,card-content]
 --
@@ -266,7 +266,7 @@ https://www.youtube.com/watch?v=322GytEo_fE[Read 
More,window=_blank]
 
 [openblock,card-header]
 --
-image:companies/bloomberg.jpg[]
+image:companies/bloomberg.jpg[Bloomberg Engineering]
 --
 [openblock,card-content]
 --
@@ -289,7 +289,7 @@ 
https://www.techatbloomberg.com/blog/meet-the-team-indices-engineering/[Read Mor
 
 [openblock,card-header]
 --
-image:companies/bundesagentur_fur_arbeit_full.jpg[bundesagentur_fur_arbeit]
+image:companies/bundesagentur_fur_arbeit_full.jpg[Bundesagentur für Arbeit]
 --
 [openblock,card-content]
 --
@@ -312,7 +312,7 @@ 
https://www.datastax.com/enterprise-success/federal-employment-agency[Read More,
 
 

[jira] [Updated] (CASSANDRA-17827) WEBSITE - Case Studies updates, August 2022

[Erick Ramirez (Jira)]

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

Erick Ramirez updated CASSANDRA-17827:
--
Status: Ready to Commit  (was: Review In Progress)

I've staged the PR and verified it is ready to commit.

 !c17827-01-case_studies.png|width=300!
 !c17827-02-case_studies-instana.png|width=300!
 !c17827-03-case_studies-backblaze.png|width=300!

> WEBSITE - Case Studies updates, August 2022
> ---
>
> Key: CASSANDRA-17827
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17827
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
>  Labels: pull-request-available
> Attachments: c17827-01-case_studies.png, 
> c17827-02-case_studies-instana.png, c17827-03-case_studies-backblaze.png
>
>
> This ticket is to capture the work associated with updates to the Apache 
> Cassandra Website's Case Studies page to address typos and formatting issues.



--
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-17827) WEBSITE - Case Studies updates, August 2022

[Erick Ramirez (Jira)]

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

Erick Ramirez updated CASSANDRA-17827:
--
Attachment: c17827-03-case_studies-backblaze.png
c17827-02-case_studies-instana.png
c17827-01-case_studies.png

> WEBSITE - Case Studies updates, August 2022
> ---
>
> Key: CASSANDRA-17827
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17827
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
>  Labels: pull-request-available
> Attachments: c17827-01-case_studies.png, 
> c17827-02-case_studies-instana.png, c17827-03-case_studies-backblaze.png
>
>
> This ticket is to capture the work associated with updates to the Apache 
> Cassandra Website's Case Studies page to address typos and formatting issues.



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