[jira] [Updated] (CASSANDRA-19092) Test Failure: cql_tracing_test.TestCqlTracing.test_tracing_simple
[
https://issues.apache.org/jira/browse/CASSANDRA-19092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19092:
Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear
Impact(13164)
Complexity: Normal
Component/s: Test/dtest/python
Discovered By: DTest
Severity: Normal
Assignee: Sam Tunnicliffe
Status: Open (was: Triage Needed)
> Test Failure: cql_tracing_test.TestCqlTracing.test_tracing_simple
> -
>
> Key: CASSANDRA-19092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19092
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Sam Tunnicliffe
>Priority: Normal
>
> Seen in cqlsh_dtests in CASSANDRA-19034
> https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/257/workflows/ddcb5f4e-e2c5-430b-b922-f7064a244971/jobs/20648/tests
> {noformat}failed on teardown with "Failed: Unexpected error found in node
> logs (see stdout for full details). Errors: [[node3] 'ERROR [main] 2023-11-24
> 19:02:04,201 FailureDetector.java:309 - Unknown endpoint: /127.0.0.1:7000
> java.lang.IllegalArgumentException: Unknown endpoint: /127.0.0.1:7000
> at
> org.apache.cassandra.gms.FailureDetector.isAlive(FailureDetector.java:309)
> at
> org.apache.cassandra.tcm.RemoteProcessor$CandidateIterator.computeNext(RemoteProcessor.java:326)
> at
> org.apache.cassandra.tcm.RemoteProcessor$CandidateIterator.computeNext(RemoteProcessor.java:256)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.tcm.RemoteProcessor$1Request.retry(RemoteProcessor.java:187)
> at
> org.apache.cassandra.tcm.RemoteProcessor.sendWithCallbackAsync(RemoteProcessor.java:223)
> at
> org.apache.cassandra.tcm.RemoteProcessor.sendWithCallback(RemoteProcessor.java:170)
> at
> org.apache.cassandra.tcm.RemoteProcessor.commit(RemoteProcessor.java:76)
> at
> org.apache.cassandra.tcm.ClusterMetadataService$SwitchableProcessor.commit(ClusterMetadataService.java:837)
> at org.apache.cassandra.tcm.Processor.commit(Processor.java:45)
> at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:502)
> at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:467)
> at
> org.apache.cassandra.tcm.transformations.Register.register(Register.java:112)
> at
> org.apache.cassandra.tcm.transformations.Register.register(Register.java:95)
> at
> org.apache.cassandra.tcm.transformations.Register.register(Register.java:132)
> at
> org.apache.cassandra.tcm.transformations.Register.maybeRegister(Register.java:89)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:807)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:367)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:728)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:879)']"
> {noformat}
--
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-19097) Test Failure: bootstrap_test.TestBootstrap.*
[
https://issues.apache.org/jira/browse/CASSANDRA-19097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789997#comment-17789997
]
Jacek Lewandowski commented on CASSANDRA-19097:
---
Let me add to that: {{test_shutdown_wiped_node_cannot_join}}
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1119/workflows/932a44e3-c25e-4c5e-b677-66579380faeb/jobs/50782/tests
> Test Failure: bootstrap_test.TestBootstrap.*
>
>
> Key: CASSANDRA-19097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19097
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0-rc
>
>
> test_killed_wiped_node_cannot_join
> test_read_from_bootstrapped_node
> test_shutdown_wiped_node_cannot_join
> Seen in dtests_offheap in CASSANDRA-19034
> https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/258/workflows/cea7d697-ca33-40bb-8914-fb9fc662820a/jobs/21162/parallel-runs/38
> {noformat}
> self =
> def test_killed_wiped_node_cannot_join(self):
> > self._wiped_node_cannot_join_test(gently=False)
> bootstrap_test.py:608:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = , gently = False
> def _wiped_node_cannot_join_test(self, gently):
> """
> @jira_ticket CASSANDRA-9765
> Test that if we stop a node and wipe its data then the node cannot
> join
> when it is not a seed. Test both a nice shutdown or a forced
> shutdown, via
> the gently parameter.
> """
> cluster = self.cluster
>
> cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
> 'True')
> cluster.populate(3)
> cluster.start()
>
> stress_table = 'keyspace1.standard1'
>
> # write some data
> node1 = cluster.nodelist()[0]
> node1.stress(['write', 'n=10K', 'no-warmup', '-rate', 'threads=8'])
>
> session = self.patient_cql_connection(node1)
> original_rows = list(session.execute("SELECT * FROM
> {}".format(stress_table,)))
>
> # Add a new node, bootstrap=True ensures that it is not a seed
> node4 = new_node(cluster, bootstrap=True)
> node4.start(wait_for_binary_proto=True)
>
> session = self.patient_cql_connection(node4)
> > assert original_rows == list(session.execute("SELECT * FROM
> > {}".format(stress_table,)))
> E assert [Row(key=b'PP...e9\xbb'), ...] == [Row(key=b'PP...e9\xbb'),
> ...]
> E At index 587 diff: Row(key=b'OP2656L630',
> C0=b"E02\xd2\x8clBv\tr\n\xe3\x01\xdd\xf2\x8a\x91\x7f-\x9dm'\xa5\xe7PH\xef\xc1xlO\xab+d",
>
> C1=b"\xb2\xc0j\xff\xcb'\xe3\xcc\x0b\x93?\x18@\xc4\xc7tV\xb7q\xeeF\x82\xa4\xd3\xdcFl\xd9\x87
> \x9a\xde\xdc\xa3",
> C2=b'\xed\xf8\x8d%\xa4\xa6LPs;\x98f\xdb\xca\x913\xba{M\x8d6XW\x01\xea-\xb5
> C3=b'\x9ec\xcf\xc7\xec\xa5\x85Z]\xa6\x19\xeb\xc4W\x1d%lyZj\xb9\x94I\x90\xebZ\xdba\xdd\xdc\x9e\x82\x95\x1c',
>
> C4=b'\xab\x9e\x13\x8b\xc6\x15D\x9b\xccl\xdcX\xb23\xd0\x8b\xa3\xba7\xc1c\xf7F\x1d\xf8e\xbd\x89\xcb\xd8\xd1)f\xdd')
> != Row(key=b'4LN78NONP0',
> C0=b"\xdf\x90\xb3/u\xc9/C\xcdOYG3\x070@#\xc3k\xaa$M'\x19\xfb\xab\xc0\x10]\xa6\xac\x1d\x81\xad",
>
> C1=b'\x8a\xb7j\x95\xf9\xbd?&\x11\xaaH\xcd\x87\xaa\xd2\x85\x08X\xea9\x94\xae8U\x92\xad\xb0\x1b9\xff\x87Z\xe81',
>
> C2=b'6\x1d\xa1-\xf77\xc7\xde+`\xb7\x89\xaa\xcd\xb5_\xe5\xb3\x04\xc7\xb1\x95e\x81s\t1\x8b\x16sc\x0eMm',
>
> C3=b'\xfbi\x08;\xc9\x94\x15}r\xfe\x1b\xae5\xf6v\x83\xae\xff\x82\x9b`J\xc2D\xa6k+\xf3\xd3\xff{C\xd0;',
>
> C4=b'\x8f\x87\x18\x0f\xfa\xadK"\x9e\x96\x87:tiu\xa5\x99\xe1_Ax\xa3\x12\xb4Z\xc9v\xa5\xad\xb8{\xc0\xa3\x93')
> E Left contains 2830 more items, first extra item:
> Row(key=b'5N7N172K30',
> C0=b'Y\x81\xa6\x02\x89\xa0hyp\x00O\xe9kFp$\x86u\xea\n\x7fK\x99\xe1\xf6G\xf77\xf7\xd7\xe1\xc7L\x...0\x87a\x03\xee',
>
> C4=b'\xe8\xd8\x17\xf3\x14\x16Q\x9d\\jb\xde=\x81\xc1B\x9c;T\xb1\xa2O-\x87zF=\x04`\x04\xbd\xc9\x95\xad')
> E Full diff:
> E [
> …
> {noformat}
--
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-19086) Problem with running repeated tests on CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-19086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19086:
--
Description:
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1114/workflows/a1d02a59-31ee-48e2-9426-a4eca52ed3ff/jobs/50107
{noformat}
BUILD SUCCESSFUL
Total time: 5 seconds
+ dest=/tmp/results/repeated_utests/stdout/passes/01
+ mkdir -p /tmp/results/repeated_utests/stdout/passes/01
+ mv stdout.txt
/tmp/results/repeated_utests/stdout/passes/01/org.apache.cassandra.db.commitlog.CommitLogSegmentBackpressureTest.txt
+ source=build/test/output/
+ dest=/tmp/results/repeated_utests/output/passes/01
+ mkdir -p /tmp/results/repeated_utests/output/passes/01
+ [[ -d build/test/output/ ]]
++ ls build/test/output/
+ [[ -n
TEST-org.apache.cassandra.db.commitlog.CommitLogSegmentBackpressureTest.xml ]]
+ mv
build/test/output//TEST-org.apache.cassandra.db.commitlog.CommitLogSegmentBackpressureTest.xml
/tmp/results/repeated_utests/output/passes/01/
+ source=build/test/logs/
+ dest=/tmp/results/repeated_utests/logs/passes/01
+ mkdir -p /tmp/results/repeated_utests/logs/passes/01
+ [[ -d build/test/logs/ ]]
++ ls build/test/logs/
+ [[ -n _jdk11 ]]
+ mv build/test/logs//_jdk11 /tmp/results/repeated_utests/logs/passes/01/
mv: cannot move 'build/test/logs//_jdk11' to
'/tmp/results/repeated_utests/logs/passes/01/_jdk11': File exists
Exited with code exit status 1
{noformat}
was:https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1114/workflows/a1d02a59-31ee-48e2-9426-a4eca52ed3ff/jobs/50107
> Problem with running repeated tests on CircleCI
> ---
>
> Key: CASSANDRA-19086
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19086
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1114/workflows/a1d02a59-31ee-48e2-9426-a4eca52ed3ff/jobs/50107
> {noformat}
> BUILD SUCCESSFUL
> Total time: 5 seconds
> + dest=/tmp/results/repeated_utests/stdout/passes/01
> + mkdir -p /tmp/results/repeated_utests/stdout/passes/01
> + mv stdout.txt
> /tmp/results/repeated_utests/stdout/passes/01/org.apache.cassandra.db.commitlog.CommitLogSegmentBackpressureTest.txt
> + source=build/test/output/
> + dest=/tmp/results/repeated_utests/output/passes/01
> + mkdir -p /tmp/results/repeated_utests/output/passes/01
> + [[ -d build/test/output/ ]]
> ++ ls build/test/output/
> + [[ -n
> TEST-org.apache.cassandra.db.commitlog.CommitLogSegmentBackpressureTest.xml ]]
> + mv
> build/test/output//TEST-org.apache.cassandra.db.commitlog.CommitLogSegmentBackpressureTest.xml
> /tmp/results/repeated_utests/output/passes/01/
> + source=build/test/logs/
> + dest=/tmp/results/repeated_utests/logs/passes/01
> + mkdir -p /tmp/results/repeated_utests/logs/passes/01
> + [[ -d build/test/logs/ ]]
> ++ ls build/test/logs/
> + [[ -n _jdk11 ]]
> + mv build/test/logs//_jdk11 /tmp/results/repeated_utests/logs/passes/01/
> mv: cannot move 'build/test/logs//_jdk11' to
> '/tmp/results/repeated_utests/logs/passes/01/_jdk11': File exists
> Exited with code exit status 1
> {noformat}
--
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-19099) Test Failure: 5.0 dtest-upgrade failing bc nodetool initiatlizecms
[ https://issues.apache.org/jira/browse/CASSANDRA-19099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19099: --- Summary: Test Failure: 5.0 dtest-upgrade failing bc nodetool initiatlizecms (was: Test Failure: 5.0 dtest-upgrade failing bc nodetool initiatlisecms) > Test Failure: 5.0 dtest-upgrade failing bc nodetool initiatlizecms > -- > > Key: CASSANDRA-19099 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19099 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > > This commit > [cassandra-dtest@c0082c9|https://github.com/apache/cassandra-dtest/commit/c0082c9d0b2ded7da93942dfbfc7c87c896d53e0] > is not entirely working. Python upgrade dtests are still failing, see this > run on clean cassandra-5.0 > https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/261/workflows/6a15688e-b110-4ede-977c-550b85306867/jobs/21417/tests > > EDIT: also now visible on post-commit ci: > https://ci-cassandra.apache.org/job/Cassandra-5.0/119/ -- 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-19100) commitlog_test.py::TestCommitLog::test_stop_failure_policy failed
Jacek Lewandowski created CASSANDRA-19100: - Summary: commitlog_test.py::TestCommitLog::test_stop_failure_policy failed Key: CASSANDRA-19100 URL: https://issues.apache.org/jira/browse/CASSANDRA-19100 Project: Cassandra Issue Type: Bug Components: Test/dtest/python Reporter: Jacek Lewandowski https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1121/workflows/fce907b1-0526-4d4d-beb5-b6620737a5f3/jobs/50905/tests -- 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-19032) StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey
[ https://issues.apache.org/jira/browse/CASSANDRA-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson reassigned CASSANDRA-19032: Assignee: Mike Adamson > StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey > - > > Key: CASSANDRA-19032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19032 > Project: Cassandra > Issue Type: Bug > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0-rc > > > The StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding has been > showing flakiness in test runs and need investigating and fixing. Looking at > the failure is seems that there is an edge condition where the index will > fail to complete its build if a table truncate is triggered at the right > moment. > We need to try and provoke this edge condition using injection and then see > what can be done to fix the build failure. -- 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-19100) commitlog_test.py::TestCommitLog::test_stop_failure_policy failed
[
https://issues.apache.org/jira/browse/CASSANDRA-19100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19100:
--
Description:
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1121/workflows/fce907b1-0526-4d4d-beb5-b6620737a5f3/jobs/50905/tests
{noformat}
AssertionError: Cannot find the commitlog failure message in logs
assert []
self =
def test_stop_failure_policy(self):
"""
Test the stop commitlog failure policy (default one)
"""
self.prepare()
self._provoke_commitlog_failure()
failure = self.node1.grep_log("Failed .+ commit log segments. Commit
disk failure policy is stop; terminating thread")
logger.debug(failure)
> assert failure, "Cannot find the commitlog failure message in logs"
E AssertionError: Cannot find the commitlog failure message in logs
E assert []
commitlog_test.py:325: AssertionError
{noformat}
was:
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1121/workflows/fce907b1-0526-4d4d-beb5-b6620737a5f3/jobs/50905/tests
> commitlog_test.py::TestCommitLog::test_stop_failure_policy failed
> -
>
> Key: CASSANDRA-19100
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19100
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1121/workflows/fce907b1-0526-4d4d-beb5-b6620737a5f3/jobs/50905/tests
> {noformat}
> AssertionError: Cannot find the commitlog failure message in logs
> assert []
> self =
> def test_stop_failure_policy(self):
> """
> Test the stop commitlog failure policy (default one)
> """
> self.prepare()
>
> self._provoke_commitlog_failure()
> failure = self.node1.grep_log("Failed .+ commit log segments. Commit
> disk failure policy is stop; terminating thread")
> logger.debug(failure)
> > assert failure, "Cannot find the commitlog failure message in logs"
> E AssertionError: Cannot find the commitlog failure message in logs
> E assert []
> commitlog_test.py:325: AssertionError
> {noformat}
--
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-19032) StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey
[ https://issues.apache.org/jira/browse/CASSANDRA-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-19032: - Bug Category: Parent values: Availability(12983) Complexity: Normal Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey > - > > Key: CASSANDRA-19032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19032 > Project: Cassandra > Issue Type: Bug > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0-rc > > > The StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding has been > showing flakiness in test runs and need investigating and fixing. Looking at > the failure is seems that there is an edge condition where the index will > fail to complete its build if a table truncate is triggered at the right > moment. > We need to try and provoke this edge condition using injection and then see > what can be done to fix the build failure. -- 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-19100) commitlog_test.py::TestCommitLog::test_stop_failure_policy failed
[
https://issues.apache.org/jira/browse/CASSANDRA-19100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19100:
--
Fix Version/s: 5.x
> commitlog_test.py::TestCommitLog::test_stop_failure_policy failed
> -
>
> Key: CASSANDRA-19100
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19100
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1121/workflows/fce907b1-0526-4d4d-beb5-b6620737a5f3/jobs/50905/tests
> {noformat}
> AssertionError: Cannot find the commitlog failure message in logs
> assert []
> self =
> def test_stop_failure_policy(self):
> """
> Test the stop commitlog failure policy (default one)
> """
> self.prepare()
>
> self._provoke_commitlog_failure()
> failure = self.node1.grep_log("Failed .+ commit log segments. Commit
> disk failure policy is stop; terminating thread")
> logger.debug(failure)
> > assert failure, "Cannot find the commitlog failure message in logs"
> E AssertionError: Cannot find the commitlog failure message in logs
> E assert []
> commitlog_test.py:325: AssertionError
> {noformat}
--
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-19100) commitlog_test.py::TestCommitLog::test_stop_failure_policy failed
[
https://issues.apache.org/jira/browse/CASSANDRA-19100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19100:
--
Fix Version/s: 5.0.x
> commitlog_test.py::TestCommitLog::test_stop_failure_policy failed
> -
>
> Key: CASSANDRA-19100
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19100
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1121/workflows/fce907b1-0526-4d4d-beb5-b6620737a5f3/jobs/50905/tests
> {noformat}
> AssertionError: Cannot find the commitlog failure message in logs
> assert []
> self =
> def test_stop_failure_policy(self):
> """
> Test the stop commitlog failure policy (default one)
> """
> self.prepare()
>
> self._provoke_commitlog_failure()
> failure = self.node1.grep_log("Failed .+ commit log segments. Commit
> disk failure policy is stop; terminating thread")
> logger.debug(failure)
> > assert failure, "Cannot find the commitlog failure message in logs"
> E AssertionError: Cannot find the commitlog failure message in logs
> E assert []
> commitlog_test.py:325: AssertionError
> {noformat}
--
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-19101) org.apache.cassandra.db.commitlog.CommitlogShutdownTest failed on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-19101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19101:
--
Fix Version/s: 5.x
> org.apache.cassandra.db.commitlog.CommitlogShutdownTest failed on trunk
> ---
>
> Key: CASSANDRA-19101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19101
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> {noformat}
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.cassandra.db.commitlog.CommitlogShutdownTest.testShutdownWithPendingTasks(CommitlogShutdownTest.java:96)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$10.evaluate(BMUnitRunner.java:393)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
> at
> com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:232)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:55)
> {noformat}
> Manual testing to confirm issues found by CircleCI when testing
> CASSANDRA-18464. Run with Java 11 / IntelliJ
--
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-19101) org.apache.cassandra.db.commitlog.CommitlogShutdownTest failed on trunk
Jacek Lewandowski created CASSANDRA-19101:
-
Summary: org.apache.cassandra.db.commitlog.CommitlogShutdownTest
failed on trunk
Key: CASSANDRA-19101
URL: https://issues.apache.org/jira/browse/CASSANDRA-19101
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Jacek Lewandowski
{noformat}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.cassandra.db.commitlog.CommitlogShutdownTest.testShutdownWithPendingTasks(CommitlogShutdownTest.java:96)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.jboss.byteman.contrib.bmunit.BMUnitRunner$10.evaluate(BMUnitRunner.java:393)
at
org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
at
com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
at
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:232)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:55)
{noformat}
Manual testing to confirm issues found by CircleCI when testing
CASSANDRA-18464. Run with Java 11 / IntelliJ
--
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-19102) org.apache.cassandra.distributed.test.ReadRepairTest#readRepairRTRangeMovementTest failed
Jacek Lewandowski created CASSANDRA-19102:
-
Summary:
org.apache.cassandra.distributed.test.ReadRepairTest#readRepairRTRangeMovementTest
failed
Key: CASSANDRA-19102
URL: https://issues.apache.org/jira/browse/CASSANDRA-19102
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/java
Reporter: Jacek Lewandowski
{noformat}
java.lang.AssertionError: Expected a different error message, but got Operation
failed - received 2 responses and 1 failures: INVALID_ROUTING from
/127.0.0.2:7012
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.cassandra.distributed.test.ReadRepairTest.readRepairRTRangeMovementTest(ReadRepairTest.java:424)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
at
com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
at
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:232)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:55)
{noformat}
Manual testing in IntelliJ / trunk. Detected during investigation of test
failures of CASSANDRA-18464
--
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-19099) Test Failure: 5.0 dtest-upgrade failing bc nodetool initiatlizecms
[ https://issues.apache.org/jira/browse/CASSANDRA-19099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19099: Reviewers: Sam Tunnicliffe, Sam Tunnicliffe Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe) Status: Review In Progress (was: Patch Available) > Test Failure: 5.0 dtest-upgrade failing bc nodetool initiatlizecms > -- > > Key: CASSANDRA-19099 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19099 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > > This commit > [cassandra-dtest@c0082c9|https://github.com/apache/cassandra-dtest/commit/c0082c9d0b2ded7da93942dfbfc7c87c896d53e0] > is not entirely working. Python upgrade dtests are still failing, see this > run on clean cassandra-5.0 > https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/261/workflows/6a15688e-b110-4ede-977c-550b85306867/jobs/21417/tests > > EDIT: also now visible on post-commit ci: > https://ci-cassandra.apache.org/job/Cassandra-5.0/119/ -- 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-19099) Test Failure: 5.0 dtest-upgrade failing bc nodetool initiatlizecms
[ https://issues.apache.org/jira/browse/CASSANDRA-19099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19099: Status: Ready to Commit (was: Review In Progress) +1 > Test Failure: 5.0 dtest-upgrade failing bc nodetool initiatlizecms > -- > > Key: CASSANDRA-19099 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19099 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-rc > > > This commit > [cassandra-dtest@c0082c9|https://github.com/apache/cassandra-dtest/commit/c0082c9d0b2ded7da93942dfbfc7c87c896d53e0] > is not entirely working. Python upgrade dtests are still failing, see this > run on clean cassandra-5.0 > https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/261/workflows/6a15688e-b110-4ede-977c-550b85306867/jobs/21417/tests > > EDIT: also now visible on post-commit ci: > https://ci-cassandra.apache.org/job/Cassandra-5.0/119/ -- 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-19059) Test failure: org.apache.cassandra.db.RepairedDataInfoTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski reassigned CASSANDRA-19059:
-
Assignee: Jacek Lewandowski (was: Marcus Eriksson)
> Test failure: org.apache.cassandra.db.RepairedDataInfoTest
> --
>
> Key: CASSANDRA-19059
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19059
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.1-alpha1
>
>
> {code}
> FSWriteError in build/test/cassandra/data/system
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:862)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:845)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursiveUsingNixCommand(PathUtils.java:384)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:402)
> at org.apache.cassandra.io.util.File.deleteRecursive(File.java:225)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:678)
> at org.apache.cassandra.schema.MockSchema.cleanup(MockSchema.java:377)
> at
> org.apache.cassandra.db.RepairedDataInfoTest.setUp(RepairedDataInfoTest.java:72)
> 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)
> Caused by: java.io.IOException: [rm, -rd,
> /tmp/cassandra/build/test/cassandra/data/system] returned non-zero exit code:
> 1
> stdout:
> {code}
> https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/256/workflows/c4fda8f1-a8d6-4523-be83-5e30b9de39fe/jobs/20450/tests
--
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-19059) Test failure: org.apache.cassandra.db.RepairedDataInfoTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790045#comment-17790045
]
Jacek Lewandowski commented on CASSANDRA-19059:
---
I suppose this is not related to CEP-21, but will look closer
> Test failure: org.apache.cassandra.db.RepairedDataInfoTest
> --
>
> Key: CASSANDRA-19059
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19059
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.1-alpha1
>
>
> {code}
> FSWriteError in build/test/cassandra/data/system
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:862)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:845)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursiveUsingNixCommand(PathUtils.java:384)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:402)
> at org.apache.cassandra.io.util.File.deleteRecursive(File.java:225)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:678)
> at org.apache.cassandra.schema.MockSchema.cleanup(MockSchema.java:377)
> at
> org.apache.cassandra.db.RepairedDataInfoTest.setUp(RepairedDataInfoTest.java:72)
> 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)
> Caused by: java.io.IOException: [rm, -rd,
> /tmp/cassandra/build/test/cassandra/data/system] returned non-zero exit code:
> 1
> stdout:
> {code}
> https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/256/workflows/c4fda8f1-a8d6-4523-be83-5e30b9de39fe/jobs/20450/tests
--
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-19059) Test failure: org.apache.cassandra.db.RepairedDataInfoTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790047#comment-17790047
]
Marcus Eriksson commented on CASSANDRA-19059:
-
it is actually, I'll post a patch this afternoon
> Test failure: org.apache.cassandra.db.RepairedDataInfoTest
> --
>
> Key: CASSANDRA-19059
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19059
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1-alpha1
>
>
> {code}
> FSWriteError in build/test/cassandra/data/system
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:862)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:845)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursiveUsingNixCommand(PathUtils.java:384)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:402)
> at org.apache.cassandra.io.util.File.deleteRecursive(File.java:225)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:678)
> at org.apache.cassandra.schema.MockSchema.cleanup(MockSchema.java:377)
> at
> org.apache.cassandra.db.RepairedDataInfoTest.setUp(RepairedDataInfoTest.java:72)
> 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)
> Caused by: java.io.IOException: [rm, -rd,
> /tmp/cassandra/build/test/cassandra/data/system] returned non-zero exit code:
> 1
> stdout:
> {code}
> https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/256/workflows/c4fda8f1-a8d6-4523-be83-5e30b9de39fe/jobs/20450/tests
--
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-19059) Test failure: org.apache.cassandra.db.RepairedDataInfoTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson reassigned CASSANDRA-19059:
---
Assignee: Marcus Eriksson (was: Jacek Lewandowski)
> Test failure: org.apache.cassandra.db.RepairedDataInfoTest
> --
>
> Key: CASSANDRA-19059
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19059
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1-alpha1
>
>
> {code}
> FSWriteError in build/test/cassandra/data/system
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:862)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:845)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursiveUsingNixCommand(PathUtils.java:384)
> at
> org.apache.cassandra.io.util.PathUtils.deleteRecursive(PathUtils.java:402)
> at org.apache.cassandra.io.util.File.deleteRecursive(File.java:225)
> at
> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:678)
> at org.apache.cassandra.schema.MockSchema.cleanup(MockSchema.java:377)
> at
> org.apache.cassandra.db.RepairedDataInfoTest.setUp(RepairedDataInfoTest.java:72)
> 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)
> Caused by: java.io.IOException: [rm, -rd,
> /tmp/cassandra/build/test/cassandra/data/system] returned non-zero exit code:
> 1
> stdout:
> {code}
> https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/256/workflows/c4fda8f1-a8d6-4523-be83-5e30b9de39fe/jobs/20450/tests
--
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-19060) Test failure: org.apache.cassandra.tools.JMXCompatabilityTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson reassigned CASSANDRA-19060:
---
Assignee: Marcus Eriksson
> Test failure: org.apache.cassandra.tools.JMXCompatabilityTest
> -
>
> Key: CASSANDRA-19060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19060
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 5.1-alpha1
>
>
> diff30, diff311, diff40 and diff41 failed on both j11_utests_trie and
> j17_utests_trie. This does not repeat locally
> {code}
> junit.framework.AssertionFailedError:
> Expecting empty but was: "Objects not in right:
> org.apache.cassandra.db:type=Caches
> org.apache.cassandra.metrics:type=Cache,scope=CounterCache,name=Capacity
> org.apache.cassandra.metrics:type=Cache,scope=CounterCache,name=Entries
> org.apache.cassandra.metrics:type=Cache,scope=CounterCache,name=FifteenMinuteHitRate
> org.apache.cassandra.metrics:type=Cache,scope=CounterCache,name=FiveMinuteHitRate
> org.apache.cassandra.metrics:type=Cache,scope=CounterCache,name=HitRate
> org.apache.cassandra.metrics:type=Cache,scope=CounterCache,name=Hits
> org.apache.cassandra.metrics:type=Cache,scope=CounterCache,name=OneMinuteHitRate
> org.apache.cassandra.metrics:type=Cache,scope=CounterCache,name=Requests
> org.apache.cassandra.metrics:type=Cache,scope=CounterCache,name=Size
> org.apache.cassandra.metrics:type=Cache,scope=KeyCache,name=Capacity
> org.apache.cassandra.metrics:type=Cache,scope=KeyCache,name=Entries
> org.apache.cassandra.metrics:type=Cache,scope=KeyCache,name=FifteenMinuteHitRate
> org.apache.cassandra.metrics:type=Cache,scope=KeyCache,name=FiveMinuteHitRate
> org.apache.cassandra.metrics:type=Cache,scope=KeyCache,name=HitRate
> org.apache.cassandra.metrics:type=Cache,scope=KeyCache,name=Hits
> org.apache.cassandra.metrics:type=Cache,scope=KeyCache,name=OneMinuteHitRate
> org.apache.cassandra.metrics:type=Cache,scope=KeyCache,name=Requests
> org.apache.cassandra.metrics:type=Cache,scope=KeyCache,name=Size
> org.apache.cassandra.metrics:type=Cache,scope=RowCache,name=Capacity
> org.apache.cassandra.metrics:type=Cache,scope=RowCache,name=Entries
> org.apache.cassandra.metrics:type=Cache,scope=RowCache,name=FifteenMinuteHitRate
> org.apache.cassandra.metrics:type=Cache,scope=RowCache,name=FiveMinuteHitRate
> org.apache.cassandra.metrics:type=Cache,scope=RowCache,name=HitRate
> org.apache.cassandra.metrics:type=Cache,scope=RowCache,name=Hits
> org.apache.cassandra.metrics:type=Cache,scope=RowCache,name=OneMinuteHitRate
> org.apache.cassandra.metrics:type=Cache,scope=RowCache,name=Requests
> org.apache.cassandra.metrics:type=Cache,scope=RowCache,name=Size
> "
> at
> org.apache.cassandra.tools.JMXCompatabilityTest.diff(JMXCompatabilityTest.java:273)
> at
> org.apache.cassandra.tools.JMXCompatabilityTest.diff30(JMXCompatabilityTest.java:139)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/256/workflows/c4fda8f1-a8d6-4523-be83-5e30b9de39fe/jobs/20465/tests
--
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-dtest) branch trunk updated: Add version guard around call to initializecms also in upgrade_tests/storage_engine_upgrade_test.py
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new eb518f3c Add version guard around call to initializecms also in
upgrade_tests/storage_engine_upgrade_test.py
eb518f3c is described below
commit eb518f3ca6f22753346dfb57c94e9935611c6a53
Author: Mick Semb Wever
AuthorDate: Sun Nov 26 22:18:45 2023 +0100
Add version guard around call to initializecms also in
upgrade_tests/storage_engine_upgrade_test.py
patch by Mick Semb Wever; reviewed by Sam Tunnicliffe for CASSANDRA-19099
---
upgrade_tests/storage_engine_upgrade_test.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/upgrade_tests/storage_engine_upgrade_test.py
b/upgrade_tests/storage_engine_upgrade_test.py
index 336c92ee..d791f2a7 100644
--- a/upgrade_tests/storage_engine_upgrade_test.py
+++ b/upgrade_tests/storage_engine_upgrade_test.py
@@ -69,7 +69,7 @@ class TestStorageEngineUpgrade(Tester):
node1.set_install_dir(install_dir=self.fixture_dtest_setup.default_install_dir)
self.install_legacy_parsing(node1)
node1.start(wait_for_binary_proto=True)
-if self.dtest_config.cassandra_version_from_build >= MAJOR_VERSION_5:
+if node1.get_cassandra_version() >= '5.1':
node1.nodetool("initializecms")
if self.fixture_dtest_setup.bootstrap:
cluster.set_install_dir(install_dir=self.fixture_dtest_setup.default_install_dir)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19099) Test Failure: 5.0 dtest-upgrade failing bc nodetool initiatlizecms
[ https://issues.apache.org/jira/browse/CASSANDRA-19099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19099: --- Fix Version/s: 5.0-beta1 5.0 5.1 (was: 5.0-rc) Since Version: 5.0-alpha2 Source Control Link: https://github.com/apache/cassandra-dtest/commit/eb518f3ca6f22753346dfb57c94e9935611c6a53 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed https://github.com/apache/cassandra-dtest/commit/eb518f3ca6f22753346dfb57c94e9935611c6a53 > Test Failure: 5.0 dtest-upgrade failing bc nodetool initiatlizecms > -- > > Key: CASSANDRA-19099 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19099 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-beta1, 5.0, 5.1 > > > This commit > [cassandra-dtest@c0082c9|https://github.com/apache/cassandra-dtest/commit/c0082c9d0b2ded7da93942dfbfc7c87c896d53e0] > is not entirely working. Python upgrade dtests are still failing, see this > run on clean cassandra-5.0 > https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/261/workflows/6a15688e-b110-4ede-977c-550b85306867/jobs/21417/tests > > EDIT: also now visible on post-commit ci: > https://ci-cassandra.apache.org/job/Cassandra-5.0/119/ -- 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-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19015: -- Attachment: image-2023-11-27-13-36-39-282.png > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt, image-2023-11-27-13-36-39-282.png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- 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-18464) Enable Direct I/O For CommitLog Files
[
https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790064#comment-17790064
]
Jacek Lewandowski commented on CASSANDRA-18464:
---
I think we are ready to merge, testing was difficult because of flakies. The
detailed information below (copied from pull request):
*trunk: https://github.com/apache/cassandra/pull/2931*
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1122/workflows/a6889c2a-3b62-4f04-91e5-4a4e270a6368
(j11)
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1122/workflows/0c4f1d43-810b-47bb-a83a-0d645f20efc0
(j17)
In both builds there are many failures, most of them are mentioned in
CASSANDRA-19055 (CEP-21 follow-up). For few others, I've run them locally on
trunk and they failed, thus I've created tickets for them (CASSANDRA-19102,
CASSANDRA-19101).
The only thing left is
org.apache.cassandra.distributed.test.ReadRepairEmptyRangeTombstonesTest - it
failed once on CircleCI by timeout in teardown method of the entire class, when
the cluster was being shutdown. It does not seem related. I could not reproduce
it locally on either feature branch or trunk. Here
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1123/workflows/a62417d7-5ecf-4d4e-9303-ff05df3282c0/jobs/51273
I couldn't reproduce it on CircleCI as well. It might have been some infra
problem I think.
*cassandra-5.0: https://github.com/apache/cassandra/pull/2894*
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1115/workflows/fd53b9c8-ee4d-4e25-8a06-2079f1732f8e
(j11)
test_stop_failure_policy passes locally and repeated run (100x) on this branch
passed
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1120/workflows/4a9716c9-24c3-485f-9f11-bb596cbbca5f/jobs/50783/steps
{{test_shutdown_wiped_node_cannot_join}} is flaky on both this branch
(https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1118/workflows/0eb8dc23-980d-45bc-9fc6-890ea05941a9/jobs/50573/tests
13% flakiness) and on {{cassandra-5.0}}
(https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1119/workflows/932a44e3-c25e-4c5e-b677-66579380faeb/jobs/50782/tests
17% flakiness), there is a ticket for this and links are
https://issues.apache.org/jira/browse/CASSANDRA-19097
Repeated unit tests seems to pass all tests but has some problems collecting
logs - the same problem is present on {{cassandra-5.0}} -
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1114/workflows/a1d02a59-31ee-48e2-9426-a4eca52ed3ff/jobs/50107
and I've created a ticket for that:
https://issues.apache.org/jira/browse/CASSANDRA-19086
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1120/workflows/2dc9ef3b-0a64-47bf-a05b-de7a36b1ca2c
(j17)
{{test_stop_failure_policy}} failed 1/100 in repeated run; therefore, I'm
rerunning the repeated run on {{cassandra-5.0}} here:
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1121/workflows/fce907b1-0526-4d4d-beb5-b6620737a5f3
- (failed 2/500, thus the test is flaky, creating ticket for it)
> Enable Direct I/O For CommitLog Files
> -
>
> Key: CASSANDRA-18464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18464
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Commit Log
>Reporter: Josh McKenzie
>Assignee: Amit Pawar
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: CommitLogStressTest.patch,
> EnableDirectIOForCommitLogUsingNativeAPI.patch,
> PeriodicCommitLogStressTest.tar.bz2, SetCommitLogFileSize.patch,
> UseDirectIOFeatureForCommitLogFiles.patch, image-2023-06-29-01-12-49-382.png
>
>
> Relocating from [dev@ email
> thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg]
>
> I shared my investigation about Commitlog I/O issue on large core count
> system in my previous email dated July-22 and link to the thread is given
> below.
> [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n]
> Basically, two solutions looked possible to improve the CommitLog I/O.
> # Multi-threaded syncing
> # Using Direct-IO through JNA
> I worked on 2nd option considering the following benefit compared to the
> first one
> # Direct I/O read/write throughput is very high compared to non-Direct I/O.
> Learnt through FIO benchmarking.
> # Reduces kernel file cache uses which in-turn reduces kernel I/O activity
> for Commitlog files only.
> # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage <
> 30% for Commitlog syncer thread with Direct I/O feature
> # Direct I/O implementation is easier compared to multi-threaded
> As per the community suggestion, less in code comple
[jira] [Updated] (CASSANDRA-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18464: -- Status: Ready to Commit (was: Review In Progress) > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CommitLogStressTest.patch, > EnableDirectIOForCommitLogUsingNativeAPI.patch, > PeriodicCommitLogStressTest.tar.bz2, SetCommitLogFileSize.patch, > UseDirectIOFeatureForCommitLogFiles.patch, image-2023-06-29-01-12-49-382.png > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- 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-18464) Enable Direct I/O For CommitLog Files
[
https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790064#comment-17790064
]
Jacek Lewandowski edited comment on CASSANDRA-18464 at 11/27/23 12:44 PM:
--
I think we are ready to merge, testing was difficult because of flakies. The
detailed information below (copied from pull request):
trunk: https://github.com/apache/cassandra/pull/2931
-
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1122/workflows/a6889c2a-3b62-4f04-91e5-4a4e270a6368
(j11)
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1122/workflows/0c4f1d43-810b-47bb-a83a-0d645f20efc0
(j17)
In both builds there are many failures, most of them are mentioned in
CASSANDRA-19055 (CEP-21 follow-up). For few others, I've run them locally on
trunk and they failed, thus I've created tickets for them (CASSANDRA-19102,
CASSANDRA-19101).
The only thing left is
org.apache.cassandra.distributed.test.ReadRepairEmptyRangeTombstonesTest - it
failed once on CircleCI by timeout in teardown method of the entire class, when
the cluster was being shutdown. It does not seem related. I could not reproduce
it locally on either feature branch or trunk. Here
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1123/workflows/a62417d7-5ecf-4d4e-9303-ff05df3282c0/jobs/51273
I couldn't reproduce it on CircleCI as well. It might have been some infra
problem I think.
cassandra-5.0: https://github.com/apache/cassandra/pull/2894
-
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1115/workflows/fd53b9c8-ee4d-4e25-8a06-2079f1732f8e
(j11)
test_stop_failure_policy passes locally and repeated run (100x) on this branch
passed
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1120/workflows/4a9716c9-24c3-485f-9f11-bb596cbbca5f/jobs/50783/steps
{{test_shutdown_wiped_node_cannot_join}} is flaky on both this branch
(https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1118/workflows/0eb8dc23-980d-45bc-9fc6-890ea05941a9/jobs/50573/tests
13% flakiness) and on {{cassandra-5.0}}
(https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1119/workflows/932a44e3-c25e-4c5e-b677-66579380faeb/jobs/50782/tests
17% flakiness), there is a ticket for this and links are
https://issues.apache.org/jira/browse/CASSANDRA-19097
Repeated unit tests seems to pass all tests but has some problems collecting
logs - the same problem is present on {{cassandra-5.0}} -
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1114/workflows/a1d02a59-31ee-48e2-9426-a4eca52ed3ff/jobs/50107
and I've created a ticket for that:
https://issues.apache.org/jira/browse/CASSANDRA-19086
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1120/workflows/2dc9ef3b-0a64-47bf-a05b-de7a36b1ca2c
(j17)
{{test_stop_failure_policy}} failed 1/100 in repeated run; therefore, I'm
rerunning the repeated run on {{cassandra-5.0}} here:
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1121/workflows/fce907b1-0526-4d4d-beb5-b6620737a5f3
- (failed 2/500, thus the test is flaky, creating ticket for it)
was (Author: jlewandowski):
I think we are ready to merge, testing was difficult because of flakies. The
detailed information below (copied from pull request):
*trunk: https://github.com/apache/cassandra/pull/2931*
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1122/workflows/a6889c2a-3b62-4f04-91e5-4a4e270a6368
(j11)
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1122/workflows/0c4f1d43-810b-47bb-a83a-0d645f20efc0
(j17)
In both builds there are many failures, most of them are mentioned in
CASSANDRA-19055 (CEP-21 follow-up). For few others, I've run them locally on
trunk and they failed, thus I've created tickets for them (CASSANDRA-19102,
CASSANDRA-19101).
The only thing left is
org.apache.cassandra.distributed.test.ReadRepairEmptyRangeTombstonesTest - it
failed once on CircleCI by timeout in teardown method of the entire class, when
the cluster was being shutdown. It does not seem related. I could not reproduce
it locally on either feature branch or trunk. Here
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1123/workflows/a62417d7-5ecf-4d4e-9303-ff05df3282c0/jobs/51273
I couldn't reproduce it on CircleCI as well. It might have been some infra
problem I think.
*cassandra-5.0: https://github.com/apache/cassandra/pull/2894*
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1115/workflows/fd53b9c8-ee4d-4e25-8a06-2079f1732f8e
(j11)
test_stop_failure_policy passes locally and repeated run (100x) o
[jira] [Updated] (CASSANDRA-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18464: -- Authors: Amit Pawar, Jacek Lewandowski (was: Amit Pawar) > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CommitLogStressTest.patch, > EnableDirectIOForCommitLogUsingNativeAPI.patch, > PeriodicCommitLogStressTest.tar.bz2, SetCommitLogFileSize.patch, > UseDirectIOFeatureForCommitLogFiles.patch, image-2023-06-29-01-12-49-382.png > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- 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-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790070#comment-17790070 ] Stefan Miklosovic commented on CASSANDRA-19015: --- Hi [~zaaath] thank you for your effort so far! Great progress. I was looking into the differences in the output and how it is now is this: !image-2023-11-27-13-36-39-282.png! I think that non-human output should print just raw numbers (the output on the right). For example, if we take a look at "Max SSTable size" which is 6.371 KiB, that should be just a number, in bytes. Same for "Bytes repaired" and "Bytes unrepaired" and "Bytes pending repair". All other figures are just plain numbers. On the other hand, human output (on the left), just reflects this and it should contain appropriate size units. It should all have consistent units, if we e.g. talk about bytes, the unit should be "B", not "bytes". Also, if you notice, for example, "Space used (live)" is "6.37 KiB" but "Max SSTable size" is "6.371KiB". Why is there a space? We either separate it with space everywhere or nowhere. I prefer to put space there. It is also once with 3 decimal points and the second time with just 2. This should be aligned as well. I am very sorry if it seems like we are postponing the merge, it may be a little bit frustrating, I get that. What we could do is that we just merge the latencies and time output as is in the current patch and we can cover the sizes in another ticket. How does that sound to you? > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt, image-2023-11-27-13-36-39-282.png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790070#comment-17790070 ] Stefan Miklosovic edited comment on CASSANDRA-19015 at 11/27/23 12:49 PM: -- Hi [~zaaath] thank you for your effort so far! Great progress. I was looking into the differences in the output and how it is now is this: !image-2023-11-27-13-49-14-247.png! I think that non-human output should print just raw numbers (the output on the right). For example, if we take a look at "Max SSTable size" which is 6.371 KiB, that should be just a number, in bytes. Same for "Bytes repaired" and "Bytes unrepaired" and "Bytes pending repair". All other figures are just plain numbers. On the other hand, human output (on the left), just reflects this and it should contain appropriate size units. It should all have consistent units, if we e.g. talk about bytes, the unit should be "B", not "bytes". Also, if you notice, for example, "Space used (live)" is "6.37 KiB" but "Max SSTable size" is "6.371KiB". Why is there a space? We either separate it with space everywhere or nowhere. I prefer to put space there. It is also once with 3 decimal points and the second time with just 2. This should be aligned as well. I am very sorry if it seems like we are postponing the merge, it may be a little bit frustrating, I get that. What we could do is that we just merge the latencies and time output as is in the current patch and we can cover the sizes in another ticket. How does that sound to you? was (Author: smiklosovic): Hi [~zaaath] thank you for your effort so far! Great progress. I was looking into the differences in the output and how it is now is this: !image-2023-11-27-13-36-39-282.png! I think that non-human output should print just raw numbers (the output on the right). For example, if we take a look at "Max SSTable size" which is 6.371 KiB, that should be just a number, in bytes. Same for "Bytes repaired" and "Bytes unrepaired" and "Bytes pending repair". All other figures are just plain numbers. On the other hand, human output (on the left), just reflects this and it should contain appropriate size units. It should all have consistent units, if we e.g. talk about bytes, the unit should be "B", not "bytes". Also, if you notice, for example, "Space used (live)" is "6.37 KiB" but "Max SSTable size" is "6.371KiB". Why is there a space? We either separate it with space everywhere or nowhere. I prefer to put space there. It is also once with 3 decimal points and the second time with just 2. This should be aligned as well. I am very sorry if it seems like we are postponing the merge, it may be a little bit frustrating, I get that. What we could do is that we just merge the latencies and time output as is in the current patch and we can cover the sizes in another ticket. How does that sound to you? > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt, > image-2023-11-27-13-36-39-282.png, image-2023-11-27-13-49-14-247.png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compressio
[jira] [Assigned] (CASSANDRA-19091) Test Failure: org.apache.cassandra.db.compaction.writers.CompactionAwareWriterTest.test*CompactionWriter-trie
[
https://issues.apache.org/jira/browse/CASSANDRA-19091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson reassigned CASSANDRA-19091:
---
Assignee: Marcus Eriksson
> Test Failure:
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriterTest.test*CompactionWriter-trie
> -
>
> Key: CASSANDRA-19091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19091
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Semb Wever
>Assignee: Marcus Eriksson
>Priority: Normal
>
> Broken on unit_tries, seen in CASSANDRA-19034
> -
> https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/257/workflows/95cdc05c-56fd-43bf-95ac-1122cf01535b/jobs/20685/tests
> -
> https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/257/workflows/ddcb5f4e-e2c5-430b-b922-f7064a244971/jobs/20670/tests
> Variants of…
> {noformat}
> junit.framework.AssertionFailedError:
> [BtiTableReader:bti(path='/tmp/cassandra/build/test/cassandra/data/cawt_keyspace/cawt_table-1b255f4def2540a60003/da-8-bti-Data.db'),
>
> BtiTableReader:bti(path='/tmp/cassandra/build/test/cassandra/data/cawt_keyspace/cawt_table-1b255f4def2540a60003/da-7-bti-Data.db')]
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriterTest.populate(CompactionAwareWriterTest.java:276)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriterTest.testSplittingSizeTieredCompactionWriter(CompactionAwareWriterTest.java:139)
> 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)
> {noformat}
--
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-19011) Harry-found exception in during SAI query
[
https://issues.apache.org/jira/browse/CASSANDRA-19011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Adamson reassigned CASSANDRA-19011:
Assignee: Mike Adamson (was: Caleb Rackliffe)
> Harry-found exception in during SAI query
> -
>
> Key: CASSANDRA-19011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19011
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Mike Adamson
>Priority: Normal
> Fix For: 5.0-rc
>
>
> Schema:
> {code:java}
> CREATE TABLE IF NOT EXISTS distributed_test_keyspace.tbl1 (pk1 bigint,ck1
> bigint,v1 ascii,v2 bigint, PRIMARY KEY (pk1, ck1)) WITH CLUSTERING ORDER BY
> (ck1 ASC);
> CREATE CUSTOM INDEX v1_sai_idx ON distributed_test_keyspace.tbl1 (v1) USING
> 'StorageAttachedIndex' WITH OPTIONS = {'case_sensitive': 'false',
> 'normalize': 'true', 'ascii': 'true'}; ;
> CREATE CUSTOM INDEX v2_sai_idx ON distributed_test_keyspace.tbl1 (v2) USING
> 'StorageAttachedIndex';
> {code}
> {code:java}
> java.lang.AssertionError: skipped to an item smaller than the target;
> iterator:
> org.apache.cassandra.index.sai.disk.IndexSearchResultIterator@f399f79, target
> key: PrimaryKey: { token: 8384965201802291970, partition:
> DecoratedKey(8384965201802291970, c4bc1c50f9e76a50), clustering:
> CLUSTERING:8b4b4c5991a4ea10 } , returned key: PrimaryKey: { token:
> 8384965201802291970, partition: DecoratedKey(8384965201802291970,
> c4bc1c50f9e76a50), clustering: CLUSTERING:89f1cf92658cb668 }
> at
> org.apache.cassandra.index.sai.iterators.KeyRangeIntersectionIterator.computeNext(KeyRangeIntersectionIterator.java:95)
> at
> org.apache.cassandra.index.sai.iterators.KeyRangeIntersectionIterator.computeNext(KeyRangeIntersectionIterator.java:39)
> at
> org.apache.cassandra.utils.AbstractGuavaIterator.tryToComputeNext(AbstractGuavaIterator.java:122)
> at
> org.apache.cassandra.index.sai.iterators.KeyRangeIterator.tryToComputeNext(KeyRangeIterator.java:129)
> at
> org.apache.cassandra.utils.AbstractGuavaIterator.hasNext(AbstractGuavaIterator.java:116)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextKey(StorageAttachedIndexSearcher.java:274)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextKeyInRange(StorageAttachedIndexSearcher.java:203)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextSelectedKeyInRange(StorageAttachedIndexSearcher.java:234)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextRowIterator(StorageAttachedIndexSearcher.java:188)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.computeNext(StorageAttachedIndexSearcher.java:169)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.computeNext(StorageAttachedIndexSearcher.java:111)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:91)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:338)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:201)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:186)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:346)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2186)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2581)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> relocated.shaded.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
>
> Unfortunately, there's no tooling for shrinking around SAI just yet, but I
> have a programmatic repro using INSERT and DELETE statements. I will do my
> best to post it asap, but thought this can already be useful for visibility.
--
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-19011) Harry-found exception in during SAI query
[
https://issues.apache.org/jira/browse/CASSANDRA-19011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Adamson updated CASSANDRA-19011:
-
Bug Category: Parent values: Availability(12983)
Complexity: Normal
Component/s: Feature/SAI
Discovered By: Fuzz Test
Severity: Normal
Status: Open (was: Triage Needed)
> Harry-found exception in during SAI query
> -
>
> Key: CASSANDRA-19011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19011
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Alex Petrov
>Assignee: Mike Adamson
>Priority: Normal
> Fix For: 5.0-rc
>
>
> Schema:
> {code:java}
> CREATE TABLE IF NOT EXISTS distributed_test_keyspace.tbl1 (pk1 bigint,ck1
> bigint,v1 ascii,v2 bigint, PRIMARY KEY (pk1, ck1)) WITH CLUSTERING ORDER BY
> (ck1 ASC);
> CREATE CUSTOM INDEX v1_sai_idx ON distributed_test_keyspace.tbl1 (v1) USING
> 'StorageAttachedIndex' WITH OPTIONS = {'case_sensitive': 'false',
> 'normalize': 'true', 'ascii': 'true'}; ;
> CREATE CUSTOM INDEX v2_sai_idx ON distributed_test_keyspace.tbl1 (v2) USING
> 'StorageAttachedIndex';
> {code}
> {code:java}
> java.lang.AssertionError: skipped to an item smaller than the target;
> iterator:
> org.apache.cassandra.index.sai.disk.IndexSearchResultIterator@f399f79, target
> key: PrimaryKey: { token: 8384965201802291970, partition:
> DecoratedKey(8384965201802291970, c4bc1c50f9e76a50), clustering:
> CLUSTERING:8b4b4c5991a4ea10 } , returned key: PrimaryKey: { token:
> 8384965201802291970, partition: DecoratedKey(8384965201802291970,
> c4bc1c50f9e76a50), clustering: CLUSTERING:89f1cf92658cb668 }
> at
> org.apache.cassandra.index.sai.iterators.KeyRangeIntersectionIterator.computeNext(KeyRangeIntersectionIterator.java:95)
> at
> org.apache.cassandra.index.sai.iterators.KeyRangeIntersectionIterator.computeNext(KeyRangeIntersectionIterator.java:39)
> at
> org.apache.cassandra.utils.AbstractGuavaIterator.tryToComputeNext(AbstractGuavaIterator.java:122)
> at
> org.apache.cassandra.index.sai.iterators.KeyRangeIterator.tryToComputeNext(KeyRangeIterator.java:129)
> at
> org.apache.cassandra.utils.AbstractGuavaIterator.hasNext(AbstractGuavaIterator.java:116)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextKey(StorageAttachedIndexSearcher.java:274)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextKeyInRange(StorageAttachedIndexSearcher.java:203)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextSelectedKeyInRange(StorageAttachedIndexSearcher.java:234)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextRowIterator(StorageAttachedIndexSearcher.java:188)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.computeNext(StorageAttachedIndexSearcher.java:169)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.computeNext(StorageAttachedIndexSearcher.java:111)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:91)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:338)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:201)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:186)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:346)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2186)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2581)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> relocated.shaded.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
>
> Unfortunately, there's no tooling for shrinking around SAI just yet, but I
> have a programmatic repro using INSERT and DELETE statements. I will do my
> best to post it asap, but thought this can already be useful for visibility.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
T
[jira] [Commented] (CASSANDRA-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790095#comment-17790095 ] Brad Schoening commented on CASSANDRA-19015: [~smiklosovic] I'd agree with covering the human output / size inconsistencies in another ticket. Since tablestats supports json output for machine readable format, it seems like human readable format is maybe an option for the default. But we'd need to get consensus on that. > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt, > image-2023-11-27-13-36-39-282.png, image-2023-11-27-13-49-14-247.png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- 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-19032) StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey
[ https://issues.apache.org/jira/browse/CASSANDRA-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790096#comment-17790096 ] Mike Adamson commented on CASSANDRA-19032: -- The patches and CI for this ticket are here: | [5.0|https://github.com/apache/cassandra/pull/2932]|[j11|https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/404/workflows/bae70e8f-7435-48d0-8651-8f03db19fa7d]|[j17|https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/404/workflows/5fdb25e1-6c63-4e53-9266-0b47703d4855]| |[trunk|https://github.com/apache/cassandra/pull/2932]|[j11|https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/405/workflows/bfb8801c-f432-47f5-9a6c-a810f1cbe67c]|[j17|https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/405/workflows/556278d4-19e8-4f79-841c-bb5bbc728cbf]| > StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey > - > > Key: CASSANDRA-19032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19032 > Project: Cassandra > Issue Type: Bug > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0-rc > > Time Spent: 20m > Remaining Estimate: 0h > > The StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding has been > showing flakiness in test runs and need investigating and fixing. Looking at > the failure is seems that there is an edge condition where the index will > fail to complete its build if a table truncate is triggered at the right > moment. > We need to try and provoke this edge condition using injection and then see > what can be done to fix the build failure. -- 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-19032) StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey
[ https://issues.apache.org/jira/browse/CASSANDRA-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790096#comment-17790096 ] Mike Adamson edited comment on CASSANDRA-19032 at 11/27/23 2:33 PM: The patches and CI for this ticket are here: | [5.0|https://github.com/apache/cassandra/pull/2932]|[j11|https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/404/workflows/bae70e8f-7435-48d0-8651-8f03db19fa7d]|[j17|https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/404/workflows/5fdb25e1-6c63-4e53-9266-0b47703d4855]| |[trunk|https://github.com/apache/cassandra/pull/2932]|[j11|https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/405/workflows/bfb8801c-f432-47f5-9a6c-a810f1cbe67c]|[j17|https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/405/workflows/556278d4-19e8-4f79-841c-bb5bbc728cbf]| The patch provides a truncate task for SAI that marks the index as queryable. There was a window of opportunity if the initial index build and table truncate operations were triggered concurrently where the index build was interrupted. This meant that index wasn't marking itself as queryable. was (Author: mike_tr_adamson): The patches and CI for this ticket are here: | [5.0|https://github.com/apache/cassandra/pull/2932]|[j11|https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/404/workflows/bae70e8f-7435-48d0-8651-8f03db19fa7d]|[j17|https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/404/workflows/5fdb25e1-6c63-4e53-9266-0b47703d4855]| |[trunk|https://github.com/apache/cassandra/pull/2932]|[j11|https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/405/workflows/bfb8801c-f432-47f5-9a6c-a810f1cbe67c]|[j17|https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/405/workflows/556278d4-19e8-4f79-841c-bb5bbc728cbf]| > StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey > - > > Key: CASSANDRA-19032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19032 > Project: Cassandra > Issue Type: Bug > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0-rc > > Time Spent: 20m > Remaining Estimate: 0h > > The StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding has been > showing flakiness in test runs and need investigating and fixing. Looking at > the failure is seems that there is an edge condition where the index will > fail to complete its build if a table truncate is triggered at the right > moment. > We need to try and provoke this edge condition using injection and then see > what can be done to fix the build failure. -- 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-19032) StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey
[ https://issues.apache.org/jira/browse/CASSANDRA-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-19032: - Test and Documentation Plan: Current CI runs are in the comments Status: Patch Available (was: In Progress) > StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey > - > > Key: CASSANDRA-19032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19032 > Project: Cassandra > Issue Type: Bug > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0-rc > > Time Spent: 20m > Remaining Estimate: 0h > > The StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding has been > showing flakiness in test runs and need investigating and fixing. Looking at > the failure is seems that there is an edge condition where the index will > fail to complete its build if a table truncate is triggered at the right > moment. > We need to try and provoke this edge condition using injection and then see > what can be done to fix the build failure. -- 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-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790104#comment-17790104 ] Maxwell Guo commented on CASSANDRA-18464: - Thank you [~jlewandowski].(y) > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CommitLogStressTest.patch, > EnableDirectIOForCommitLogUsingNativeAPI.patch, > PeriodicCommitLogStressTest.tar.bz2, SetCommitLogFileSize.patch, > UseDirectIOFeatureForCommitLogFiles.patch, image-2023-06-29-01-12-49-382.png > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- 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-18935) Fix nodetool enable/disablebinary to correctly set rpc
[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18935:
-
Status: Review In Progress (was: Needs Committer)
> Fix nodetool enable/disablebinary to correctly set rpc
> --
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: 18935-3.11.patch, image-2023-11-16-10-56-16-693.png,
> signature.asc
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
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-18824) Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused missing replica
[ https://issues.apache.org/jira/browse/CASSANDRA-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18824: - Status: Patch Available (was: Needs Committer) > Backport CASSANDRA-16418: Cleanup behaviour during node decommission caused > missing replica > --- > > Key: CASSANDRA-18824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18824 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: Szymon Miezal >Assignee: Szymon Miezal >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Node decommission triggers data transfer to other nodes. While this transfer > is in progress, > receiving nodes temporarily hold token ranges in a pending state. However, > the cleanup process currently doesn't consider these pending ranges when > calculating token ownership. > As a consequence, data that is already stored in sstables gets inadvertently > cleaned up. > STR: > * Create two node cluster > * Create keyspace with RF=1 > * Insert sample data (assert data is available when querying both nodes) > * Start decommission process of node 1 > * Start running cleanup in a loop on node 2 until decommission on node 1 > finishes > * Verify of all rows are in the cluster - it will fail as the previous step > removed some of the rows > It seems that the cleanup process does not take into account the pending > ranges, it uses only the local ranges - > [https://github.com/apache/cassandra/blob/caad2f24f95b494d05c6b5d86a8d25fbee58d7c2/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L466]. > There are two solutions to the problem. > One would be to change the cleanup process in a way that it start taking > pending ranges into account. Even thought it might sound tempting at first it > will require involving changes and a lot of testing effort. > Alternatively we could interrupt/prevent the cleanup process from running > when any pending range on a node is detected. That sounds like a reasonable > alternative to the problem and something that is relatively easy to implement. > The bug has been already fixed in 4.x with CASSANDRA-16418, the goal of this > ticket is to backport it to 3.x. -- 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-18935) Fix nodetool enable/disablebinary to correctly set rpc
[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790115#comment-17790115
]
Brandon Williams commented on CASSANDRA-18935:
--
I am +1 on this.
I think we should figure out why counter_leader_with_partial_view_test didn't
fail (and still does not currently) when we set rpc_ready to false, otherwise
it's not very useful.
> Fix nodetool enable/disablebinary to correctly set rpc
> --
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: 18935-3.11.patch, image-2023-11-16-10-56-16-693.png,
> signature.asc
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
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-18935) Fix nodetool enable/disablebinary to correctly set rpc
[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18935:
-
Status: Ready to Commit (was: Review In Progress)
> Fix nodetool enable/disablebinary to correctly set rpc
> --
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: 18935-3.11.patch, image-2023-11-16-10-56-16-693.png,
> signature.asc
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-79) Sidecar should be able to load metadata even if the local instance is unavailable
[ https://issues.apache.org/jira/browse/CASSANDRASC-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-79: - Status: Patch Available (was: Needs Committer) > Sidecar should be able to load metadata even if the local instance is > unavailable > - > > Key: CASSANDRASC-79 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-79 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Doug Rohrer >Assignee: Doug Rohrer >Priority: Normal > Labels: pull-request-available > > Today, the sidecar’s CassandraAdapter/CqlSessionProvider uses a load > balancing policy that only allows connections to a single instance configured > for one of the managed instances of Cassandra. However, this is both > unnecessary and potentially harmful, as requests to that instance’s hostname > will fail to retrieve information like keyspace/cluster metadata when that > instance is unavailable, and will not receive any updates to metadata either, > which can cause stale metadata to be used. > Instead, the CqlSessionProvider should take a list of contact points and use > them to connect to the whole cluster (or a subset of nodes) without the > single-instance load balancing policy. Where it is necessary to query an > individual instance (system tables, attempts to check the health of a > particular instance) we can, instead, use the driver’s ability to direct > queries to a specific host on a per-statement basis. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-79) Sidecar should be able to load metadata even if the local instance is unavailable
[ https://issues.apache.org/jira/browse/CASSANDRASC-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Rohrer updated CASSANDRASC-79: --- Status: Needs Committer (was: Patch Available) > Sidecar should be able to load metadata even if the local instance is > unavailable > - > > Key: CASSANDRASC-79 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-79 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Doug Rohrer >Assignee: Doug Rohrer >Priority: Normal > Labels: pull-request-available > > Today, the sidecar’s CassandraAdapter/CqlSessionProvider uses a load > balancing policy that only allows connections to a single instance configured > for one of the managed instances of Cassandra. However, this is both > unnecessary and potentially harmful, as requests to that instance’s hostname > will fail to retrieve information like keyspace/cluster metadata when that > instance is unavailable, and will not receive any updates to metadata either, > which can cause stale metadata to be used. > Instead, the CqlSessionProvider should take a list of contact points and use > them to connect to the whole cluster (or a subset of nodes) without the > single-instance load balancing policy. Where it is necessary to query an > individual instance (system tables, attempts to check the health of a > particular instance) we can, instead, use the driver’s ability to direct > queries to a specific host on a per-statement basis. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-79) Sidecar should be able to load metadata even if the local instance is unavailable
[ https://issues.apache.org/jira/browse/CASSANDRASC-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-79: - Reviewers: Yifan Cai Status: Review In Progress (was: Patch Available) > Sidecar should be able to load metadata even if the local instance is > unavailable > - > > Key: CASSANDRASC-79 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-79 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Doug Rohrer >Assignee: Doug Rohrer >Priority: Normal > Labels: pull-request-available > > Today, the sidecar’s CassandraAdapter/CqlSessionProvider uses a load > balancing policy that only allows connections to a single instance configured > for one of the managed instances of Cassandra. However, this is both > unnecessary and potentially harmful, as requests to that instance’s hostname > will fail to retrieve information like keyspace/cluster metadata when that > instance is unavailable, and will not receive any updates to metadata either, > which can cause stale metadata to be used. > Instead, the CqlSessionProvider should take a list of contact points and use > them to connect to the whole cluster (or a subset of nodes) without the > single-instance load balancing policy. Where it is necessary to query an > individual instance (system tables, attempts to check the health of a > particular instance) we can, instead, use the driver’s ability to direct > queries to a specific host on a per-statement basis. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-84) Expose additional node settings
[
https://issues.apache.org/jira/browse/CASSANDRASC-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRASC-84:
-
Reviewers: Yifan Cai
Status: Review In Progress (was: Patch Available)
> Expose additional node settings
> ---
>
> Key: CASSANDRASC-84
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-84
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Rest API
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> Sidecar exposes settings from the Cassandra node via the node settings API
> endpoint. The information exposed is limited, and we need to start exposing
> additional information from the {{system.local}} table, for example
> {{datacenter}} information, owned token ranges, and the local address and
> port for the native protocol. This information can be consumed by Sidecar
> itself, as well as the Cassandra Analytics library.
--
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-18744) cassandra-stress in simplenative mode and prepared fails with exceptions
[ https://issues.apache.org/jira/browse/CASSANDRA-18744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18744: - Status: Review In Progress (was: Needs Committer) > cassandra-stress in simplenative mode and prepared fails with exceptions > > > Key: CASSANDRA-18744 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18744 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Brad Schoening >Assignee: Dmitry Bychkov >Priority: Low > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 2h > Remaining Estimate: 0h > > % cassandra-stress write n=10 -mode simplenative cql3 prepared > ... > ap'; org.apache.cassandra.transport.messages.ResultMessage$Prepared is in > unnamed module of loader 'app') > java.lang.ClassCastException: class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > java.io.IOException: Operation x10 on key(s) [4e334f364c4c4b373530]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.io.IOException: Operation x10 on key(s) [373038504b3436363830]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.lang.RuntimeException: Failed to execute warmup > at org.apache.cassandra.stress.StressAction.warmup(StressAction.java:128) > at org.apache.cassandra.stress.StressAction.run(StressAction.java:71) > at org.apache.cassandra.stress.Stress.run(Stress.java:101) > at org.apache.cassandra.stress.Stress.main(Stress.java:54) -- 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-18744) cassandra-stress in simplenative mode and prepared fails with exceptions
[ https://issues.apache.org/jira/browse/CASSANDRA-18744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18744: - Status: Ready to Commit (was: Review In Progress) +1 > cassandra-stress in simplenative mode and prepared fails with exceptions > > > Key: CASSANDRA-18744 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18744 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Brad Schoening >Assignee: Dmitry Bychkov >Priority: Low > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 2h > Remaining Estimate: 0h > > % cassandra-stress write n=10 -mode simplenative cql3 prepared > ... > ap'; org.apache.cassandra.transport.messages.ResultMessage$Prepared is in > unnamed module of loader 'app') > java.lang.ClassCastException: class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > java.io.IOException: Operation x10 on key(s) [4e334f364c4c4b373530]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.io.IOException: Operation x10 on key(s) [373038504b3436363830]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.lang.RuntimeException: Failed to execute warmup > at org.apache.cassandra.stress.StressAction.warmup(StressAction.java:128) > at org.apache.cassandra.stress.StressAction.run(StressAction.java:71) > at org.apache.cassandra.stress.Stress.run(Stress.java:101) > at org.apache.cassandra.stress.Stress.main(Stress.java:54) -- 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-18744) cassandra-stress in simplenative mode and prepared fails with exceptions
[ https://issues.apache.org/jira/browse/CASSANDRA-18744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18744: - Reviewers: Brandon Williams, Stefan Miklosovic (was: Stefan Miklosovic) > cassandra-stress in simplenative mode and prepared fails with exceptions > > > Key: CASSANDRA-18744 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18744 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Brad Schoening >Assignee: Dmitry Bychkov >Priority: Low > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 2h > Remaining Estimate: 0h > > % cassandra-stress write n=10 -mode simplenative cql3 prepared > ... > ap'; org.apache.cassandra.transport.messages.ResultMessage$Prepared is in > unnamed module of loader 'app') > java.lang.ClassCastException: class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > java.io.IOException: Operation x10 on key(s) [4e334f364c4c4b373530]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.io.IOException: Operation x10 on key(s) [373038504b3436363830]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.lang.RuntimeException: Failed to execute warmup > at org.apache.cassandra.stress.StressAction.warmup(StressAction.java:128) > at org.apache.cassandra.stress.StressAction.run(StressAction.java:71) > at org.apache.cassandra.stress.Stress.run(Stress.java:101) > at org.apache.cassandra.stress.Stress.main(Stress.java:54) -- 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-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790137#comment-17790137 ] Leo Toff commented on CASSANDRA-19015: -- [~smiklosovic] That sounds great, I think we should merge the latencies and time output and then cover the sizes in another ticket. The human-readable output seems to be lacking units like in "Compacted partition minimum bytes", etc. Thanks for catching the inconsistencies. We could resolve these issues in another ticket. And I'd agree with Brad that human readability should be the default for non-JSON / non-YAML output. The only caveat, perhaps, is to make the transition more gradual in case there are scripts that depend on `nodetool`'s output. > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt, > image-2023-11-27-13-36-39-282.png, image-2023-11-27-13-49-14-247.png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- 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-19088) Test Failure: pushed_notifications_test.TestPushedNotifications.test_move_single_node
[
https://issues.apache.org/jira/browse/CASSANDRA-19088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe reassigned CASSANDRA-19088:
---
Assignee: Sam Tunnicliffe
> Test Failure:
> pushed_notifications_test.TestPushedNotifications.test_move_single_node
> -
>
> Key: CASSANDRA-19088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19088
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Semb Wever
>Assignee: Sam Tunnicliffe
>Priority: Normal
>
> In j11_dtests from CASSANDRA-19034
> https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/402/workflows/92aacb84-fd3a-48e0-9fb2-d1e2fe6fc71a/jobs/35345/tests
> {noformat}
> AssertionError: assert 'MOVED_NODE' == 'NEW_NODE'
> - NEW_NODE
> + MOVED_NODE
> self = 0x7fd28ee838d0>
> @pytest.mark.no_vnodes
> def test_move_single_node(self):
> """
> @jira_ticket CASSANDRA-8516
> Moving a token should result in MOVED_NODE notifications.
> """
> self.cluster.populate(3).start()
>
> waiters = [NotificationWaiter(self, node, ["TOPOLOGY_CHANGE"])
>for node in list(self.cluster.nodes.values())]
>
> # The first node sends NEW_NODE for the other 2 nodes during startup,
> in case they are
> # late due to network delays let's block a bit longer
> logger.debug("Waiting for unwanted notifications")
> waiters[0].wait_for_notifications(timeout=30, num_notifications=2)
> waiters[0].clear_notifications()
>
> logger.debug("Issuing move command")
> node1 = list(self.cluster.nodes.values())[0]
> node1.move("123")
>
> for waiter in waiters:
> logger.debug("Waiting for notification from
> {}".format(waiter.address,))
> notifications = waiter.wait_for_notifications(60.0)
> assert 1 == len(notifications), notifications
> notification = notifications[0]
> change_type = notification["change_type"]
> address, port = notification["address"]
> > assert "MOVED_NODE" == change_type
> E AssertionError: assert 'MOVED_NODE' == 'NEW_NODE'
> E - NEW_NODE
> E + MOVED_NODE
> pushed_notifications_test.py:118: AssertionError
> {noformat}
--
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-19088) Test Failure: pushed_notifications_test.TestPushedNotifications.test_move_single_node
[
https://issues.apache.org/jira/browse/CASSANDRA-19088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19088:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Test/dtest/python
Discovered By: DTest
Fix Version/s: 5.1-alpha1
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure:
> pushed_notifications_test.TestPushedNotifications.test_move_single_node
> -
>
> Key: CASSANDRA-19088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19088
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.1-alpha1
>
>
> In j11_dtests from CASSANDRA-19034
> https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/402/workflows/92aacb84-fd3a-48e0-9fb2-d1e2fe6fc71a/jobs/35345/tests
> {noformat}
> AssertionError: assert 'MOVED_NODE' == 'NEW_NODE'
> - NEW_NODE
> + MOVED_NODE
> self = 0x7fd28ee838d0>
> @pytest.mark.no_vnodes
> def test_move_single_node(self):
> """
> @jira_ticket CASSANDRA-8516
> Moving a token should result in MOVED_NODE notifications.
> """
> self.cluster.populate(3).start()
>
> waiters = [NotificationWaiter(self, node, ["TOPOLOGY_CHANGE"])
>for node in list(self.cluster.nodes.values())]
>
> # The first node sends NEW_NODE for the other 2 nodes during startup,
> in case they are
> # late due to network delays let's block a bit longer
> logger.debug("Waiting for unwanted notifications")
> waiters[0].wait_for_notifications(timeout=30, num_notifications=2)
> waiters[0].clear_notifications()
>
> logger.debug("Issuing move command")
> node1 = list(self.cluster.nodes.values())[0]
> node1.move("123")
>
> for waiter in waiters:
> logger.debug("Waiting for notification from
> {}".format(waiter.address,))
> notifications = waiter.wait_for_notifications(60.0)
> assert 1 == len(notifications), notifications
> notification = notifications[0]
> change_type = notification["change_type"]
> address, port = notification["address"]
> > assert "MOVED_NODE" == change_type
> E AssertionError: assert 'MOVED_NODE' == 'NEW_NODE'
> E - NEW_NODE
> E + MOVED_NODE
> pushed_notifications_test.py:118: AssertionError
> {noformat}
--
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-19103) Filter replicas for counter mutation leader to be JOINED replicas to decouple from RPC_READY state
Stefan Miklosovic created CASSANDRA-19103: - Summary: Filter replicas for counter mutation leader to be JOINED replicas to decouple from RPC_READY state Key: CASSANDRA-19103 URL: https://issues.apache.org/jira/browse/CASSANDRA-19103 Project: Cassandra Issue Type: Improvement Reporter: Stefan Miklosovic In CASSANDRA-18935, what I did was that if transport is turned off while node is up, it will set RPC_READY to "false". Before 18935 was in, if you turned off transport, RPC_READY was not changed to true but it stayed to be "true" for ever. Clearly, this was wrong, so I fixed that, but when I did that, the code which decides who will be the leader of counter mutation was broken, because that node filtered out all nodes for which RPC_READY is false, which never happened before, because nobody has set it to "false" on turned off transport. So, we decided to revert this regression in 5.0-rc1 and I was waiting for CEP-21 to be in because I saw it is rewritten there with TODO to filter JOINED nodes. Hence, we can decouple this logic and fix RPC_READY status finally. -- 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-19067) Test failure: j11_dtests_large.replace_address_test.TestReplaceAddress
[
https://issues.apache.org/jira/browse/CASSANDRA-19067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19067:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Test/dtest/java
Discovered By: DTest
Fix Version/s: 5.1-alpha1
Severity: Normal
Assignee: Sam Tunnicliffe
Status: Open (was: Triage Needed)
> Test failure: j11_dtests_large.replace_address_test.TestReplaceAddress
> --
>
> Key: CASSANDRA-19067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19067
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Alex Petrov
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.1-alpha1
>
>
> CircleCI failure:
> https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/256/workflows/c4fda8f1-a8d6-4523-be83-5e30b9de39fe/jobs/20466/tests
> ```
> assert 0 == 1
> + where 0 = len(set())
> self =
> @pytest.mark.resource_intensive
> def test_replace_first_boot(self):
> > self._test_replace_node(jvm_option='replace_address_first_boot')
> replace_address_test.py:281:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> replace_address_test.py:300: in _test_replace_node
> previous_log_size = self._verify_tokens_migrated_successfully()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> previous_log_size = None
> def _verify_tokens_migrated_successfully(self, previous_log_size=None):
> if not self.dtest_config.use_vnodes:
> num_tokens = 1
> else:
> # a little hacky but grep_log returns the whole line...
> num_tokens =
> int(self.replacement_node.get_conf_option('num_tokens'))
>
> logger.debug("Verifying {} tokens migrated
> successfully".format(num_tokens))
> replmnt_address =
> self.replacement_node.address_for_current_version_slashy()
> repled_address =
> self.replaced_node.address_for_current_version_slashy()
> token_ownership_log = r"Token (.*?) changing ownership from {} to
> {}".format(repled_address,
>
>replmnt_address)
> logs = self.replacement_node.grep_log(token_ownership_log)
>
> if (previous_log_size is not None):
> assert len(logs) == previous_log_size
>
> moved_tokens = set([l[1].group(1) for l in logs])
> logger.debug("number of moved tokens: {}".format(len(moved_tokens)))
> > assert len(moved_tokens) == num_tokens
> E assert 0 == 1
> E+ where 0 = len(set())
> replace_address_test.py:207: AssertionError
> ```
--
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-19103) Filter replicas for counter mutation leader to be JOINED replicas to decouple from RPC_READY state
[ https://issues.apache.org/jira/browse/CASSANDRA-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19103: -- Test and Documentation Plan: CI Status: Patch Available (was: Open) > Filter replicas for counter mutation leader to be JOINED replicas to decouple > from RPC_READY state > -- > > Key: CASSANDRA-19103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19103 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > In CASSANDRA-18935, what I did was that if transport is turned off while node > is up, it will set RPC_READY to "false". Before 18935 was in, if you turned > off transport, RPC_READY was not changed to true but it stayed to be "true" > for ever. > Clearly, this was wrong, so I fixed that, but when I did that, the code which > decides who will be the leader of counter mutation was broken, because that > node filtered out all nodes for which RPC_READY is false, which never > happened before, because nobody has set it to "false" on turned off transport. > So, we decided to revert this regression in 5.0-rc1 and I was waiting for > CEP-21 to be in because I saw it is rewritten there with TODO to filter > JOINED nodes. > Hence, we can decouple this logic and fix RPC_READY status finally. -- 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-19103) Filter replicas for counter mutation leader to be JOINED replicas to decouple from RPC_READY state
[ https://issues.apache.org/jira/browse/CASSANDRA-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19103: -- Change Category: Operability Complexity: Normal Component/s: Transactional Cluster Metadata Fix Version/s: 5.x Assignee: Stefan Miklosovic Status: Open (was: Triage Needed) > Filter replicas for counter mutation leader to be JOINED replicas to decouple > from RPC_READY state > -- > > Key: CASSANDRA-19103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19103 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > In CASSANDRA-18935, what I did was that if transport is turned off while node > is up, it will set RPC_READY to "false". Before 18935 was in, if you turned > off transport, RPC_READY was not changed to true but it stayed to be "true" > for ever. > Clearly, this was wrong, so I fixed that, but when I did that, the code which > decides who will be the leader of counter mutation was broken, because that > node filtered out all nodes for which RPC_READY is false, which never > happened before, because nobody has set it to "false" on turned off transport. > So, we decided to revert this regression in 5.0-rc1 and I was waiting for > CEP-21 to be in because I saw it is rewritten there with TODO to filter > JOINED nodes. > Hence, we can decouple this logic and fix RPC_READY status finally. -- 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-19067) Test failure: j11_dtests_large.replace_address_test.TestReplaceAddress
[
https://issues.apache.org/jira/browse/CASSANDRA-19067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19067:
Description:
CircleCI failure:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/256/workflows/c4fda8f1-a8d6-4523-be83-5e30b9de39fe/jobs/20466/tests
{code}
assert 0 == 1
+ where 0 = len(set())
self =
@pytest.mark.resource_intensive
def test_replace_first_boot(self):
> self._test_replace_node(jvm_option='replace_address_first_boot')
replace_address_test.py:281:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
replace_address_test.py:300: in _test_replace_node
previous_log_size = self._verify_tokens_migrated_successfully()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
previous_log_size = None
def _verify_tokens_migrated_successfully(self, previous_log_size=None):
if not self.dtest_config.use_vnodes:
num_tokens = 1
else:
# a little hacky but grep_log returns the whole line...
num_tokens =
int(self.replacement_node.get_conf_option('num_tokens'))
logger.debug("Verifying {} tokens migrated
successfully".format(num_tokens))
replmnt_address =
self.replacement_node.address_for_current_version_slashy()
repled_address = self.replaced_node.address_for_current_version_slashy()
token_ownership_log = r"Token (.*?) changing ownership from {} to
{}".format(repled_address,
replmnt_address)
logs = self.replacement_node.grep_log(token_ownership_log)
if (previous_log_size is not None):
assert len(logs) == previous_log_size
moved_tokens = set([l[1].group(1) for l in logs])
logger.debug("number of moved tokens: {}".format(len(moved_tokens)))
> assert len(moved_tokens) == num_tokens
E assert 0 == 1
E+ where 0 = len(set())
replace_address_test.py:207: AssertionError
{code}
was:
CircleCI failure:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/256/workflows/c4fda8f1-a8d6-4523-be83-5e30b9de39fe/jobs/20466/tests
```
assert 0 == 1
+ where 0 = len(set())
self =
@pytest.mark.resource_intensive
def test_replace_first_boot(self):
> self._test_replace_node(jvm_option='replace_address_first_boot')
replace_address_test.py:281:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
replace_address_test.py:300: in _test_replace_node
previous_log_size = self._verify_tokens_migrated_successfully()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
previous_log_size = None
def _verify_tokens_migrated_successfully(self, previous_log_size=None):
if not self.dtest_config.use_vnodes:
num_tokens = 1
else:
# a little hacky but grep_log returns the whole line...
num_tokens =
int(self.replacement_node.get_conf_option('num_tokens'))
logger.debug("Verifying {} tokens migrated
successfully".format(num_tokens))
replmnt_address =
self.replacement_node.address_for_current_version_slashy()
repled_address = self.replaced_node.address_for_current_version_slashy()
token_ownership_log = r"Token (.*?) changing ownership from {} to
{}".format(repled_address,
replmnt_address)
logs = self.replacement_node.grep_log(token_ownership_log)
if (previous_log_size is not None):
assert len(logs) == previous_log_size
moved_tokens = set([l[1].group(1) for l in logs])
logger.debug("number of moved tokens: {}".format(len(moved_tokens)))
> assert len(moved_tokens) == num_tokens
E assert 0 == 1
E+ where 0 = len(set())
replace_address_test.py:207: AssertionError
```
> Test failure: j11_dtests_large.replace_address_test.TestReplaceAddress
> --
>
> Key: CASSANDRA-19067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19067
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Alex Petrov
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.1-alpha1
>
>
> CircleCI failure:
> https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/256/workflows/c4fda8f1-a8d6-4523-be83-5e30b9de39fe/jobs/20466/tests
> {code}
> assert 0 == 1
> + where 0 = len(set())
> self =
> @pytest.mark.resource_intensive
> def test_replace_first_boot(self):
> > self._test_replace_node(jvm_option='replace_address_first_
[jira] [Commented] (CASSANDRA-18935) Fix nodetool enable/disablebinary to correctly set rpc
[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790161#comment-17790161
]
Stefan Miklosovic commented on CASSANDRA-18935:
---
I created this for trunk CASSANDRA-19103
> Fix nodetool enable/disablebinary to correctly set rpc
> --
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: 18935-3.11.patch, image-2023-11-16-10-56-16-693.png,
> signature.asc
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
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-18935) Fix nodetool enable/disablebinary to correctly set rpc
[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790161#comment-17790161
]
Stefan Miklosovic edited comment on CASSANDRA-18935 at 11/27/23 4:19 PM:
-
I created this for trunk CASSANDRA-19103
TCM has landed in the meanwhile and stuff has changed around this logic. I will
try to get some response from TCM guys.
was (Author: smiklosovic):
I created this for trunk CASSANDRA-19103
> Fix nodetool enable/disablebinary to correctly set rpc
> --
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: 18935-3.11.patch, image-2023-11-16-10-56-16-693.png,
> signature.asc
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
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-19103) Filter replicas for counter mutation leader to be JOINED replicas to decouple from RPC_READY state
[ https://issues.apache.org/jira/browse/CASSANDRA-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790163#comment-17790163 ] Stefan Miklosovic commented on CASSANDRA-19103: --- this is basically blocking CASSANDRA-18935 because by TCM being merged it changed the trunk so reverting stuff in CASSANDRA-18935 would not apply for trunk anymore. [~samt] [~ifesdjeen] [~marcuse] I would love to get some feedback and review here! Not sure who was dealing with that part of the code as it was squashed and committed by Sam. > Filter replicas for counter mutation leader to be JOINED replicas to decouple > from RPC_READY state > -- > > Key: CASSANDRA-19103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19103 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > In CASSANDRA-18935, what I did was that if transport is turned off while node > is up, it will set RPC_READY to "false". Before 18935 was in, if you turned > off transport, RPC_READY was not changed to true but it stayed to be "true" > for ever. > Clearly, this was wrong, so I fixed that, but when I did that, the code which > decides who will be the leader of counter mutation was broken, because that > node filtered out all nodes for which RPC_READY is false, which never > happened before, because nobody has set it to "false" on turned off transport. > So, we decided to revert this regression in 5.0-rc1 and I was waiting for > CEP-21 to be in because I saw it is rewritten there with TODO to filter > JOINED nodes. > Hence, we can decouple this logic and fix RPC_READY status finally. -- 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-19103) Filter replicas for counter mutation leader to be JOINED replicas to decouple from RPC_READY state
[ https://issues.apache.org/jira/browse/CASSANDRA-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19103: -- Description: In CASSANDRA-18935, what I did was that if transport is turned off while node is up, it will set RPC_READY to "false". Before 18935 was in, if you turned off transport while node was up and transport was on, RPC_READY was not changed to false but it stayed to be "true" for ever. Clearly, this was wrong, so I fixed that, but when I did that, the code which decides who will be the leader of counter mutation was broken, because that node filtered out all nodes for which RPC_READY is false, which never happened before, because nobody has set it to "false" on turned off transport. So, we decided to revert this regression in 5.0-rc1 and I was waiting for CEP-21 to be in because I saw it is rewritten there with TODO to filter JOINED nodes. Hence, we can decouple this logic and fix RPC_READY status finally. was: In CASSANDRA-18935, what I did was that if transport is turned off while node is up, it will set RPC_READY to "false". Before 18935 was in, if you turned off transport, RPC_READY was not changed to true but it stayed to be "true" for ever. Clearly, this was wrong, so I fixed that, but when I did that, the code which decides who will be the leader of counter mutation was broken, because that node filtered out all nodes for which RPC_READY is false, which never happened before, because nobody has set it to "false" on turned off transport. So, we decided to revert this regression in 5.0-rc1 and I was waiting for CEP-21 to be in because I saw it is rewritten there with TODO to filter JOINED nodes. Hence, we can decouple this logic and fix RPC_READY status finally. > Filter replicas for counter mutation leader to be JOINED replicas to decouple > from RPC_READY state > -- > > Key: CASSANDRA-19103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19103 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > In CASSANDRA-18935, what I did was that if transport is turned off while node > is up, it will set RPC_READY to "false". Before 18935 was in, if you turned > off transport while node was up and transport was on, RPC_READY was not > changed to false but it stayed to be "true" for ever. > Clearly, this was wrong, so I fixed that, but when I did that, the code which > decides who will be the leader of counter mutation was broken, because that > node filtered out all nodes for which RPC_READY is false, which never > happened before, because nobody has set it to "false" on turned off transport. > So, we decided to revert this regression in 5.0-rc1 and I was waiting for > CEP-21 to be in because I saw it is rewritten there with TODO to filter > JOINED nodes. > Hence, we can decouple this logic and fix RPC_READY status finally. -- 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-18753) Add an optimized default configuration to tests and make it available for new users
[
https://issues.apache.org/jira/browse/CASSANDRA-18753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Branimir Lambov updated CASSANDRA-18753:
Fix Version/s: 5.0-rc
(was: 5.0.x)
> Add an optimized default configuration to tests and make it available for new
> users
> ---
>
> Key: CASSANDRA-18753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18753
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Urgent
> Fix For: 5.0-rc, 5.x
>
> Attachments:
> CCM_Add_support_for_specifying_the_name_of_the_file_to_use_as_cassandra_YAML_.patch,
>
> DTEST_Add_support_for_specifying_the_name_of_the_file_to_use_as_cassandra_YAML_.patch
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> We currently offer only one sample configuration file with Cassandra, and
> that file is deliberately configured to disable all new functionality and
> incompatible improvements. This works well for legacy users that want to have
> a painless upgrade, but is a very bad choice for new users, or anyone wanting
> to make comparisons between Cassandra versions or between Cassandra and other
> databases.
> We offer very little indication, in the database packaging itself, that there
> are well-tested configuration choices that can solve known problems and
> dramatically improve performance. This is guaranteed to paint the database in
> a worse light than it deserves, and will very likely hurt adoption.
> We should find a way to offer a very easy way of choosing between "optimized"
> and "compatible" defaults. At minimal, we could provide alternate yaml files.
> Alternatively, we could build on the {{storage_compatibility_mode}} concept
> to grow it into a setting that not only enables/disables certain settings,
> but also changes their default values.
--
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-19085) In-jvm dtest RepairTest fails with storage_compatibility_mode: NONE
[
https://issues.apache.org/jira/browse/CASSANDRA-19085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Branimir Lambov updated CASSANDRA-19085:
Fix Version/s: 5.0-rc
> In-jvm dtest RepairTest fails with storage_compatibility_mode: NONE
> ---
>
> Key: CASSANDRA-19085
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19085
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Branimir Lambov
>Priority: Normal
> Fix For: 5.0-rc
>
>
> More precisely, when the {{MessagingService}} version to {{{}VERSION_50{}}},
> the test fails with an exception that appears to be a genuine problem:
> {code:java}
> junit.framework.AssertionFailedError: Exception found expected null, but
> was: at
> org.apache.cassandra.service.ActiveRepairService.lambda$prepareForRepair$2(ActiveRepairService.java:678)
> 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.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> 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)
> >
> at
> org.apache.cassandra.distributed.test.DistributedRepairUtils.lambda$assertParentRepairSuccess$4(DistributedRepairUtils.java:129)
> at
> org.apache.cassandra.distributed.test.DistributedRepairUtils.validateExistingParentRepair(DistributedRepairUtils.java:164)
> at
> org.apache.cassandra.distributed.test.DistributedRepairUtils.assertParentRepairSuccess(DistributedRepairUtils.java:124)
> at
> org.apache.cassandra.distributed.test.RepairTest.testForcedNormalRepairWithOneNodeDown(RepairTest.java:211)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> org.apache.cassandra.distributed.shared.ShutdownException: Uncaught
> exceptions were thrown during test
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:1117)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1103)
> at
> org.apache.cassandra.distributed.test.RepairTest.closeCluster(RepairTest.java:160)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Suppressed: java.lang.IllegalStateException: complete already:
> (failure: java.lang.RuntimeException: Did not get replies from all endpoints.)
> at
> org.apache.cassandra.utils.concurrent.AsyncPromise.setSuccess(AsyncPromise.java:106)
> at
> org.apache.cassandra.service.ActiveRepairService$2.ack(ActiveRepairService.java:721)
> at
> org.apache.cassandra.service.ActiveRepairService$2.onResponse(ActiveRepairService.java:697)
> at
> org.apache.cassandra.repair.messages.RepairMessage$2.onResponse(RepairMessage.java:187)
> at
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:58)
> at
> org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
> at
> org.apache.cassandra.net.InboundSink$Filtered.accept(InboundSink.java:64)
> at
> org.apache.cassandra.net.InboundSink$Filtered.accept(InboundSink.java:50)
> at
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
> at
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:430)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable
[jira] [Updated] (CASSANDRA-19046) Paxos V2 does not update individual fields of readMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremiah Jordan updated CASSANDRA-19046:
Fix Version/s: 5.0-rc
> Paxos V2 does not update individual fields of readMetrics
> -
>
> Key: CASSANDRA-19046
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19046
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions, Observability/Metrics
>Reporter: Branimir Lambov
>Priority: Normal
> Fix For: 5.0-rc
>
>
> As a result, {{ClientMetricsTest.testPaxosStatement}} is failing with
> {{paxos_variant: v2}}.
--
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-18935) Fix nodetool enable/disablebinary to correctly set rpc
[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790174#comment-17790174
]
Runtian Liu commented on CASSANDRA-18935:
-
[~brandon.williams] the reason why test_counter_leader_with_partial_view didn't
fail before and still does not fail currently is because "nodetool
disablebinary" is not called in the test. The test is only restarting a node
and delay update status of other nodes' views for that node. I would say the
test is currently useful but it won't cover the case when modifying binary port
with nodetool commands.
> Fix nodetool enable/disablebinary to correctly set rpc
> --
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: 18935-3.11.patch, image-2023-11-16-10-56-16-693.png,
> signature.asc
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
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-18935) Fix nodetool enable/disablebinary to correctly set rpc
[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790177#comment-17790177
]
Brandon Williams commented on CASSANDRA-18935:
--
I see, thanks. NativeProtocolTest will cover it in Stefan's patch, so I think
we good to go here.
> Fix nodetool enable/disablebinary to correctly set rpc
> --
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: 18935-3.11.patch, image-2023-11-16-10-56-16-693.png,
> signature.asc
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
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-18935) Fix nodetool enable/disablebinary to correctly set rpc
[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790177#comment-17790177
]
Brandon Williams edited comment on CASSANDRA-18935 at 11/27/23 4:54 PM:
I see, thanks. NativeProtocolTest will cover it in Stefan's patch, so I think
we're good to go here.
was (Author: brandon.williams):
I see, thanks. NativeProtocolTest will cover it in Stefan's patch, so I think
we good to go here.
> Fix nodetool enable/disablebinary to correctly set rpc
> --
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: 18935-3.11.patch, image-2023-11-16-10-56-16-693.png,
> signature.asc
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
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-19104) Standardize data units and formatting used in tablestats
Brad Schoening created CASSANDRA-19104: -- Summary: Standardize data units and formatting used in tablestats Key: CASSANDRA-19104 URL: https://issues.apache.org/jira/browse/CASSANDRA-19104 Project: Cassandra Issue Type: Bug Components: Tool/nodetool Reporter: Brad Schoening Tablestats reports output in plaintext, JSON or YAML. The plaintext output currently has a mix of KiB, bytes with inconsistent spacing !image-2023-11-27-13-49-14-247.png! -- 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-19032) StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey
[ https://issues.apache.org/jira/browse/CASSANDRA-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19032: Reviewers: Caleb Rackliffe, Caleb Rackliffe Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Status: Review In Progress (was: Patch Available) > StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey > - > > Key: CASSANDRA-19032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19032 > Project: Cassandra > Issue Type: Bug > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0-rc > > Time Spent: 20m > Remaining Estimate: 0h > > The StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding has been > showing flakiness in test runs and need investigating and fixing. Looking at > the failure is seems that there is an edge condition where the index will > fail to complete its build if a table truncate is triggered at the right > moment. > We need to try and provoke this edge condition using injection and then see > what can be done to fix the build failure. -- 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-19011) Harry-found exception in during SAI query
[
https://issues.apache.org/jira/browse/CASSANDRA-19011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790202#comment-17790202
]
Mike Adamson commented on CASSANDRA-19011:
--
[~ifesdjeen] Did you manage to isolate a reproduction for this issue? It's not
an easy one to reproduce but I will keep trying.
> Harry-found exception in during SAI query
> -
>
> Key: CASSANDRA-19011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19011
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Alex Petrov
>Assignee: Mike Adamson
>Priority: Normal
> Fix For: 5.0-rc
>
>
> Schema:
> {code:java}
> CREATE TABLE IF NOT EXISTS distributed_test_keyspace.tbl1 (pk1 bigint,ck1
> bigint,v1 ascii,v2 bigint, PRIMARY KEY (pk1, ck1)) WITH CLUSTERING ORDER BY
> (ck1 ASC);
> CREATE CUSTOM INDEX v1_sai_idx ON distributed_test_keyspace.tbl1 (v1) USING
> 'StorageAttachedIndex' WITH OPTIONS = {'case_sensitive': 'false',
> 'normalize': 'true', 'ascii': 'true'}; ;
> CREATE CUSTOM INDEX v2_sai_idx ON distributed_test_keyspace.tbl1 (v2) USING
> 'StorageAttachedIndex';
> {code}
> {code:java}
> java.lang.AssertionError: skipped to an item smaller than the target;
> iterator:
> org.apache.cassandra.index.sai.disk.IndexSearchResultIterator@f399f79, target
> key: PrimaryKey: { token: 8384965201802291970, partition:
> DecoratedKey(8384965201802291970, c4bc1c50f9e76a50), clustering:
> CLUSTERING:8b4b4c5991a4ea10 } , returned key: PrimaryKey: { token:
> 8384965201802291970, partition: DecoratedKey(8384965201802291970,
> c4bc1c50f9e76a50), clustering: CLUSTERING:89f1cf92658cb668 }
> at
> org.apache.cassandra.index.sai.iterators.KeyRangeIntersectionIterator.computeNext(KeyRangeIntersectionIterator.java:95)
> at
> org.apache.cassandra.index.sai.iterators.KeyRangeIntersectionIterator.computeNext(KeyRangeIntersectionIterator.java:39)
> at
> org.apache.cassandra.utils.AbstractGuavaIterator.tryToComputeNext(AbstractGuavaIterator.java:122)
> at
> org.apache.cassandra.index.sai.iterators.KeyRangeIterator.tryToComputeNext(KeyRangeIterator.java:129)
> at
> org.apache.cassandra.utils.AbstractGuavaIterator.hasNext(AbstractGuavaIterator.java:116)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextKey(StorageAttachedIndexSearcher.java:274)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextKeyInRange(StorageAttachedIndexSearcher.java:203)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextSelectedKeyInRange(StorageAttachedIndexSearcher.java:234)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.nextRowIterator(StorageAttachedIndexSearcher.java:188)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.computeNext(StorageAttachedIndexSearcher.java:169)
> at
> org.apache.cassandra.index.sai.plan.StorageAttachedIndexSearcher$ResultRetriever.computeNext(StorageAttachedIndexSearcher.java:111)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:91)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:338)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:201)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:186)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:346)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2186)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2581)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
> relocated.shaded.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
>
> Unfortunately, there's no tooling for shrinking around SAI just yet, but I
> have a programmatic repro using INSERT and DELETE statements. I will do my
> best to post it asap, but thought this can already be useful for visibility.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: co
[jira] [Updated] (CASSANDRA-19054) WEBSITE - Add Cassandra Catalyst page and blog
[ https://issues.apache.org/jira/browse/CASSANDRA-19054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-19054: --- Labels: pull-request-available (was: ) > WEBSITE - Add Cassandra Catalyst page and blog > -- > > Key: CASSANDRA-19054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19054 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog, Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with creating a new page for > the Cassandra Catalyst program and it's associated blog. > > Preferably, the blog and page are live as of *November 27.* Please contact > me, suggest changes, or correct the date when possible in the pull request > for the appropriate time that the blog will go live (on both the blog.adoc > and the blog post's file). -- 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-19054) WEBSITE - Add Cassandra Catalyst page and blog
[ https://issues.apache.org/jira/browse/CASSANDRA-19054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-19054: - Change Category: Semantic Complexity: Normal Status: Open (was: Triage Needed) https://github.com/apache/cassandra-website/pull/257 > WEBSITE - Add Cassandra Catalyst page and blog > -- > > Key: CASSANDRA-19054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19054 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog, Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with creating a new page for > the Cassandra Catalyst program and it's associated blog. > > Preferably, the blog and page are live as of *November 27.* Please contact > me, suggest changes, or correct the date when possible in the pull request > for the appropriate time that the blog will go live (on both the blog.adoc > and the blog post's file). -- 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 cep-15-accord updated: Ninja for CASSANDRA-19045: make sure to use https rather than git@ for submodule so its portable
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch cep-15-accord in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cep-15-accord by this push: new 99fc9e28cc Ninja for CASSANDRA-19045: make sure to use https rather than git@ for submodule so its portable 99fc9e28cc is described below commit 99fc9e28cc6b91a3f500715efeafc77f4d19f306 Author: David Capwell AuthorDate: Mon Nov 27 10:32:35 2023 -0800 Ninja for CASSANDRA-19045: make sure to use https rather than git@ for submodule so its portable --- .gitmodules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitmodules b/.gitmodules index c85d47c922..616dacf610 100644 --- a/.gitmodules +++ b/.gitmodules @@ -1,4 +1,4 @@ [submodule "modules/accord"] path = modules/accord - url = g...@github.com:apache/cassandra-accord + url = https://github.com/apache/cassandra-accord.git branch = trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19054) WEBSITE - Add Cassandra Catalyst page and blog
[ https://issues.apache.org/jira/browse/CASSANDRA-19054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-19054: - Authors: Paul Au Impacts: Docs (was: None) Test and Documentation Plan: * Add Cassandra Catalyst landing page Add Cassandra Catalyst blog * Modify blog index * Update main nav with landing page button * Add image for main nav button Status: Patch Available (was: Open) > WEBSITE - Add Cassandra Catalyst page and blog > -- > > Key: CASSANDRA-19054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19054 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog, Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with creating a new page for > the Cassandra Catalyst program and it's associated blog. > > Preferably, the blog and page are live as of *November 27.* Please contact > me, suggest changes, or correct the date when possible in the pull request > for the appropriate time that the blog will go live (on both the blog.adoc > and the blog post's file). -- 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-19015) Nodetool 'tablestats' formatting uses inconsistent significant digits
[ https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790211#comment-17790211 ] Brad Schoening commented on CASSANDRA-19015: Created https://issues.apache.org/jira/browse/CASSANDRA-19104 > Nodetool 'tablestats' formatting uses inconsistent significant digits > - > > Key: CASSANDRA-19015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19015 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: CASSANDRA-19015-1.txt, CASSANDRA-19015-2.txt, > CASSANDRA-19015-3.txt, CASSANDRA-19015.txt, > image-2023-11-27-13-36-39-282.png, image-2023-11-27-13-49-14-247.png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant > digits. Ratios use five or sixteen decimal places. Averages use 1 or 13 > decimal places. > * milliseconds should use 3 decimal places > * ratios should use 3 decimal places (tenths of a percent) > * averages should use 1 or 2 > For readability, it would be helpful if large integers had comma separators. > I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear > if the exact disk size is somehow useful, as it may change minute-by-minute, > if not, rounding would be best, or displaying both Space used (live): > 1,463,210,998,523 (1,463GiB) > Total number of tables: 83 > > Keyspace : X > Read Count: 1007337271 > Read Latency: 8.485891803649942 ms > Write Count: 67550181 > Write Latency: 0.02556443163342523 ms > Pending Flushes: 0 > Table: Y > SSTable count: 7183 > Old SSTable count: 0 > SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0] > Space used (live): 1463210998523 > Space used (total): 1463210998523 > Space used by snapshots (total): 0 > Off heap memory used (total): 607419608 > SSTable Compression Ratio: 0.3146620992793412 > Number of partitions (estimate): 24784137 > Memtable cell count: 106067 > Memtable data size: 248539982 > Memtable off heap memory used: 0 > Memtable switch count: 256 > Local read count: 865440924 > Local read latency: 6.857 ms > Local write count: 13881409 > Local write latency: 0.037 ms > Pending flushes: 0 > Percent repaired: 0.0 > Bytes repaired: 0.000KiB > Bytes unrepaired: 4315.386GiB > Bytes pending repair: 0.000KiB > Bloom filter false positives: 11027855 > Bloom filter false ratio: 0.01099 > Bloom filter space used: 33590024 > Bloom filter off heap memory used: 33532560 > Index summary off heap memory used: 8174024 > Compression metadata off heap memory used: 565713024 > Compacted partition minimum bytes: 36 > Compacted partition maximum bytes: 17797419593 > Compacted partition mean bytes: 189740 > Average live cells per slice (last five minutes): 1443.2146104466253 > Maximum live cells per slice (last five minutes): 105778 > Average tombstones per slice (last five minutes): 1.0 > Maximum tombstones per slice (last five minutes): 1 > Dropped Mutations: 0 > Droppable tombstone ratio: 0.0 -- 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-19104) Standardize tablestats formatting and data units
[ https://issues.apache.org/jira/browse/CASSANDRA-19104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19104: --- Summary: Standardize tablestats formatting and data units (was: Standardize data units and formatting used in tablestats ) > Standardize tablestats formatting and data units > > > Key: CASSANDRA-19104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19104 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Brad Schoening >Priority: Normal > > Tablestats reports output in plaintext, JSON or YAML. The plaintext output > currently has a mix of KiB, bytes with inconsistent spacing > > !image-2023-11-27-13-49-14-247.png! -- 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-19104) Standardize tablestats formatting and data units
[ https://issues.apache.org/jira/browse/CASSANDRA-19104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19104: --- Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Discovered By: Adhoc Test Severity: Low Status: Open (was: Triage Needed) > Standardize tablestats formatting and data units > > > Key: CASSANDRA-19104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19104 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Brad Schoening >Priority: Normal > > Tablestats reports output in plaintext, JSON or YAML. The plaintext output > currently has a mix of KiB, bytes with inconsistent spacing > > !image-2023-11-27-13-49-14-247.png! -- 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-19054) WEBSITE - Add Cassandra Catalyst page and blog
[ https://issues.apache.org/jira/browse/CASSANDRA-19054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-19054: - Attachment: raw.githack.com_Paul-TT_cassandra-website_CASSANDRA-19054_generated_content___blog_Introducing-the-Apache-Cassandra-Catalyst-Program.html.png raw.githack.com_Paul-TT_cassandra-website_CASSANDRA-19054_generated_content___cassandra-catalyst-program.html.png > WEBSITE - Add Cassandra Catalyst page and blog > -- > > Key: CASSANDRA-19054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19054 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog, Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Attachments: > raw.githack.com_Paul-TT_cassandra-website_CASSANDRA-19054_generated_content___blog_Introducing-the-Apache-Cassandra-Catalyst-Program.html.png, > > raw.githack.com_Paul-TT_cassandra-website_CASSANDRA-19054_generated_content___cassandra-catalyst-program.html.png > > > This ticket is to capture the work associated with creating a new page for > the Cassandra Catalyst program and it's associated blog. > > Preferably, the blog and page are live as of *November 27.* Please contact > me, suggest changes, or correct the date when possible in the pull request > for the appropriate time that the blog will go live (on both the blog.adoc > and the blog post's file). -- 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-19104) Standardize tablestats formatting and data units
[ https://issues.apache.org/jira/browse/CASSANDRA-19104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19104: --- Description: Tablestats reports output in plaintext, JSON or YAML. The plaintext output currently has a mix of KiB, bytes with inconsistent spacing Considering simplifying and defaulting output to 'human readable'. Machine readable output is available as an option and the current mixed output formatting is neither friendly for human or machine reading. !image-2023-11-27-13-49-14-247.png! was: Tablestats reports output in plaintext, JSON or YAML. The plaintext output currently has a mix of KiB, bytes with inconsistent spacing !image-2023-11-27-13-49-14-247.png! > Standardize tablestats formatting and data units > > > Key: CASSANDRA-19104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19104 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Brad Schoening >Priority: Normal > > Tablestats reports output in plaintext, JSON or YAML. The plaintext output > currently has a mix of KiB, bytes with inconsistent spacing > Considering simplifying and defaulting output to 'human readable'. Machine > readable output is available as an option and the current mixed output > formatting is neither friendly for human or machine reading. > !image-2023-11-27-13-49-14-247.png! -- 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-19104) Standardize tablestats formatting and data units
[ https://issues.apache.org/jira/browse/CASSANDRA-19104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19104: --- Description: Tablestats reports output in plaintext, JSON or YAML. The human readable output currently has a mix of KiB, bytes with inconsistent spacing Considering simplifying and defaulting output to 'human readable'. Machine readable output is available as an option and the current mixed output formatting is neither friendly for human or machine reading. !image-2023-11-27-13-49-14-247.png! was: Tablestats reports output in plaintext, JSON or YAML. The plaintext output currently has a mix of KiB, bytes with inconsistent spacing Considering simplifying and defaulting output to 'human readable'. Machine readable output is available as an option and the current mixed output formatting is neither friendly for human or machine reading. !image-2023-11-27-13-49-14-247.png! > Standardize tablestats formatting and data units > > > Key: CASSANDRA-19104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19104 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Brad Schoening >Priority: Normal > > Tablestats reports output in plaintext, JSON or YAML. The human readable > output currently has a mix of KiB, bytes with inconsistent spacing > Considering simplifying and defaulting output to 'human readable'. Machine > readable output is available as an option and the current mixed output > formatting is neither friendly for human or machine reading. > !image-2023-11-27-13-49-14-247.png! -- 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-19032) StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey
[ https://issues.apache.org/jira/browse/CASSANDRA-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19032: --- Reviewers: Caleb Rackliffe, Michael Semb Wever (was: Caleb Rackliffe) > StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey > - > > Key: CASSANDRA-19032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19032 > Project: Cassandra > Issue Type: Bug > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0-rc > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding has been > showing flakiness in test runs and need investigating and fixing. Looking at > the failure is seems that there is an edge condition where the index will > fail to complete its build if a table truncate is triggered at the right > moment. > We need to try and provoke this edge condition using injection and then see > what can be done to fix the build failure. -- 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-19054) WEBSITE - Add Cassandra Catalyst page and blog
[ https://issues.apache.org/jira/browse/CASSANDRA-19054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-19054: - Attachment: blogindex.png navicon.png > WEBSITE - Add Cassandra Catalyst page and blog > -- > > Key: CASSANDRA-19054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19054 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog, Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Attachments: blogindex.png, navicon.png, > raw.githack.com_Paul-TT_cassandra-website_CASSANDRA-19054_generated_content___blog_Introducing-the-Apache-Cassandra-Catalyst-Program.html.png, > > raw.githack.com_Paul-TT_cassandra-website_CASSANDRA-19054_generated_content___cassandra-catalyst-program.html.png > > > This ticket is to capture the work associated with creating a new page for > the Cassandra Catalyst program and it's associated blog. > > Preferably, the blog and page are live as of *November 27.* Please contact > me, suggest changes, or correct the date when possible in the pull request > for the appropriate time that the blog will go live (on both the blog.adoc > and the blog post's file). -- 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-19054) WEBSITE - Add Cassandra Catalyst page and blog
[ https://issues.apache.org/jira/browse/CASSANDRA-19054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790219#comment-17790219 ] Diogenese Topper commented on CASSANDRA-19054: -- Preview here: [https://raw.githack.com/Paul-TT/cassandra-website/CASSANDRA-19054_generated/content/_/blog/Introducing-the-Apache-Cassandra-Catalyst-Program.html] [https://raw.githack.com/Paul-TT/cassandra-website/CASSANDRA-19054_generated/content/_/blog.html] [https://raw.githack.com/Paul-TT/cassandra-website/CASSANDRA-19054_generated/content/_/cassandra-catalyst-program.html] !raw.githack.com_Paul-TT_cassandra-website_CASSANDRA-19054_generated_content___blog_Introducing-the-Apache-Cassandra-Catalyst-Program.html.png!!raw.githack.com_Paul-TT_cassandra-website_CASSANDRA-19054_generated_content___cassandra-catalyst-program.html.png!!blogindex.png!!navicon.png! > WEBSITE - Add Cassandra Catalyst page and blog > -- > > Key: CASSANDRA-19054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19054 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog, Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Attachments: blogindex.png, navicon.png, > raw.githack.com_Paul-TT_cassandra-website_CASSANDRA-19054_generated_content___blog_Introducing-the-Apache-Cassandra-Catalyst-Program.html.png, > > raw.githack.com_Paul-TT_cassandra-website_CASSANDRA-19054_generated_content___cassandra-catalyst-program.html.png > > > This ticket is to capture the work associated with creating a new page for > the Cassandra Catalyst program and it's associated blog. > > Preferably, the blog and page are live as of *November 27.* Please contact > me, suggest changes, or correct the date when possible in the pull request > for the appropriate time that the blog will go live (on both the blog.adoc > and the blog post's file). -- 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-19104) Standardize tablestats formatting and data units
[ https://issues.apache.org/jira/browse/CASSANDRA-19104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leo Toff reassigned CASSANDRA-19104: Assignee: Leo Toff > Standardize tablestats formatting and data units > > > Key: CASSANDRA-19104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19104 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Leo Toff >Priority: Normal > > Tablestats reports output in plaintext, JSON or YAML. The human readable > output currently has a mix of KiB, bytes with inconsistent spacing > Considering simplifying and defaulting output to 'human readable'. Machine > readable output is available as an option and the current mixed output > formatting is neither friendly for human or machine reading. > !image-2023-11-27-13-49-14-247.png! -- 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-18806) create README.md for cassandra-accord subproject
[ https://issues.apache.org/jira/browse/CASSANDRA-18806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leo Toff updated CASSANDRA-18806: - Attachment: CASSANDRA-18806-2.txt > create README.md for cassandra-accord subproject > > > Key: CASSANDRA-18806 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18806 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Ling Mao >Assignee: Leo Toff >Priority: Normal > Fix For: 5.x > > Attachments: CASSANDRA-18806-1.txt, CASSANDRA-18806-2.txt, > CASSANDRA-18806.txt > > > We should add more descriptions to the cassandra-accord subproject, such as > following: > 1. how to build and run the source code with gradle > 2. how the codes are organized > 3. explain the protocal in a more understanding way -- 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-18806) create README.md for cassandra-accord subproject
[ https://issues.apache.org/jira/browse/CASSANDRA-18806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leo Toff updated CASSANDRA-18806: - Test and Documentation Plan: Instructions in README.md are correct and descriptive. [^CASSANDRA-18806-2.txt] was: Instructions in README.md are correct and descriptive. [^CASSANDRA-18806-1.txt] > create README.md for cassandra-accord subproject > > > Key: CASSANDRA-18806 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18806 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Ling Mao >Assignee: Leo Toff >Priority: Normal > Fix For: 5.x > > Attachments: CASSANDRA-18806-1.txt, CASSANDRA-18806-2.txt, > CASSANDRA-18806.txt > > > We should add more descriptions to the cassandra-accord subproject, such as > following: > 1. how to build and run the source code with gradle > 2. how the codes are organized > 3. explain the protocal in a more understanding way -- 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 cep-15-accord updated (99fc9e28cc -> 8645cf49af)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch cep-15-accord in repository https://gitbox.apache.org/repos/asf/cassandra.git from 99fc9e28cc Ninja for CASSANDRA-19045: make sure to use https rather than git@ for submodule so its portable add 8645cf49af Ninja for CASSANDRA-19045: use the latest sha from trunk rather than an old one from 10 months ago No new revisions were added by this update. Summary of changes: modules/accord | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18947) Test failure: dtest-novnode.disk_balance_test.TestDiskBalance.test_disk_balance_stress
[
https://issues.apache.org/jira/browse/CASSANDRA-18947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18947:
---
Reviewers: Michael Semb Wever, Michael Semb Wever
Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever)
Status: Review In Progress (was: Patch Available)
> Test failure:
> dtest-novnode.disk_balance_test.TestDiskBalance.test_disk_balance_stress
> --
>
> Key: CASSANDRA-18947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18947
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc
>
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/72/testReport/dtest-novnode.disk_balance_test/TestDiskBalance/test_disk_balance_stress/
> h3.
> {code:java}
> Error Message
> AssertionError: values not within 10.00% of the max: (2534183, 2762123,
> 2423706) (node1)
> Stacktrace
> self = def
> test_disk_balance_stress(self): cluster = self.cluster if
> self.dtest_config.use_vnodes:
> cluster.set_configuration_options(values={'num_tokens': 256})
> cluster.populate(4).start() node1 = cluster.nodes['node1']
> node1.stress(['write', 'n=50k', 'no-warmup', '-rate', 'threads=100',
> '-schema', 'replication(factor=3)',
> 'compaction(strategy=SizeTieredCompactionStrategy,enabled=false)'])
> cluster.flush() # make sure the data directories are balanced: for node in
> cluster.nodelist(): > self.assert_balanced(node) disk_balance_test.py:48: _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> disk_balance_test.py:186: in assert_balanced assert_almost_equal(*new_sums,
> error=0.1, error_message=node.name) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ args = (2534183, 2762123, 2423706)
> kwargs = {'error': 0.1, 'error_message': 'node1'}, error = 0.1, vmax =
> 2762123 vmin = 2423706, error_message = 'node1' def
> assert_almost_equal(*args, **kwargs): """ Assert variable number of arguments
> all fall within a margin of error. @params *args variable number of numerical
> arguments to check @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default '' Examples:
> assert_almost_equal(sizes[2], init_size) assert_almost_equal(ttl_session1,
> ttl_session2[0][0], error=0.005) """ error = kwargs['error'] if 'error' in
> kwargs else 0.16 vmax = max(args) vmin = min(args) error_message = '' if
> 'error_message' not in kwargs else kwargs['error_message'] assert vmin > vmax
> * (1.0 - error) or vmin == vmax, \ > "values not within {:.2f}% of the max:
> {} ({})".format(error * 100, args, error_message) E AssertionError: values
> not within 10.00% of the max: (2534183, 2762123, 2423706) (node1)
> tools/assertions.py:206: AssertionError
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18947) Test failure: dtest-novnode.disk_balance_test.TestDiskBalance.test_disk_balance_stress
[
https://issues.apache.org/jira/browse/CASSANDRA-18947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790233#comment-17790233
]
Michael Semb Wever commented on CASSANDRA-18947:
CI
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/263/workflows/349a08b5-5323-4632-bff7-d40c0de10380
> Test failure:
> dtest-novnode.disk_balance_test.TestDiskBalance.test_disk_balance_stress
> --
>
> Key: CASSANDRA-18947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18947
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc
>
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/72/testReport/dtest-novnode.disk_balance_test/TestDiskBalance/test_disk_balance_stress/
> h3.
> {code:java}
> Error Message
> AssertionError: values not within 10.00% of the max: (2534183, 2762123,
> 2423706) (node1)
> Stacktrace
> self = def
> test_disk_balance_stress(self): cluster = self.cluster if
> self.dtest_config.use_vnodes:
> cluster.set_configuration_options(values={'num_tokens': 256})
> cluster.populate(4).start() node1 = cluster.nodes['node1']
> node1.stress(['write', 'n=50k', 'no-warmup', '-rate', 'threads=100',
> '-schema', 'replication(factor=3)',
> 'compaction(strategy=SizeTieredCompactionStrategy,enabled=false)'])
> cluster.flush() # make sure the data directories are balanced: for node in
> cluster.nodelist(): > self.assert_balanced(node) disk_balance_test.py:48: _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> disk_balance_test.py:186: in assert_balanced assert_almost_equal(*new_sums,
> error=0.1, error_message=node.name) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ args = (2534183, 2762123, 2423706)
> kwargs = {'error': 0.1, 'error_message': 'node1'}, error = 0.1, vmax =
> 2762123 vmin = 2423706, error_message = 'node1' def
> assert_almost_equal(*args, **kwargs): """ Assert variable number of arguments
> all fall within a margin of error. @params *args variable number of numerical
> arguments to check @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default '' Examples:
> assert_almost_equal(sizes[2], init_size) assert_almost_equal(ttl_session1,
> ttl_session2[0][0], error=0.005) """ error = kwargs['error'] if 'error' in
> kwargs else 0.16 vmax = max(args) vmin = min(args) error_message = '' if
> 'error_message' not in kwargs else kwargs['error_message'] assert vmin > vmax
> * (1.0 - error) or vmin == vmax, \ > "values not within {:.2f}% of the max:
> {} ({})".format(error * 100, args, error_message) E AssertionError: values
> not within 10.00% of the max: (2534183, 2762123, 2423706) (node1)
> tools/assertions.py:206: AssertionError
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19032) StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey
[ https://issues.apache.org/jira/browse/CASSANDRA-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790245#comment-17790245 ] Caleb Rackliffe commented on CASSANDRA-19032: - +1, assuming we can resolve the outstanding [logging conversation|https://github.com/apache/cassandra/pull/2932#discussion_r1406610291] in the PR > StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey > - > > Key: CASSANDRA-19032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19032 > Project: Cassandra > Issue Type: Bug > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0-rc > > Time Spent: 1.5h > Remaining Estimate: 0h > > The StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding has been > showing flakiness in test runs and need investigating and fixing. Looking at > the failure is seems that there is an edge condition where the index will > fail to complete its build if a table truncate is triggered at the right > moment. > We need to try and provoke this edge condition using injection and then see > what can be done to fix the build failure. -- 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-19105) Capture in CQLSH with Tracing on saves the trace results
Brad Schoening created CASSANDRA-19105:
--
Summary: Capture in CQLSH with Tracing on saves the trace results
Key: CASSANDRA-19105
URL: https://issues.apache.org/jira/browse/CASSANDRA-19105
Project: Cassandra
Issue Type: Bug
Components: CQL/Interpreter
Reporter: Brad Schoening
When using *Tracing* in CQLSH, it's sometimes helpful to use *Capture* to avoid
paging through output when you want to see the trace results. However, the
trace results are also capture to the output file.
According to *Help Capture* (below), only the query result should be saved. The
correct behavior should probably be to display the trace results and only
capture the query results.
{{ Only query result output is captured. Errors and output from cqlsh-only
commands will still be shown in the cqlsh session.}}
--
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-18330) Delivery of CEP-21: Transactional Cluster Metadata
[ https://issues.apache.org/jira/browse/CASSANDRA-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-18330: Attachment: ci_summary.html result_details.tar.gz > Delivery of CEP-21: Transactional Cluster Metadata > -- > > Key: CASSANDRA-18330 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18330 > Project: Cassandra > Issue Type: Epic > Components: Cluster/Membership, Cluster/Schema >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 5.x > > Attachments: ci_summary.html, result_details.tar.gz > > -- 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-18330) Delivery of CEP-21: Transactional Cluster Metadata
[
https://issues.apache.org/jira/browse/CASSANDRA-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790257#comment-17790257
]
Sam Tunnicliffe commented on CASSANDRA-18330:
-
Attached CI summary and result details for {{cep-21-tcm}}
> Delivery of CEP-21: Transactional Cluster Metadata
> --
>
> Key: CASSANDRA-18330
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18330
> Project: Cassandra
> Issue Type: Epic
> Components: Cluster/Membership, Cluster/Schema
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html, result_details.tar.gz
>
>
--
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-19050) Enhanced usage of test method names in CQLTester for better test debugging
[
https://issues.apache.org/jira/browse/CASSANDRA-19050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19050:
---
Reviewers: Michael Semb Wever
Status: Review In Progress (was: Patch Available)
> Enhanced usage of test method names in CQLTester for better test debugging
> --
>
> Key: CASSANDRA-19050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19050
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> All views, tables, ks,... created in CQLTester are of the form {{table_00}}:
> - While debugging tests and flakies this makes it really hard to match logs
> to test methods.
> - Some async operations can spill log lines from a previous test method into
> the next's log lines which is incredibly confusing
> - It's hard on the eyes and easy to mix up
> - When comparing logs from 2 different branches, envs,... it's really hard to
> match logs
> The proposed solution is for {{CQLTester}} to decorate these with the test
> name.
--
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-19050) Enhanced usage of test method names in CQLTester for better test debugging
[
https://issues.apache.org/jira/browse/CASSANDRA-19050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19050:
---
Status: Ready to Commit (was: Review In Progress)
+1
> Enhanced usage of test method names in CQLTester for better test debugging
> --
>
> Key: CASSANDRA-19050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19050
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> All views, tables, ks,... created in CQLTester are of the form {{table_00}}:
> - While debugging tests and flakies this makes it really hard to match logs
> to test methods.
> - Some async operations can spill log lines from a previous test method into
> the next's log lines which is incredibly confusing
> - It's hard on the eyes and easy to mix up
> - When comparing logs from 2 different branches, envs,... it's really hard to
> match logs
> The proposed solution is for {{CQLTester}} to decorate these with the test
> name.
--
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-19032) StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey
[ https://issues.apache.org/jira/browse/CASSANDRA-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790262#comment-17790262 ] Michael Semb Wever commented on CASSANDRA-19032: +1 > StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding is flakey > - > > Key: CASSANDRA-19032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19032 > Project: Cassandra > Issue Type: Bug > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0-rc > > Time Spent: 1h 40m > Remaining Estimate: 0h > > The StorageAttachedIndexDDLTest.concurrentTruncateWithIndexBuilding has been > showing flakiness in test runs and need investigating and fixing. Looking at > the failure is seems that there is an edge condition where the index will > fail to complete its build if a table truncate is triggered at the right > moment. > We need to try and provoke this edge condition using injection and then see > what can be done to fix the build failure. -- 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 (a68cb1ef6 -> 06a53ce09)
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 a68cb1ef6 generate docs for 04cb904e new 06a53ce09 generate docs for 04cb904e 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 (a68cb1ef6) \ N -- N -- N refs/heads/asf-staging (06a53ce09) 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 4881597 -> 4881597 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] [Created] (CASSANDRA-19106) harry-core-0.0.2 vulnerability: CVE-2020-13946
Brandon Williams created CASSANDRA-19106: Summary: harry-core-0.0.2 vulnerability: CVE-2020-13946 Key: CASSANDRA-19106 URL: https://issues.apache.org/jira/browse/CASSANDRA-19106 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams https://nvd.nist.gov/vuln/detail/CVE-2020-13946 This is our own old CVE so we can probably suppress. -- 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-19106) harry-core-0.0.2 vulnerability: CVE-2020-13946
[ https://issues.apache.org/jira/browse/CASSANDRA-19106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19106: - Bug Category: Parent values: Security(12985) Complexity: Normal Component/s: Test/fuzz Discovered By: User Report Fix Version/s: 5.x Severity: Low Status: Open (was: Triage Needed) > harry-core-0.0.2 vulnerability: CVE-2020-13946 > -- > > Key: CASSANDRA-19106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19106 > Project: Cassandra > Issue Type: Bug > Components: Test/fuzz >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.x > > > https://nvd.nist.gov/vuln/detail/CVE-2020-13946 > This is our own old CVE so we can probably suppress. -- 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-18731) Add declarative root CI structure
[
https://issues.apache.org/jira/browse/CASSANDRA-18731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790270#comment-17790270
]
Josh McKenzie commented on CASSANDRA-18731:
---
{quote}Today, our 5.0+ requirements to the CI pre-commit pipeline are...
{quote}
I think we should revisit this on the dev ML; I don't fully agree w/what you've
outlined above and this is something we should discuss as a project community,
not mandate on a comment in a JIRA.
[~e.dimitrova] made the excellent point that as the JDK authors keep tightening
down what's allowed in terms of unsafe and reflection-based access, we're more
likely to see failures on the highest supported JDK version rather than the
lowest for example, meaning the python dtest suites and jvm-dtest-upgrade
should likely be calibrated to "highest supported and down", vs. "lowest
supported and up".
Further, I don't agree with (and we've discussed) the need to run test-cdc (or
it existing at all vs. it just being enabled for all tests), the compression,
oa, or trie suites as pre-commit smoke suites, etc. I have a strong belief that
we should expect very infrequent test failures on non-default configurations
vs. the base; that functionality is supposed to be API compatible and if it
works on one configuration, it works on all. While there will no doubt be
flakes, the amount of compute required to run all those pre-commit as a smoke
suite effectively removes the "smoke" aspect of it and just makes pre-commit a
vast majority of the cost of a full run.
Same for testing everything in no-vnode and vnode combination; that's so
terribly wasteful that I just can't agree with doing that for everything
pre-commit (in any env, circle, new, or ASF-CI). I would very much prefer we
take the approach you enumerated on the dev ML:
{quote}Can we get these tests temporarily annotated as skipped while all the
subtickets to 19055 are being worked on ?
{quote}
We have the current example of the TCM merge on CASSANDRA-19055 to immediately
inspect as to whether this approach is sufficient or not. With an _incredibly
large_ patch in the form of TCM (88k+ LoC, 900+ files touched), we have less
than a .002% test failure injection rate using the above restricted smoke
heuristic, and many of them look to be circle ci env specific and not asf ci.
(Of note - the artifact building bit definitely needs to be resolved; we should
consider extending an "artifact build only" target on ASF CI people can
parameterize with feature branches to make sure they haven't broken the various
builds?)
And for repeated runs, we discussed the fact that not having support for
repeated runs in ASF CI meant we also didn't want to put down a hard blocker on
requiring those runs on other pre-commit environments. Has your position
changed on that? Regardless, that's just a question of prioritization; it's
relatively trivial to finish up support for that if we deem it an immediate
priority.
> Add declarative root CI structure
> -
>
> Key: CASSANDRA-18731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18731
> Project: Cassandra
> Issue Type: Improvement
> Components: CI
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 5.x
>
>
> Currently we have a somewhat declarative structure in .circleci, however
> there's still quite a bit that's baked in (resource limitations, parallelism,
> which suites qualify for which pipelines (pre-commit vs. post-commit vs.
> ???), etc). Further, while CASSANDRA-18133 brings the build scripts in-tree,
> all these parameters (pipelines, env vars, job definitions, resource
> constraints) are all still scattered throughout the shell scripts and/or
> reliant on the {{JenkinsFile}} to determine what suites comprise what
> pipelines.
> This ticket aims to decouple the definition of pipelines and jobs for CI from
> the implementations themselves. The goal here is to define, establish, and
> test both the base config and some helper methods to provide _other_
> configurations (circle, ASF CI, etc) the tools they need to programmatically
> inherit base CI config from a purely declarative structure.
> Follow-up tickets will involve rewriting the in-tree build scripts and
> JenkinsFile generation to rely on this structure, as well as integrating the
> config parsing unit tests into our 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
[jira] [Created] (CASSANDRA-19107) Revert unnecessary read lock acquisition when reading ring version in TokenMetadata introduced in CASSANDRA-16286
Caleb Rackliffe created CASSANDRA-19107:
---
Summary: Revert unnecessary read lock acquisition when reading
ring version in TokenMetadata introduced in CASSANDRA-16286
Key: CASSANDRA-19107
URL: https://issues.apache.org/jira/browse/CASSANDRA-19107
Project: Cassandra
Issue Type: Improvement
Components: Legacy/Distributed Metadata
Reporter: Caleb Rackliffe
Assignee: Caleb Rackliffe
CASSANDRA-16286 achieved its goal of making sure that concurrent increments to
the ring version would independently increment the version (i.e. not "merge"
multiple invalidations into single versions), but it also unnecessarily
replaced the volatile read on {{ringVersion}} w/ making {{readVersion}}
non-volatile and acquiring the read lock on the fair {{ReadWriteLock}} in
{{TokenMetadata}}. This can result in unnecessary queueing w/ high CPU
usage/read volume. For example, you might see this on a 4.0 cluster...
{noformat}
"Native-Transport-Requests-99" #271 daemon prio=5 os_prio=0 cpu=5822566.56ms
elapsed=1949.40s tid=0x7fcc96c31b00 nid=0xb7bd waiting on condition
[0x7fcb7f144000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.16/Native Method)
- parking to wait for <0x0005c0ab92a0> (a
java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
at
java.util.concurrent.locks.LockSupport.park(java.base@11.0.16/LockSupport.java:194)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.16/AbstractQueuedSynchronizer.java:885)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1009)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11.0.16/AbstractQueuedSynchronizer.java:1324)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(java.base@11.0.16/ReentrantReadWriteLock.java:738)
at
org.apache.cassandra.locator.TokenMetadata.getRingVersion(TokenMetadata.java:1389)
at
org.apache.cassandra.locator.AbstractReplicationStrategy.getCachedReplicas(AbstractReplicationStrategy.java:82)
at
org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:116)
at
org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicasForToken(AbstractReplicationStrategy.java:109)
at
org.apache.cassandra.locator.ReplicaLayout.forTokenWriteLiveAndDown(ReplicaLayout.java:209)
at
org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:328)
at
org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1426)
at
org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:937)
{noformat}
Reverting to a volatile read makes this no longer possible, but keeps the fix
from CASSANDRA-16286 intact.
--
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
