[jira] [Commented] (CASSANDRA-19558) Standalone jenkinsfile first round bug fixes

2024-04-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-19558:


A number of issues have been identified.
– need to capture the generateTestReports logs, 
– fix ant version in centos7-build.docker
– remove docker login (if credentials exist then docker is logged in)
– prefetch docker images from jfrog (to reduce dockerhub pull rate limits)
– use scripts from cassandra-builds to clean and report on agents
– stream xz where possible (not an issue, just perf improvement)

The docker pull rate limit was the most serious, blocking.

patches…

1.
this is part of CASSANDRA-18594 (most of it is already running (manually 
deployed) to ci-cassandra)
[https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:cassandra-builds:mck/18594]
( [https://github.com/apache/cassandra-builds/commit/eb3eb5e] )

2.
and for CASSANDRA-19558
[https://github.com/thelastpickle/cassandra-builds/compare/mck/18594...thelastpickle:cassandra-builds:mck/19558]
( 
[https://github.com/thelastpickle/cassandra-builds/commit/9f8ae9dcacd0d744992cc4eaf50f29a8836ffdbd]
 )

3.

and then (also for CASSANDRA-19558 ) but comes last (i can test it manually 
once (2) is committed)
[https://github.com/apache/cassandra/commit/b3e1e40658e99c37f2a142e247ca4305fcc52eb0]
(this is on top of the previous commit (that already passed review) in 
[https://github.com/apache/cassandra/compare/apache:cassandra:cassandra-5.0...thelastpickle:cassandra:mck/mck/jenkinsfile-persist-parameters-5.0-test]
 )

> Standalone jenkinsfile first round bug fixes
> 
>
> Key: CASSANDRA-19558
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19558
> Project: Cassandra
>  Issue Type: Bug
>  Components: CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments:  CASSANDRA-19558_50_#5_ci_summary.html,  
> CASSANDRA-19558_50_#5_results_details.tar.xz, 
> CASSANDRA-19558-5.0_#13_ci_summary.html, 
> CASSANDRA-19558-5.0_#13_results_details.tar.xz, 
> CASSANDRA-19558-5.0_#16_ci_summary.html, 
> CASSANDRA-19558-5.0_#16_results_details.tar.xz, 
> CASSANDRA-19558_#8_ci_summary.html, CASSANDRA-19558_#8_results_details.tar.xz
>
>
> A few follow up improvements and bug fixes for the standalone jenkinsfile.
> - add at top a list of test failures in ci_summary.html
> - docker scripts always try to login (as base images need to be pulled too)
> - move simulator-dtests to large containers (they need 8g just heap)
> - in ubuntu2004_test.docker make sure /home/cassandra exists and has correct 
> perms (from marcuse)
> - persist the jenkinsfile parameters from run to run (important for the 
> post-commit jobs to keep their non-default branch and profile values) (was 
> CASSANDRA-19536)
> - increase jvm-dtest splits from 8 to 12
> - when on ci-cassandra, replace use of copyArtifacts in Jenkinsfile 
> generateTestReports() with manual wget of test files, allowing the summary 
> phase to be run on any agent (copyArtifact would take >4hrs otherwise) (was 
> INFRA-25694)
> - copy ci_summary.html and results_details.tar.xz to nightlies



--
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-19578) Concurrent equivalent schema updates lead to unresolved disagreement

2024-04-20 Thread Brandon Williams (Jira)


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

Brandon Williams edited comment on CASSANDRA-19578 at 4/20/24 8:00 PM:
---

We'll also need to multiplex SchemaTest for flakiness, which I ran 
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1592/workflows/a84707b9-9ff8-4d49-af26-015a5e99d2b4/jobs/85318/tests]
 and is failing, which I verified, and learned that it is only failing when the 
suite is run, but testTransKsMigration passes in isolation.


was (Author: brandon.williams):
We'll also need to multiplex SchemaTest for flakiness, which I ram 
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1592/workflows/a84707b9-9ff8-4d49-af26-015a5e99d2b4/jobs/85318/tests]
 and is failing, which I verified, and learned that it is only failing when the 
suite is run, but testTransKsMigration passes in isolation.

> Concurrent equivalent schema updates lead to unresolved disagreement
> 
>
> Key: CASSANDRA-19578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19578
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Chris Lohfink
>Priority: Normal
> Fix For: 4.1.5, 5.0-beta2
>
>
> As part of CASSANDRA-17819 a check for empty schema changes was added to the 
> updateSchema. This only looks at the _logical_ schema difference of the 
> schemas, but the changes made to the system_schema keyspace are the ones that 
> actually are involved in the digest.
> If two nodes issue the same CREATE statement the difference from the 
> keyspace.diff would be empty but the timestamps on the mutations would be 
> different, leading to a pseudo schema disagreement which will never resolve 
> until resetlocalschema or nodes being bounced.
> Only impacts 4.1
> test and fix : 
> https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411



--
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-19578) Concurrent equivalent schema updates lead to unresolved disagreement

2024-04-20 Thread Brandon Williams (Jira)


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

Brandon Williams commented on CASSANDRA-19578:
--

We'll also need to multiplex SchemaTest for flakiness, which I ram 
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1592/workflows/a84707b9-9ff8-4d49-af26-015a5e99d2b4/jobs/85318/tests]
 and is failing, which I verified, and learned that it is only failing when the 
suite is run, but testTransKsMigration passes in isolation.

> Concurrent equivalent schema updates lead to unresolved disagreement
> 
>
> Key: CASSANDRA-19578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19578
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Chris Lohfink
>Priority: Normal
> Fix For: 4.1.5, 5.0-beta2
>
>
> As part of CASSANDRA-17819 a check for empty schema changes was added to the 
> updateSchema. This only looks at the _logical_ schema difference of the 
> schemas, but the changes made to the system_schema keyspace are the ones that 
> actually are involved in the digest.
> If two nodes issue the same CREATE statement the difference from the 
> keyspace.diff would be empty but the timestamps on the mutations would be 
> different, leading to a pseudo schema disagreement which will never resolve 
> until resetlocalschema or nodes being bounced.
> Only impacts 4.1
> test and fix : 
> https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411



--
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-19578) Concurrent equivalent schema updates lead to unresolved disagreement

2024-04-20 Thread Brandon Williams (Jira)


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

Brandon Williams commented on CASSANDRA-19578:
--

I've started a run: 
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-before-5/2678/

> Concurrent equivalent schema updates lead to unresolved disagreement
> 
>
> Key: CASSANDRA-19578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19578
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Chris Lohfink
>Priority: Normal
> Fix For: 4.1.5, 5.0-beta2
>
>
> As part of CASSANDRA-17819 a check for empty schema changes was added to the 
> updateSchema. This only looks at the _logical_ schema difference of the 
> schemas, but the changes made to the system_schema keyspace are the ones that 
> actually are involved in the digest.
> If two nodes issue the same CREATE statement the difference from the 
> keyspace.diff would be empty but the timestamps on the mutations would be 
> different, leading to a pseudo schema disagreement which will never resolve 
> until resetlocalschema or nodes being bounced.
> Only impacts 4.1
> test and fix : 
> https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411



--
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-19578) Concurrent equivalent schema updates lead to unresolved disagreement

2024-04-20 Thread Jordan West (Jira)


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

Jordan West commented on CASSANDRA-19578:
-

+1. We should definitely get this into a 4.1.5 quickly as its a pretty 
significant operational bug. We should get a full test run on this branch going 
so we can merge. 

> Concurrent equivalent schema updates lead to unresolved disagreement
> 
>
> Key: CASSANDRA-19578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19578
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Chris Lohfink
>Priority: Normal
> Fix For: 4.1.5, 5.0-beta2
>
>
> As part of CASSANDRA-17819 a check for empty schema changes was added to the 
> updateSchema. This only looks at the _logical_ schema difference of the 
> schemas, but the changes made to the system_schema keyspace are the ones that 
> actually are involved in the digest.
> If two nodes issue the same CREATE statement the difference from the 
> keyspace.diff would be empty but the timestamps on the mutations would be 
> different, leading to a pseudo schema disagreement which will never resolve 
> until resetlocalschema or nodes being bounced.
> Only impacts 4.1
> test and fix : 
> https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411



--
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-19578) Concurrent equivalent schema updates lead to unresolved disagreement

2024-04-20 Thread Jordan West (Jira)


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

Jordan West updated CASSANDRA-19578:

Fix Version/s: 4.1.5
   5.0-beta2

> Concurrent equivalent schema updates lead to unresolved disagreement
> 
>
> Key: CASSANDRA-19578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19578
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Chris Lohfink
>Priority: Normal
> Fix For: 4.1.5, 5.0-beta2
>
>
> As part of CASSANDRA-17819 a check for empty schema changes was added to the 
> updateSchema. This only looks at the _logical_ schema difference of the 
> schemas, but the changes made to the system_schema keyspace are the ones that 
> actually are involved in the digest.
> If two nodes issue the same CREATE statement the difference from the 
> keyspace.diff would be empty but the timestamps on the mutations would be 
> different, leading to a pseudo schema disagreement which will never resolve 
> until resetlocalschema or nodes being bounced.
> Only impacts 4.1
> test and fix : 
> https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411



--
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-19578) Concurrent equivalent schema updates lead to unresolved disagreement

2024-04-20 Thread Jordan West (Jira)


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

Jordan West updated CASSANDRA-19578:

 Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable 
Corruption / Loss(12986)
   Complexity: Normal
Discovered By: User Report
 Severity: Critical
   Status: Open  (was: Triage Needed)

> Concurrent equivalent schema updates lead to unresolved disagreement
> 
>
> Key: CASSANDRA-19578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19578
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Chris Lohfink
>Priority: Normal
>
> As part of CASSANDRA-17819 a check for empty schema changes was added to the 
> updateSchema. This only looks at the _logical_ schema difference of the 
> schemas, but the changes made to the system_schema keyspace are the ones that 
> actually are involved in the digest.
> If two nodes issue the same CREATE statement the difference from the 
> keyspace.diff would be empty but the timestamps on the mutations would be 
> different, leading to a pseudo schema disagreement which will never resolve 
> until resetlocalschema or nodes being bounced.
> Only impacts 4.1
> test and fix : 
> https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411



--
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-19565) SIGSEGV on Cassandra v4.1.4

2024-04-20 Thread Brandon Williams (Jira)


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

Brandon Williams commented on CASSANDRA-19565:
--

[Here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-before-5/2677/]
 is CI for 4.1

> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Thomas De Keulenaer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: cassandra_57_debian_jdk11_amd64_attempt1.log.xz, 
> cassandra_57_redhat_jdk11_amd64_attempt1.log.xz, hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start 
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been 
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: #  SIGSEGV (0xb) at 
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to 
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?



--
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-19567) Minimize the heap consumption when registering metrics

2024-04-20 Thread Maxim Muzafarov (Jira)


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

Maxim Muzafarov commented on CASSANDRA-19567:
-

!summary.png|width=900!

> Minimize the heap consumption when registering metrics
> --
>
> Key: CASSANDRA-19567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: summary.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The problem is only reproducible on the x86 machine, the problem is not 
> reproducible on the arm64. A quick analysis showed a lot of MetricName 
> objects stored in the heap, although the real cause could be related to 
> something else, the MetricName object requires extra attention.
> To reproduce run the command run locally:
> {code}
> ant test-jvm-dtest-some 
> -Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
> {code}
> The error:
> {code:java}
> [junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java 
> heap space
> [junit-timeout]     at 
> java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
> [junit-timeout]     at 
> java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
> [junit-timeout]     at 
> org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
> [junit-timeout]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
> [junit-timeout]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
> [junit-timeout]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
> [junit-timeout]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
> [junit-timeout] Testsuite: 
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> [junit-timeout] Testsuite: 
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
>  Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout] 
> [junit-timeout] Testcase: 
> org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
>     Caused an ERROR
> [junit-timeout] Forked Java VM exited abnormally. Please note the time in the 
> report does not reflect the time until the VM exit.
> [junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited 
> abnormally. Please note the time in the report does not reflect the time 
> until the VM exit.
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]     at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]     at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Test org.apache.cassandra.distributed.test.ReadRepairTest 
> FAILED (crashed)BUILD FAILED
>  {code}



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

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



[jira] [Comment Edited] (CASSANDRA-19567) Minimize the heap consumption when registering metrics

2024-04-20 Thread Maxim Muzafarov (Jira)


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

Maxim Muzafarov edited comment on CASSANDRA-19567 at 4/20/24 4:33 PM:
--

!summary.png|width=800!


was (Author: mmuzaf):
!summary.png|width=900!

> Minimize the heap consumption when registering metrics
> --
>
> Key: CASSANDRA-19567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: summary.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The problem is only reproducible on the x86 machine, the problem is not 
> reproducible on the arm64. A quick analysis showed a lot of MetricName 
> objects stored in the heap, although the real cause could be related to 
> something else, the MetricName object requires extra attention.
> To reproduce run the command run locally:
> {code}
> ant test-jvm-dtest-some 
> -Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
> {code}
> The error:
> {code:java}
> [junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java 
> heap space
> [junit-timeout]     at 
> java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
> [junit-timeout]     at 
> java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
> [junit-timeout]     at 
> org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
> [junit-timeout]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
> [junit-timeout]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
> [junit-timeout]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
> [junit-timeout]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
> [junit-timeout] Testsuite: 
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> [junit-timeout] Testsuite: 
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
>  Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout] 
> [junit-timeout] Testcase: 
> org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
>     Caused an ERROR
> [junit-timeout] Forked Java VM exited abnormally. Please note the time in the 
> report does not reflect the time until the VM exit.
> [junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited 
> abnormally. Please note the time in the report does not reflect the time 
> until the VM exit.
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]     at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]     at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Test org.apache.cassandra.distributed.test.ReadRepairTest 
> FAILED (crashed)BUILD FAILED
>  {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-19567) Minimize the heap consumption when registering metrics

2024-04-20 Thread Maxim Muzafarov (Jira)


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

Maxim Muzafarov updated CASSANDRA-19567:

Attachment: summary.png

> Minimize the heap consumption when registering metrics
> --
>
> Key: CASSANDRA-19567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: summary.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The problem is only reproducible on the x86 machine, the problem is not 
> reproducible on the arm64. A quick analysis showed a lot of MetricName 
> objects stored in the heap, although the real cause could be related to 
> something else, the MetricName object requires extra attention.
> To reproduce run the command run locally:
> {code}
> ant test-jvm-dtest-some 
> -Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
> {code}
> The error:
> {code:java}
> [junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java 
> heap space
> [junit-timeout]     at 
> java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
> [junit-timeout]     at 
> java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
> [junit-timeout]     at 
> org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
> [junit-timeout]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
> [junit-timeout]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
> [junit-timeout]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
> [junit-timeout]     at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
> [junit-timeout] Testsuite: 
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> [junit-timeout] Testsuite: 
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
>  Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout] 
> [junit-timeout] Testcase: 
> org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
>     Caused an ERROR
> [junit-timeout] Forked Java VM exited abnormally. Please note the time in the 
> report does not reflect the time until the VM exit.
> [junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited 
> abnormally. Please note the time in the report does not reflect the time 
> until the VM exit.
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]     at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]     at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]     at 
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout]     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] 
> [junit-timeout] 
> [junit-timeout] Test org.apache.cassandra.distributed.test.ReadRepairTest 
> FAILED (crashed)BUILD FAILED
>  {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: Ninja remove unused import

2024-04-20 Thread brandonwilliams
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/trunk by this push:
 new e4f030170f Ninja remove unused import
e4f030170f is described below

commit e4f030170fc5afbba1c88fc87199fc78ee500e06
Author: Brandon Williams 
AuthorDate: Sat Apr 20 11:17:12 2024 -0500

Ninja remove unused import
---
 .../org/apache/cassandra/tcm/ownership/UniformRangePlacementTest.java| 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/test/unit/org/apache/cassandra/tcm/ownership/UniformRangePlacementTest.java 
b/test/unit/org/apache/cassandra/tcm/ownership/UniformRangePlacementTest.java
index b1846ca7fd..f046be7955 100644
--- 
a/test/unit/org/apache/cassandra/tcm/ownership/UniformRangePlacementTest.java
+++ 
b/test/unit/org/apache/cassandra/tcm/ownership/UniformRangePlacementTest.java
@@ -36,7 +36,6 @@ import org.apache.cassandra.schema.ReplicationParams;
 import org.apache.cassandra.tcm.Epoch;
 
 import static org.apache.cassandra.tcm.membership.MembershipUtils.endpoint;
-import static org.apache.cassandra.tcm.ownership.OwnershipUtils.bytesToken;
 import static org.apache.cassandra.tcm.ownership.OwnershipUtils.token;
 import static org.junit.Assert.assertEquals;
 import static org.junit.Assert.assertTrue;


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



[jira] [Updated] (CASSANDRA-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset

2024-04-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever updated CASSANDRA-17819:
---
Fix Version/s: 4.0

> 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.0, 4.0.7, 4.1-beta1, 5.0-alpha1, 5.0
>
>  Time Spent: 6h 40m
>  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] [Commented] (CASSANDRA-18931) ci job to build and push new in-tree docker images when dockerfile changes

2024-04-20 Thread Michael Semb Wever (Jira)


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

Michael Semb Wever commented on CASSANDRA-18931:


if we want to also push to our jfrog repository, it becomes…
{code}
cd .build

image_name="apache/cassandra-almalinux-build:$(md5sum 
docker/almalinux-build.docker | cut -d' ' -f1)"

docker buildx build --platform linux/amd64,linux/arm64 -t "${image_name}" -t 
"apache.jfrog.io/cassan-docker/${image_name}" -f docker/almalinux-build.docker 
--push .

image_name="apache/cassandra-bullseye-build:$(md5sum 
docker/bullseye-build.docker | cut -d' ' -f1)"

docker buildx build --platform linux/amd64,linux/arm64 -t "${image_name}" -t 
"apache.jfrog.io/cassan-docker/${image_name}" -f docker/bullseye-build.docker 
--push .

image_name="apache/cassandra-centos7-build:$(md5sum docker/centos7-build.docker 
| cut -d' ' -f1)"

docker buildx build --platform linux/amd64,linux/arm64 -t "${image_name}" -t 
"apache.jfrog.io/cassan-docker/${image_name}" -f docker/centos7-build.docker 
--push .

image_name="apache/cassandra-ubuntu2004_test:$(md5sum 
docker/ubuntu2004_test.docker | cut -d' ' -f1)"

docker buildx build --platform linux/amd64,linux/arm64 -t "${image_name}" -t 
"apache.jfrog.io/cassan-docker/${image_name}" -f docker/ubuntu2004_test.docker 
--push .
{code}

> ci job to build and push new in-tree docker images when dockerfile changes
> --
>
> Key: CASSANDRA-18931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18931
> Project: Cassandra
>  Issue Type: Task
>  Components: CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> The dockerfiles under .build/docker are now and are deployed by file md5sum.
> (There is no "latest").
> in-tree scripts will have to build these images on-the-fly if they are not 
> available to pull from dockerhub.
> Automatically building and pushing them to dockerhub whenever they change 
> will save a lot of resources and time in tests/CI.



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