[jira] [Comment Edited] (CASSANDRA-18098) Test failure bootstrap_test.py::test_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-18098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846429#comment-17846429
]
Brandon Williams edited comment on CASSANDRA-18098 at 5/14/24 8:32 PM:
---
>From the failure in CASSANDRA-15439:
{noformat}
19:25:25,570 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-19-big-Data.db
19:25:25,570 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-16-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-17-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-18-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-23-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data1/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-2-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data1/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-5-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data1/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-8-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data1/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-11-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data1/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-14-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-3-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-6-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-24-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-20-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-21-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-22-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-25-big-Data.db
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:24,329 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-13-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:24,545 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-7-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:24,682 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-10-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:24,841 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-4-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:24,965 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-15-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:25,140 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-9-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:25,286 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-12-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:25,429 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-1-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:25,576 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-6-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:25,661 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-3-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:25,840 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data1/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-14-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:26,039 BigFormat.java:231 -
Deleting sstable:
[jira] [Commented] (CASSANDRA-18098) Test failure bootstrap_test.py::test_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-18098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846429#comment-17846429
]
Brandon Williams commented on CASSANDRA-18098:
--
>From the failure in CASSANDRA-15439:
{noformat}
19:25:25,570 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-19-big-Data.db
19:25:25,570 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-16-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-17-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-18-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-23-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data1/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-2-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data1/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-5-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data1/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-8-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data1/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-11-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data1/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-14-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-3-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-6-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-24-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-20-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-21-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-22-big-Data.db
19:25:25,571 bootstrap_test ERROR
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-25-big-Data.db
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:24,329 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-13-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:24,545 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-7-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:24,682 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-10-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:24,841 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-4-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:24,965 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-15-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:25,140 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-9-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:25,286 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-12-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:25,429 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data0/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-1-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:25,576 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-6-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:25,661 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data2/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-3-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:25,840 BigFormat.java:231 -
Deleting sstable:
/tmp/dtest-fezk9v8f/test/node1/data1/keyspace1/standard1-3a213a10033911efaffa37bdbd08956d/nb-14-big
INFO [NonPeriodicTasks:1] 2024-04-25 19:25:26,039 BigFormat.java:231 -
Deleting sstable:
[jira] [Commented] (CASSANDRA-19601) Test failure: test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846366#comment-17846366
]
Brandon Williams commented on CASSANDRA-19601:
--
I thought in CASSANDRA-19471 that my last fix would solve this issue,
specifically:
bq. it needs to reset the batch mode options when it recreates the cluster for
the second run, otherwise the CL gets an asynchronous flush that breaks the
test again
This is the asynchronous flush I mentioned. Now that we are measuring right
before and after writing, this has to be the CL being written during the
write_to_trigger_fsync method. [~blambov] do you know why this would happen?
If it's expected I guess we can insert some sleep before we begin measuring,
but I hate adding sleep so I'd like to understand why it is needed.
> Test failure: test_change_durable_writes
>
>
> Key: CASSANDRA-19601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19601
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
>
> Failing on trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1880/testReport/junit/dtest-latest.configuration_test/TestConfiguration/Tests___dtest_latest_jdk11_31_64___test_change_durable_writes/]
> [https://app.circleci.com/pipelines/github/blerer/cassandra/400/workflows/893a0edb-9181-4981-b542-77228c8bc975/jobs/10941/tests]
> {code:java}
> AssertionError: Commitlog was written with durable writes disabled
> assert 90112 == 86016
> +90112
> -86016
> self =
> @pytest.mark.timeout(60*30)
> def test_change_durable_writes(self):
> """
> @jira_ticket CASSANDRA-9560
>
> Test that changes to the DURABLE_WRITES option on keyspaces is
> respected in subsequent writes.
>
> This test starts by writing a dataset to a cluster and asserting that
> the commitlogs have been written to. The subsequent test depends on
> the assumption that this dataset triggers an fsync.
>
> After checking this assumption, the test destroys the cluster and
> creates a fresh one. Then it tests that DURABLE_WRITES is respected
> by:
>
> - creating a keyspace with DURABLE_WRITES set to false,
> - using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
> - writing a dataset to this keyspace that is known to trigger a
> commitlog fsync,
> - asserting that the commitlog has grown in size since the data was
> written.
> """
> cluster = self.cluster
> cluster.set_batch_commitlog(enabled=True, use_batch_window =
> cluster.version() < '5.0')
>
> cluster.set_configuration_options(values={'commitlog_segment_size_in_mb': 1})
>
> cluster.populate(1).start()
> durable_node = cluster.nodelist()[0]
>
> durable_init_size = commitlog_size(durable_node)
> durable_session = self.patient_exclusive_cql_connection(durable_node)
>
> # test assumption that write_to_trigger_fsync actually triggers a
> commitlog fsync
> durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
> {'class': 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = true")
> durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
> int, b int, c int)')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
> write_to_trigger_fsync(durable_session, 'ks', 'tab')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
>
> assert commitlog_size(durable_node) > durable_init_size, \
> "This test will not work in this environment;
> write_to_trigger_fsync does not trigger fsync."
>
> durable_session.shutdown()
> cluster.stop()
> cluster.clear()
>
> cluster.set_batch_commitlog(enabled=True, use_batch_window =
> cluster.version() < '5.0')
>
> cluster.set_configuration_options(values={'commitlog_segment_size_in_mb': 1})
> cluster.start()
> node = cluster.nodelist()[0]
> session = self.patient_exclusive_cql_connection(node)
>
> # set up a keyspace without durable writes, then alter it to use them
> session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
> 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = false")
> session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
> int, c int)')
> init_size = commitlog_size(node)
> write_to_trigger_fsync(session,
[jira] [Updated] (CASSANDRA-19601) Test failure: test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19601:
-
Fix Version/s: 5.0.x
> Test failure: test_change_durable_writes
>
>
> Key: CASSANDRA-19601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19601
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> Failing on trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1880/testReport/junit/dtest-latest.configuration_test/TestConfiguration/Tests___dtest_latest_jdk11_31_64___test_change_durable_writes/]
> [https://app.circleci.com/pipelines/github/blerer/cassandra/400/workflows/893a0edb-9181-4981-b542-77228c8bc975/jobs/10941/tests]
> {code:java}
> AssertionError: Commitlog was written with durable writes disabled
> assert 90112 == 86016
> +90112
> -86016
> self =
> @pytest.mark.timeout(60*30)
> def test_change_durable_writes(self):
> """
> @jira_ticket CASSANDRA-9560
>
> Test that changes to the DURABLE_WRITES option on keyspaces is
> respected in subsequent writes.
>
> This test starts by writing a dataset to a cluster and asserting that
> the commitlogs have been written to. The subsequent test depends on
> the assumption that this dataset triggers an fsync.
>
> After checking this assumption, the test destroys the cluster and
> creates a fresh one. Then it tests that DURABLE_WRITES is respected
> by:
>
> - creating a keyspace with DURABLE_WRITES set to false,
> - using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
> - writing a dataset to this keyspace that is known to trigger a
> commitlog fsync,
> - asserting that the commitlog has grown in size since the data was
> written.
> """
> cluster = self.cluster
> cluster.set_batch_commitlog(enabled=True, use_batch_window =
> cluster.version() < '5.0')
>
> cluster.set_configuration_options(values={'commitlog_segment_size_in_mb': 1})
>
> cluster.populate(1).start()
> durable_node = cluster.nodelist()[0]
>
> durable_init_size = commitlog_size(durable_node)
> durable_session = self.patient_exclusive_cql_connection(durable_node)
>
> # test assumption that write_to_trigger_fsync actually triggers a
> commitlog fsync
> durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
> {'class': 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = true")
> durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
> int, b int, c int)')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
> write_to_trigger_fsync(durable_session, 'ks', 'tab')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
>
> assert commitlog_size(durable_node) > durable_init_size, \
> "This test will not work in this environment;
> write_to_trigger_fsync does not trigger fsync."
>
> durable_session.shutdown()
> cluster.stop()
> cluster.clear()
>
> cluster.set_batch_commitlog(enabled=True, use_batch_window =
> cluster.version() < '5.0')
>
> cluster.set_configuration_options(values={'commitlog_segment_size_in_mb': 1})
> cluster.start()
> node = cluster.nodelist()[0]
> session = self.patient_exclusive_cql_connection(node)
>
> # set up a keyspace without durable writes, then alter it to use them
> session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
> 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = false")
> session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
> int, c int)')
> init_size = commitlog_size(node)
> write_to_trigger_fsync(session, 'ks', 'tab')
> > assert commitlog_size(node) == init_size, "Commitlog was written with
> > durable writes disabled"
> E AssertionError: Commitlog was written with durable writes disabled
> E assert 90112 == 86016
> E +90112
> E -86016
> configuration_test.py:104: 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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846359#comment-17846359 ] Brandon Williams commented on CASSANDRA-19335: -- That's correct, but why both if you're going the json route in the end? > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846338#comment-17846338 ] Brandon Williams commented on CASSANDRA-19335: -- We can wrap the tests with if/else depending on version like [this random example|https://github.com/apache/cassandra-dtest/blob/trunk/bootstrap_test.py#L172], but I think updating them all to use json would be cleaner. > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19335: - Status: Changes Suggested (was: Review In Progress) > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846326#comment-17846326 ] Brandon Williams commented on CASSANDRA-19335: -- That is a very good point I hadn't considered, thanks for bringing it up. I think maybe we should go ahead with the parsing of json/yaml to get around this in all versions, then. [~zaaath] what do you think? > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-18098) Test failure bootstrap_test.py::test_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-18098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846322#comment-17846322
]
Brandon Williams commented on CASSANDRA-18098:
--
I have recently seen this failing a lot more often, but strangely it still does
not repro in isolation or the suite. I'll keep digging.
> Test failure bootstrap_test.py::test_cleanup
>
>
> Key: CASSANDRA-18098
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18098
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Yifan Cai
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 5.0.x, 5.x
>
>
> The test failed a few times in the recent CI runs. For example, this log
> captures a recent failure.
> {code:none}
> 20:02:01,364 ccm INFO node1: using Java 11 for the current invocation
> 20:02:02,679 bootstrap_test ERROR ---
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data0/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-1-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data0/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-4-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data0/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-7-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data0/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-10-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data0/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-13-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data1/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-2-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data1/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-5-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data1/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-8-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data1/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-11-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data1/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-14-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data2/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-3-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data2/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-6-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data2/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-9-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data2/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-12-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data2/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-15-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data2/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-16-big-Data.db
> 20:02:02,679 bootstrap_test ERROR
> /tmp/dtest-8kcle23s/test/node1/data2/keyspace1/standard1-e36da130727b11edb08827a767e354f3/nb-17-big-Data.db
> 20:02:02,679 bootstrap_test ERROR Current count is 17, basecount was 15
> -- generated xml file: /tmp/results/dtests/pytest_result_j11_with_vnodes.xml
> ---
> ===Flaky Test Report===
> test_materialized_views_auth passed 1 out of the required 1 times. Success!
> test_cleanup failed and was not selected for rerun.
>
> assert not True
> + where True = 0x7f071d43cba8>>()
> +where 0x7f071d43cba8>> = .is_set
> []
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19633) Replaced node is stuck in a loop calculating ranges
[
https://issues.apache.org/jira/browse/CASSANDRA-19633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19633:
-
Fix Version/s: 5.x
(was: 5.1-alpha1)
> Replaced node is stuck in a loop calculating ranges
> ---
>
> Key: CASSANDRA-19633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19633
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Jai Bheemsen Rao Dhanwada
>Assignee: Marcus Eriksson
>Priority: Normal
> Labels: Bootstrap
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: result1.html
>
>
> Hello,
>
> I am running into an issue where in a node that is replacing a dead
> (non-seed) node is stuck in calculating ranges forever. It eventually
> succeeds, however the time taken for calculating the ranges is not constant.
> I do sometimes see that it takes 24 hours to calculate ranges for each
> keyspace. Attached the flume graph of the cassandra process during this time,
> which points to the below code.
> {code:java}
> Multimap>
> getRangeFetchMapForNonTrivialRanges()
> {
> //Get the graph with edges between ranges and their source endpoints
> MutableCapacityGraph graph = getGraph();
> //Add source and destination vertex and edges
> addSourceAndDestination(graph, getDestinationLinkCapacity(graph));
> int flow = 0;
> MaximumFlowAlgorithmResult> result =
> null;
> //We might not be working on all ranges
> while (flow < getTotalRangeVertices(graph))
> {
> if (flow > 0)
> { //We could not find a path with previous graph. Bump the capacity b/w
> endpoint vertices and destination by 1 incrementCapacity(graph, 1); }
> MaximumFlowAlgorithm fordFulkerson =
> FordFulkersonAlgorithm.getInstance(DFSPathFinder.getInstance());
> result = fordFulkerson.calc(graph, sourceVertex, destinationVertex,
> IntegerNumberSystem.getInstance());
> int newFlow = result.calcTotalFlow();
> assert newFlow > flow; //We are not making progress which should not happen
> flow = newFlow;
> }
> return getRangeFetchMapFromGraphResult(graph, result);
> }
> {code}
> Digging through the logs, I see the below log line for a given keyspace
> `system_auth`
> {code:java}
> INFO [main] 2024-05-10 17:35:02,489 RangeStreamer.java:330 - Bootstrap: range
> Full(/10.135.56.214:7000,(5080189126057290696,5081324396311791613]) exists on
> Full(/10.135.56.157:7000,(5080189126057290696,5081324396311791613]) for
> keyspace system_auth{code}
> corresponding code:
> {code:java}
> for (Map.Entry entry : fetchMap.flattenEntries())
> logger.info("{}: range {} exists on {} for keyspace {}", description,
> entry.getKey(), entry.getValue(), keyspaceName);{code}
> BUT do not see the below line for the corresponding keyspace
> {code:java}
> RangeStreamer.java:606 - Output from RangeFetchMapCalculator for
> keyspace{code}
> this means the code it's stuck in `getRangeFetchMap();`
> {code:java}
> Multimap> rangeFetchMapMap =
> calculator.getRangeFetchMap();
> logger.info("Output from RangeFetchMapCalculator for keyspace {}",
> keyspace);{code}
> Here is the cluster topology:
> * Cassandra version: 4.0.12
> * # of nodes: 190
> * Tokens (vnodes): 128
> Initial hypothesis was that the graph calculation was taking longer due to
> the combination of nodes + tokens + tables but in the same cluster I see one
> of the node joined without any issues.
> wondering if I am hitting a bug causing it to work sometimes but get into an
> infinite loop some times?
> Please let me know if you need any other details and appreciate any pointers
> to debug this further.
--
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-19335) Default nodetool tablestats to Human-Readable Output
[
https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846271#comment-17846271
]
Brandon Williams commented on CASSANDRA-19335:
--
bq. Speaking of JSON/YAML, I had to force {{no-human-readable}} mode when the
{{--output}} flag is present
Nice catch. Maybe we should add some smoke tests for json/yaml.
bq. could you help me figure out what should be my next step here?
I think this ticket is basically done, it just needs another committer to
review. If you are referring to:
bq. dtests and CCM should start parsing the JSON/YAML output instead of plain
text
then that should probably be a new ticket.
> Default nodetool tablestats to Human-Readable Output
>
>
> Key: CASSANDRA-19335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19335
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Leo Toff
>Assignee: Leo Toff
>Priority: Low
> Fix For: 5.x
>
> Attachments: c-19335-dtest-bootstraptest-fail.txt,
> c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *Current Behavior*
> The current implementation of nodetool tablestats in Apache Cassandra outputs
> statistics in a format that is not immediately human-readable. This output
> primarily includes raw byte counts, which require additional calculation or
> conversion to be easily understood by users. This can be inefficient and
> time-consuming, especially for users who frequently monitor these statistics
> for performance tuning or maintenance purposes.
> *Proposed Change*
> We propose that nodetool tablestats should, by default, provide its output in
> a human-readable format. This change would involve converting byte counts
> into more understandable units (KiB, MiB, GiB). The tool could still retain
> the option to display raw data for those who need it, perhaps through a flag
> such as --no-human-readable or --raw.
> *Considerations*
> The change should maintain backward compatibility, ensuring that scripts or
> tools relying on the current output format can continue to function correctly.
> We should provide adequate documentation and examples of both the new default
> output and how to access the raw data format, if needed.
> *Alignment*
> Discussion in the dev mailing list:
> [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9]
> *Related work*
> Previous work in the series:
> # https://issues.apache.org/jira/browse/CASSANDRA-19015
> # https://issues.apache.org/jira/browse/CASSANDRA-19104
--
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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846093#comment-17846093 ] Brandon Williams edited comment on CASSANDRA-18106 at 5/13/24 10:04 PM: Ah, that's right. I think this was a relevant bit: bq. b) we run the python dtest upgrade tests twice and each run ignores (filters out) upgrade paths that are not valid for the current JAVA_HOME jdk. So we obviated the need to switch JDKs during a run by doing more runs with adjacent versions that share the same JDK. was (Author: brandon.williams): Ah, that's right. I think this was a relevant bit: > b) we run the python dtest upgrade tests twice and each run ignores (filters > out) upgrade paths that are not valid for the current JAVA_HOME jdk. So we obviated the need to switch JDKs during a run by doing more runs with adjacent versions that share the same JDK. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- 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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846093#comment-17846093 ] Brandon Williams commented on CASSANDRA-18106: -- Ah, that's right. I think this was a relevant bit: > b) we run the python dtest upgrade tests twice and each run ignores (filters > out) upgrade paths that are not valid for the current JAVA_HOME jdk. So we obviated the need to switch JDKs during a run by doing more runs with adjacent versions that share the same JDK. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- 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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846085#comment-17846085 ] Brandon Williams edited comment on CASSANDRA-18106 at 5/13/24 9:50 PM: --- >From the comments it seems that both V3 and V4 will need to cross JDKs, and >probably someday V5 will too: \# Proto v3 upgrades (v3 is supported on 2.1, 2.2, 3.0, 3.11, 4.0, 4.1, trunk) \# Proto v4 upgrades (v4 is supported on 2.2, 3.0, 3.1, 4.0, 4.1, trunk) \# Proto v5 upgrades (v5 is supported on 4.1, trunk) It is unfortunate to discover this almost a year after an implementation relying on it not being true, but I guess we have no choice but to bring back JAVAx_HOME. was (Author: brandon.williams): >From the comments it seems that both V3 and V4 will need to cross JDKs, and >probably someday V5 will too: # Proto v3 upgrades (v3 is supported on 2.1, 2.2, 3.0, 3.11, 4.0, 4.1, trunk) # Proto v4 upgrades (v4 is supported on 2.2, 3.0, 3.1, 4.0, 4.1, trunk) # Proto v5 upgrades (v5 is supported on 4.1, trunk) It is unfortunate to discover this almost a year after an implementation relying on it not being true, but I guess we have no choice but to bring back JAVAx_HOME. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- 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] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[ https://issues.apache.org/jira/browse/CASSANDRA-19557 ]
Brandon Williams deleted comment on CASSANDRA-19557:
--
was (Author: brandon.williams):
Good point. Doing this in {{ShallowInfoRetriever}} instead looks viable to me.
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:829)
> {code}
> This Cassandra logic was originally written for the case when there is a
> small number of index entries and all of them are fetched in memory, so it
> was cheap to retrieve the IndexInfo
[jira] [Commented] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846087#comment-17846087
]
Brandon Williams commented on CASSANDRA-19557:
--
Good point. Doing this in {{ShallowInfoRetriever}} instead looks viable to me.
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:829)
> {code}
> This Cassandra logic was originally written for the case when there is a
> small number of index entries and all of them are fetched in
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846085#comment-17846085 ] Brandon Williams commented on CASSANDRA-18106: -- >From the comments it seems that both V3 and V4 will need to cross JDKs, and >probably someday V5 will too: # Proto v3 upgrades (v3 is supported on 2.1, 2.2, 3.0, 3.11, 4.0, 4.1, trunk) # Proto v4 upgrades (v4 is supported on 2.2, 3.0, 3.1, 4.0, 4.1, trunk) # Proto v5 upgrades (v5 is supported on 4.1, trunk) It is unfortunate to discover this almost a year after an implementation relying on it not being true, but I guess we have no choice but to bring back JAVAx_HOME. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- 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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19335: - Status: Review In Progress (was: Changes Suggested) > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19335: - Status: Needs Committer (was: Review In Progress) > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846013#comment-17846013 ] Brandon Williams commented on CASSANDRA-19335: -- None of the failures are related to this patch, +1 from me. > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845986#comment-17845986
]
Brandon Williams commented on CASSANDRA-19498:
--
TopPartitionsTest testServiceTopPartitionsSingleTable is CASSANDRA-17798
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845957#comment-17845957 ] Brandon Williams edited comment on CASSANDRA-19335 at 5/13/24 2:55 PM: --- bq. which utilizes the "raw" or "no-human-readable" output option I see the short flag came in handy! :) This looks good to me, let's see how it fares in CI: ||Branch||CI|| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19335-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1630/workflows/0be4de5e-2879-4c15-827e-b709bb58b4a0], [j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1630/workflows/09bd2a1d-e3a3-4ec1-a6b4-19cdff50307d]| was (Author: brandon.williams): bq. which utilizes the "raw" or "no-human-readable" output option I see the short flag came in handy! :) This looks good to me, let's see how it fares in CI: ||Branch||CI|| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19335-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1628/workflows/91587415-6150-47cd-9612-2c3ea48ea953], [j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1628/workflows/8bf28bd5-efb1-436c-935d-c1eeea5165d3]| > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845957#comment-17845957 ] Brandon Williams commented on CASSANDRA-19335: -- bq. which utilizes the "raw" or "no-human-readable" output option I see the short flag came in handy! :) This looks good to me, let's see how it fares in CI: ||Branch||CI|| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19335-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1628/workflows/91587415-6150-47cd-9612-2c3ea48ea953], [j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1628/workflows/8bf28bd5-efb1-436c-935d-c1eeea5165d3]| > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19335: - Complexity: Normal (was: Low Hanging Fruit) > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 50m > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845373#comment-17845373 ] Brandon Williams commented on CASSANDRA-19632: -- There are nearly 500 instances of trace logging in the code base, wrapping them is at the least significant delta, so this is trivial in thought but less so in execution. Making changes "across the codebase" this close to release doesn't seem like prudent near-release behavior to me. This may improve stability, but probably not in an empirically measurable way, and I don't know of trace logging (when not enabled) causing any instability now. The risk versus reward calculation just doesn't look equitable for 5.0.0. > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 5.0.x, 5.x > > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- 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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845084#comment-17845084 ] Brandon Williams commented on CASSANDRA-19335: -- Docs were fixed for that in CASSANDRA-19628 > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 50m > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19629) Upgrade from 4.1.4 to 5.0 crashes with CorruptSSTableException
[
https://issues.apache.org/jira/browse/CASSANDRA-19629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845054#comment-17845054
]
Brandon Williams commented on CASSANDRA-19629:
--
This looks like a duplicate of CASSANDRA-18108, to which I've added a fixver
for 5.0.x .
> Upgrade from 4.1.4 to 5.0 crashes with CorruptSSTableException
> --
>
> Key: CASSANDRA-19629
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19629
> Project: Cassandra
> Issue Type: Bug
>Reporter: Klay
>Priority: Normal
> Attachments: data.tar.gz, system.log
>
>
> When migrating data from 4.1.4 to 5.0 (commit: ccdeb12), the upgrade crashed
> with the following exception
> {code:java}
> ERROR [SSTableBatchOpen:1] 2024-05-09 16:25:04,564
> DefaultFSErrorHandler.java:129 - Exiting forcefully due to file system
> exception on startup, disk failure policy "stop"
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /home/klay/system/cassandra/apache-cassandra-5.0/bin/../data/data/ks/tb-9f7e6da00e2011efa77a0bfeb6733ccc/nb-1-big
> at
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:111)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:397)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:353)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.lambda$openAll$4(SSTableReader.java:414)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.AssertionError: null
> at
> org.apache.cassandra.db.RegularAndStaticColumns$Builder.add(RegularAndStaticColumns.java:166)
> at
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:327)
> at
> org.apache.cassandra.io.sstable.format.StatsComponent.serializationHeader(StatsComponent.java:85)
> at
> org.apache.cassandra.io.sstable.format.big.BigSSTableReaderLoadingBuilder.openComponents(BigSSTableReaderLoadingBuilder.java:78)
> at
> org.apache.cassandra.io.sstable.format.big.BigSSTableReaderLoadingBuilder.openComponents(BigSSTableReaderLoadingBuilder.java:58)
> at
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:92)
> ... 10 common frames omitted
> {code}
> h1. Reproduce
> Start up one 4.1.4 node using default configuration and execute the following
> command
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE ks.tb (c1 INT, c2 INT, PRIMARY KEY (c1));
> INSERT INTO ks.tb (c1, c2) VALUES (0,0);
> ALTER TABLE ks.tb DROP c2 ;
> ALTER TABLE ks.tb RENAME c1 TO c2;
> {code}
> Drain and upgrade to 5.0 (commit: ccdeb12)
> {code:java}
> bin/nodetool drain
> bin/nodetool stopdaemon{code}
> The upgrade would crash with the following exception
> {code:java}
> ERROR [SSTableBatchOpen:1] 2024-05-09 16:25:04,564
> DefaultFSErrorHandler.java:129 - Exiting forcefully due to file system
> exception on startup, disk failure policy "stop"
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /home/klay/system/cassandra/apache-cassandra-5.0/bin/../data/data/ks/tb-9f7e6da00e2011efa77a0bfeb6733ccc/nb-1-big
> at
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:111)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:397)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:353)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.lambda$openAll$4(SSTableReader.java:414)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at
[jira] [Updated] (CASSANDRA-18108) Data loss after a system restart of 3.11.17/4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18108:
-
Bug Category: Parent values: Availability(12983)Level 1 values:
Unavailable(12994)
Complexity: Normal
Component/s: Legacy/Core
Discovered By: User Report
Fix Version/s: 4.1.x
5.0.x
5.x
Severity: Normal
Status: Open (was: Triage Needed)
> Data loss after a system restart of 3.11.17/4.1.4
> -
>
> Key: CASSANDRA-18108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18108
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Ke Han
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> When we upgrade Cassandra from 3.11.17 to 4.0.12, we found a data loss during
> the upgrade process. This bug can also be triggered if simply performing a
> system restart for 3.11.17, 4.0.12 or 4.1.4.
> h1. Steps to reproduce
> Start a 3.11.15 or 4.1.4 Cassandra node using default configurations. Execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE IF NOT EXISTS ks.tb (c1 INT,c3 INT,c2 TEXT, PRIMARY KEY (c1 ))
> WITH speculative_retry = 'ALWAYS';
> INSERT INTO ks.tb (c1, c2) VALUES (2,'val');
> ALTER TABLE ks.tb DROP c2 ;
> ALTER TABLE ks.tb RENAME c1 TO c2; {code}
> Then execute a SELECT command, we get the correct data
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +--
> 2 | null
> (1 rows){code}
> Flush and stop the Cassandra daemon.
> {code:java}
> bin/nodetool flush
> bin/nodetool stopdaemon{code}
> Then restart the node.
> {code:java}
> bin/cassandra{code}
> Start cqlsh, and execute the same SELECT command. The data in ks.tb is lost.
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +
> (0 rows){code}
> During the node restart, we found an error log about initializing the table,
> but it didn't prevent the system from starting up.
> {code:java}
> INFO [main] 2022-12-09 21:37:54,234 ColumnFamilyStore.java:432 -
> Initializing ks.tb
> ERROR [SSTableBatchOpen:1] 2022-12-09 21:37:54,237 CassandraDaemon.java:244 -
> Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.PartitionColumns$Builder.add(PartitionColumns.java:161)
> at
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:340)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:522)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:385)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader$3.run(SSTableReader.java:570)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> at java.lang.Thread.run(Thread.java:750) {code}
> This bug can also be triggered if we perform an upgrade (with drain) from
> 3.11.17 to 4.0.12 or 4.1.4 and execute the SELECT command in the new version.
--
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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845037#comment-17845037
]
Brandon Williams commented on CASSANDRA-19628:
--
Committed and deployed, thanks!
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.31, 4.0.14, 4.1.6, 5.0-beta2, 5.0, 5.1
>
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19628:
-
Fix Version/s: 3.0.31
4.0.14
4.1.6
5.0-beta2
5.0
5.1
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra-website/commit/a5b7a87861cf02d7a02e38e7e4212018f93be3e1
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.31, 4.0.14, 4.1.6, 5.0-beta2, 5.0, 5.1
>
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19628:
-
Bug Category: Parent values: Documentation(13562)
Complexity: Low Hanging Fruit
Component/s: Legacy/Documentation and Website
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19628:
-
Test and Documentation Plan: not really needed
Status: Patch Available (was: Open)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845002#comment-17845002
]
Brandon Williams commented on CASSANDRA-19628:
--
Branch [here|https://github.com/driftx/cassandra-website/tree/CASSANDRA-19628]
to remove mentions of updateconf. I don't think we need to mention ccm
specifics here, especially since this is not a common operation for beginners.
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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-19628) Correct testing instructions on the website
Brandon Williams created CASSANDRA-19628:
Summary: Correct testing instructions on the website
Key: CASSANDRA-19628
URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
Project: Cassandra
Issue Type: Bug
Reporter: Brandon Williams
At https://cassandra.apache.org/_/development/testing.html it says to issue
these statements for cqlsh tests:
{noformat}
ccm updateconf "enable_user_defined_functions: true"
ccm updateconf "enable_scripted_user_defined_functions: true"
ccm updateconf "cdc_enabled: true"
{noformat}
But these actually break the configuration so it won't start.
--
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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-19628:
Assignee: Brandon Williams
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844999#comment-17844999 ] Brandon Williams commented on CASSANDRA-19335: -- On slack, Leo and I narrowed his issue down to faulty updateconf directives to ccm from the docs. Without those ccm starts just fine. > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 50m > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- 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-19624) ModificationStatement#casInternal leaks RowIterator
[ https://issues.apache.org/jira/browse/CASSANDRA-19624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19624: - Bug Category: Parent values: Degradation(12984)Level 1 values: Resource Management(12995) Complexity: Normal Component/s: Legacy/Core Discovered By: User Report Fix Version/s: 4.0.x 4.1.x 5.0.x 5.x Severity: Normal Status: Open (was: Triage Needed) > ModificationStatement#casInternal leaks RowIterator > --- > > Key: CASSANDRA-19624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19624 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Michael Marshall >Assignee: Michael Marshall >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 40m > Remaining Estimate: 0h > > In the `ModificationStatement` class, the `casInternal` method opens a row > iterator without closing it, causing the iterator to leak resources. Here is > a link to the relevant code in the `trunk` branch. > [https://github.com/apache/cassandra/blob/a77a2d10b1d247ed920b75df79f982a3b7c6a431/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java#L680-L684] > > It seems that `cassandra-3.0.30` has the bug, but `cassandra-2.2.19` does not > have it. Is it correct to target `cassandra-3.0.30`? > What is the best practice for testing this kind of bug fix? It seems like a > low complexity fix. This is my first contribution to the Cassandra community, > so any guidance is appreciated. Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19621) Test failure: gossip_test.TestGossip::test_2dc_parallel_startup
[
https://issues.apache.org/jira/browse/CASSANDRA-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19621:
-
Test and Documentation Plan: run CI
Status: Patch Available (was: Open)
> Test failure: gossip_test.TestGossip::test_2dc_parallel_startup
> ---
>
> Key: CASSANDRA-19621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19621
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x
>
>
> As seen at
> https://app.circleci.com/pipelines/github/driftx/cassandra/1625/workflows/d3849d2a-987e-49f8-9f4b-916c7ce85279/jobs/88756/tests:
> {quote}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node4] 'ERROR [Messaging-EventLoop-3-3] 2024-05-07
> 20:10:54,261 NoSpamLogger.java:110 -
> /127.0.0.4:7004->/127.0.0.1:7001-URGENT_MESSAGES-[no-channel] failed to
> connect\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.OutboundConnectionInitiator$Handler.channelInactive(OutboundConnectionInitiator.java:322)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat
>
> io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:411)\n\tat
>
> io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:376)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat
>
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:301)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
>
> io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)\n\tat
>
> io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:813)\n\tat
>
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)\n\tat
>
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)\n\tat
>
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)\n\tat
> io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)\n\tat
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)\n\tat
>
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:833)']"
> {quote}
--
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-19621) Test failure: gossip_test.TestGossip::test_2dc_parallel_startup
[
https://issues.apache.org/jira/browse/CASSANDRA-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844700#comment-17844700
]
Brandon Williams commented on CASSANDRA-19621:
--
Patch to ignore this
[here|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-19621]. I
haven't been able to reproduce but this should do the trick and
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1627/workflows/270dafe1-230c-4650-977b-a6c0bbaa370f/jobs/89041]
is multiplexed CI.
> Test failure: gossip_test.TestGossip::test_2dc_parallel_startup
> ---
>
> Key: CASSANDRA-19621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19621
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x
>
>
> As seen at
> https://app.circleci.com/pipelines/github/driftx/cassandra/1625/workflows/d3849d2a-987e-49f8-9f4b-916c7ce85279/jobs/88756/tests:
> {quote}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node4] 'ERROR [Messaging-EventLoop-3-3] 2024-05-07
> 20:10:54,261 NoSpamLogger.java:110 -
> /127.0.0.4:7004->/127.0.0.1:7001-URGENT_MESSAGES-[no-channel] failed to
> connect\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.OutboundConnectionInitiator$Handler.channelInactive(OutboundConnectionInitiator.java:322)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat
>
> io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:411)\n\tat
>
> io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:376)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat
>
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:301)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
>
> io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)\n\tat
>
> io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:813)\n\tat
>
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)\n\tat
>
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)\n\tat
>
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)\n\tat
> io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)\n\tat
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)\n\tat
>
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:833)']"
> {quote}
--
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-15439) Token metadata for bootstrapping nodes is lost under temporary failures
[
https://issues.apache.org/jira/browse/CASSANDRA-15439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15439:
-
Fix Version/s: 4.0.14
4.1.6
5.0-beta2
5.0
(was: 4.0.x)
(was: 4.1.x)
(was: 5.0.x)
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/057d082e00f7d10b8e9b127cfabd9b8cd228da3d
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks all!
> Token metadata for bootstrapping nodes is lost under temporary failures
> ---
>
> Key: CASSANDRA-15439
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15439
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Josh Snyder
>Assignee: Raymond Huffman
>Priority: Normal
> Fix For: 4.0.14, 4.1.6, 5.0-beta2, 5.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In CASSANDRA-8838, [~pauloricardomg] asked "hints will not be stored to the
> bootstrapping node after RING_DELAY, since it will evicted from the TMD
> pending ranges. Should we create a ticket to address this?"
> CASSANDRA-15264 relates to the most likely cause of such situations, where
> the Cassandra daemon on the bootstrapping node completely crashes. Based on
> testing with {{kill -STOP}} on a bootstrapping Cassandra JVM, I believe it
> also is possible to remove token metadata (and thus pending ranges, and thus
> hints) for a bootstrapping node, simply by affecting its status in the
> failure detector.
> A node in the cluster sees the bootstrapping node this way:
> {noformat}
> INFO [GossipStage:1] 2019-11-27 20:41:41,101 Gossiper.java: - Node
> /PUBLIC-IP is now part of the cluster
> INFO [GossipStage:1] 2019-11-27 20:41:41,199 Gossiper.java:1073 -
> InetAddress /PUBLIC-IP is now UP
> INFO [HANDSHAKE-/PRIVATE-IP] 2019-11-27 20:41:41,412
> OutboundTcpConnection.java:565 - Handshaking version with /PRIVATE-IP
> INFO [STREAM-INIT-/PRIVATE-IP:21233] 2019-11-27 20:42:10,019
> StreamResultFuture.java:112 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4
> ID#0] Creating new streaming plan for Bootstrap
> INFO [STREAM-INIT-/PRIVATE-IP:21233] 2019-11-27 20:42:10,020
> StreamResultFuture.java:119 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4,
> ID#0] Received streaming plan for Bootstrap
> INFO [STREAM-INIT-/PRIVATE-IP:56003] 2019-11-27 20:42:10,112
> StreamResultFuture.java:119 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4,
> ID#0] Received streaming plan for Bootstrap
> INFO [STREAM-IN-/PUBLIC-IP] 2019-11-27 20:42:10,179
> StreamResultFuture.java:169 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4
> ID#0] Prepare completed. Receiving 0 files(0 bytes), sending 833
> files(139744616815 bytes)
> INFO [GossipStage:1] 2019-11-27 20:54:47,547 Gossiper.java:1089 -
> InetAddress /PUBLIC-IP is now DOWN
> INFO [GossipTasks:1] 2019-11-27 20:54:57,551 Gossiper.java:849 - FatClient
> /PUBLIC-IP has been silent for 3ms, removing from gossip
> {noformat}
> Since the bootstrapping node has no tokens, it is treated like a fat client,
> and it is removed from the ring. For correctness purposes, I believe we must
> keep storing hints for the downed bootstrapping node until it is either
> assassinated or until a replacement attempts to bootstrap for the same token.
--
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-19621) Test failure: gossip_test.TestGossip::test_2dc_parallel_startup
[
https://issues.apache.org/jira/browse/CASSANDRA-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19621:
-
Description:
As seen at
https://app.circleci.com/pipelines/github/driftx/cassandra/1625/workflows/d3849d2a-987e-49f8-9f4b-916c7ce85279/jobs/88756/tests:
{quote}
failed on teardown with "Unexpected error found in node logs (see stdout for
full details). Errors: [[node4] 'ERROR [Messaging-EventLoop-3-3] 2024-05-07
20:10:54,261 NoSpamLogger.java:110 -
/127.0.0.4:7004->/127.0.0.1:7001-URGENT_MESSAGES-[no-channel] failed to
connect\njava.nio.channels.ClosedChannelException: null\n\tat
org.apache.cassandra.net.OutboundConnectionInitiator$Handler.channelInactive(OutboundConnectionInitiator.java:322)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat
io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:411)\n\tat
io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:376)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat
io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:301)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)\n\tat
io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:813)\n\tat
io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)\n\tat
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)\n\tat
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)\n\tat
io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)\n\tat
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)\n\tat
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)\n\tat
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
java.base/java.lang.Thread.run(Thread.java:833)']"
{quote}
was:
As seen at
https://app.circleci.com/pipelines/github/driftx/cassandra/1625/workflows/d3849d2a-987e-49f8-9f4b-916c7ce85279/jobs/88756/tests:
{noformat}
failed on teardown with "Unexpected error found in node logs (see stdout for
full details). Errors: [[node4] 'ERROR [Messaging-EventLoop-3-3] 2024-05-07
20:10:54,261 NoSpamLogger.java:110 -
/127.0.0.4:7004->/127.0.0.1:7001-URGENT_MESSAGES-[no-channel] failed to
connect\njava.nio.channels.ClosedChannelException: null\n\tat
org.apache.cassandra.net.OutboundConnectionInitiator$Handler.channelInactive(OutboundConnectionInitiator.java:322)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat
io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:411)\n\tat
io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:376)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat
io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:301)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)\n\tat
[jira] [Updated] (CASSANDRA-19623) Read fail with "illegal RT bounds sequence" after migrating data from 2.2.19 to 3.0.30
[
https://issues.apache.org/jira/browse/CASSANDRA-19623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19623:
-
Bug Category: Parent values: Availability(12983)Level 1 values:
Unavailable(12994)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 3.0.x
Severity: Normal
Status: Open (was: Triage Needed)
> Read fail with "illegal RT bounds sequence" after migrating data from 2.2.19
> to 3.0.30
> --
>
> Key: CASSANDRA-19623
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19623
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Klay
>Priority: Normal
> Fix For: 3.0.x
>
> Attachments: cassandra.yaml, data.tar.gz, system.log
>
>
> After migrating data from 2.2.19 to 3.0.30, reading the legacy data in 3.0.30
> would fail with the following exception.
> {code:java}
> INFO [main] 2024-05-08 00:42:42,397 CassandraDaemon.java:653 - Startup
> complete
> ERROR [SharedPool-Worker-2] 2024-05-08 00:42:49,975
> AbstractLocalAwareExecutorService.java:166 - Uncaught exception on thread
> Thread[SharedPool-Worker-2,10,main]
> java.lang.RuntimeException: java.lang.IllegalStateException: SSTABLE
> UnfilteredRowIterator for ks.tb has an illegal RT bounds sequence: unexpected
> end bound or boundary Marker INCL_START_BOUND(1)@1715128933051779/1715128933
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2656)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
> at java.lang.Thread.run(Thread.java:750)
> Caused by: java.lang.IllegalStateException: SSTABLE UnfilteredRowIterator for
> ks.tb has an illegal RT bounds sequence: unexpected end bound or boundary
> Marker INCL_START_BOUND(1)@1715128933051779/1715128933
> at
> org.apache.cassandra.db.transform.RTBoundValidator$RowsTransformation.ise(RTBoundValidator.java:120)
> at
> org.apache.cassandra.db.transform.RTBoundValidator$RowsTransformation.applyToMarker(RTBoundValidator.java:87)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:144)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:297)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:187)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:180)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:176)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:76)
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:347)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1914)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2652)
> ... 5 common frames omitted {code}
> h1. Reproduce
> 1. Start up cassandra-2.2.19, single node. Set column_index_size_in_kb in
> cassandra.yaml to 1.
> {code:java}
> // cassandra.yaml
> column_index_size_in_kb: 1 {code}
> 2. Execute the following commands (I masked out all data in the INSERT
> command using a long string of 'A' to make it simpler)
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE ks.tb (c3 INT, c7 INT, c0 TEXT,c6 set, PRIMARY KEY (c3,
> c7, c0));DELETE FROM ks.tb WHERE c3 = 1 AND c7 = 1;
> DELETE FROM ks.tb WHERE c3 = 1 AND c7 = 1 AND c0 = 'e';INSERT INTO ks.tb (c7,
> c3, c6, c0) VALUES
>
[jira] [Updated] (CASSANDRA-15439) Token metadata for bootstrapping nodes is lost under temporary failures
[
https://issues.apache.org/jira/browse/CASSANDRA-15439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15439:
-
Status: Ready to Commit (was: Review In Progress)
> Token metadata for bootstrapping nodes is lost under temporary failures
> ---
>
> Key: CASSANDRA-15439
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15439
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Josh Snyder
>Assignee: Raymond Huffman
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In CASSANDRA-8838, [~pauloricardomg] asked "hints will not be stored to the
> bootstrapping node after RING_DELAY, since it will evicted from the TMD
> pending ranges. Should we create a ticket to address this?"
> CASSANDRA-15264 relates to the most likely cause of such situations, where
> the Cassandra daemon on the bootstrapping node completely crashes. Based on
> testing with {{kill -STOP}} on a bootstrapping Cassandra JVM, I believe it
> also is possible to remove token metadata (and thus pending ranges, and thus
> hints) for a bootstrapping node, simply by affecting its status in the
> failure detector.
> A node in the cluster sees the bootstrapping node this way:
> {noformat}
> INFO [GossipStage:1] 2019-11-27 20:41:41,101 Gossiper.java: - Node
> /PUBLIC-IP is now part of the cluster
> INFO [GossipStage:1] 2019-11-27 20:41:41,199 Gossiper.java:1073 -
> InetAddress /PUBLIC-IP is now UP
> INFO [HANDSHAKE-/PRIVATE-IP] 2019-11-27 20:41:41,412
> OutboundTcpConnection.java:565 - Handshaking version with /PRIVATE-IP
> INFO [STREAM-INIT-/PRIVATE-IP:21233] 2019-11-27 20:42:10,019
> StreamResultFuture.java:112 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4
> ID#0] Creating new streaming plan for Bootstrap
> INFO [STREAM-INIT-/PRIVATE-IP:21233] 2019-11-27 20:42:10,020
> StreamResultFuture.java:119 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4,
> ID#0] Received streaming plan for Bootstrap
> INFO [STREAM-INIT-/PRIVATE-IP:56003] 2019-11-27 20:42:10,112
> StreamResultFuture.java:119 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4,
> ID#0] Received streaming plan for Bootstrap
> INFO [STREAM-IN-/PUBLIC-IP] 2019-11-27 20:42:10,179
> StreamResultFuture.java:169 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4
> ID#0] Prepare completed. Receiving 0 files(0 bytes), sending 833
> files(139744616815 bytes)
> INFO [GossipStage:1] 2019-11-27 20:54:47,547 Gossiper.java:1089 -
> InetAddress /PUBLIC-IP is now DOWN
> INFO [GossipTasks:1] 2019-11-27 20:54:57,551 Gossiper.java:849 - FatClient
> /PUBLIC-IP has been silent for 3ms, removing from gossip
> {noformat}
> Since the bootstrapping node has no tokens, it is treated like a fat client,
> and it is removed from the ring. For correctness purposes, I believe we must
> keep storing hints for the downed bootstrapping node until it is either
> assassinated or until a replacement attempts to bootstrap for the same token.
--
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-15439) Token metadata for bootstrapping nodes is lost under temporary failures
[
https://issues.apache.org/jira/browse/CASSANDRA-15439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15439:
-
Reviewers: Brandon Williams, David Capwell (was: Brandon Williams)
Status: Review In Progress (was: Needs Committer)
> Token metadata for bootstrapping nodes is lost under temporary failures
> ---
>
> Key: CASSANDRA-15439
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15439
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Josh Snyder
>Assignee: Raymond Huffman
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In CASSANDRA-8838, [~pauloricardomg] asked "hints will not be stored to the
> bootstrapping node after RING_DELAY, since it will evicted from the TMD
> pending ranges. Should we create a ticket to address this?"
> CASSANDRA-15264 relates to the most likely cause of such situations, where
> the Cassandra daemon on the bootstrapping node completely crashes. Based on
> testing with {{kill -STOP}} on a bootstrapping Cassandra JVM, I believe it
> also is possible to remove token metadata (and thus pending ranges, and thus
> hints) for a bootstrapping node, simply by affecting its status in the
> failure detector.
> A node in the cluster sees the bootstrapping node this way:
> {noformat}
> INFO [GossipStage:1] 2019-11-27 20:41:41,101 Gossiper.java: - Node
> /PUBLIC-IP is now part of the cluster
> INFO [GossipStage:1] 2019-11-27 20:41:41,199 Gossiper.java:1073 -
> InetAddress /PUBLIC-IP is now UP
> INFO [HANDSHAKE-/PRIVATE-IP] 2019-11-27 20:41:41,412
> OutboundTcpConnection.java:565 - Handshaking version with /PRIVATE-IP
> INFO [STREAM-INIT-/PRIVATE-IP:21233] 2019-11-27 20:42:10,019
> StreamResultFuture.java:112 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4
> ID#0] Creating new streaming plan for Bootstrap
> INFO [STREAM-INIT-/PRIVATE-IP:21233] 2019-11-27 20:42:10,020
> StreamResultFuture.java:119 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4,
> ID#0] Received streaming plan for Bootstrap
> INFO [STREAM-INIT-/PRIVATE-IP:56003] 2019-11-27 20:42:10,112
> StreamResultFuture.java:119 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4,
> ID#0] Received streaming plan for Bootstrap
> INFO [STREAM-IN-/PUBLIC-IP] 2019-11-27 20:42:10,179
> StreamResultFuture.java:169 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4
> ID#0] Prepare completed. Receiving 0 files(0 bytes), sending 833
> files(139744616815 bytes)
> INFO [GossipStage:1] 2019-11-27 20:54:47,547 Gossiper.java:1089 -
> InetAddress /PUBLIC-IP is now DOWN
> INFO [GossipTasks:1] 2019-11-27 20:54:57,551 Gossiper.java:849 - FatClient
> /PUBLIC-IP has been silent for 3ms, removing from gossip
> {noformat}
> Since the bootstrapping node has no tokens, it is treated like a fat client,
> and it is removed from the ring. For correctness purposes, I believe we must
> keep storing hints for the downed bootstrapping node until it is either
> assassinated or until a replacement attempts to bootstrap for the same token.
--
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-15439) Token metadata for bootstrapping nodes is lost under temporary failures
[
https://issues.apache.org/jira/browse/CASSANDRA-15439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1789#comment-1789
]
Brandon Williams commented on CASSANDRA-15439:
--
CI found CASSANDRA-19621 and CASSANDRA-19622 which aren't related, otherwise
nothing new. I will begin committing.
> Token metadata for bootstrapping nodes is lost under temporary failures
> ---
>
> Key: CASSANDRA-15439
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15439
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Josh Snyder
>Assignee: Raymond Huffman
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In CASSANDRA-8838, [~pauloricardomg] asked "hints will not be stored to the
> bootstrapping node after RING_DELAY, since it will evicted from the TMD
> pending ranges. Should we create a ticket to address this?"
> CASSANDRA-15264 relates to the most likely cause of such situations, where
> the Cassandra daemon on the bootstrapping node completely crashes. Based on
> testing with {{kill -STOP}} on a bootstrapping Cassandra JVM, I believe it
> also is possible to remove token metadata (and thus pending ranges, and thus
> hints) for a bootstrapping node, simply by affecting its status in the
> failure detector.
> A node in the cluster sees the bootstrapping node this way:
> {noformat}
> INFO [GossipStage:1] 2019-11-27 20:41:41,101 Gossiper.java: - Node
> /PUBLIC-IP is now part of the cluster
> INFO [GossipStage:1] 2019-11-27 20:41:41,199 Gossiper.java:1073 -
> InetAddress /PUBLIC-IP is now UP
> INFO [HANDSHAKE-/PRIVATE-IP] 2019-11-27 20:41:41,412
> OutboundTcpConnection.java:565 - Handshaking version with /PRIVATE-IP
> INFO [STREAM-INIT-/PRIVATE-IP:21233] 2019-11-27 20:42:10,019
> StreamResultFuture.java:112 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4
> ID#0] Creating new streaming plan for Bootstrap
> INFO [STREAM-INIT-/PRIVATE-IP:21233] 2019-11-27 20:42:10,020
> StreamResultFuture.java:119 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4,
> ID#0] Received streaming plan for Bootstrap
> INFO [STREAM-INIT-/PRIVATE-IP:56003] 2019-11-27 20:42:10,112
> StreamResultFuture.java:119 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4,
> ID#0] Received streaming plan for Bootstrap
> INFO [STREAM-IN-/PUBLIC-IP] 2019-11-27 20:42:10,179
> StreamResultFuture.java:169 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4
> ID#0] Prepare completed. Receiving 0 files(0 bytes), sending 833
> files(139744616815 bytes)
> INFO [GossipStage:1] 2019-11-27 20:54:47,547 Gossiper.java:1089 -
> InetAddress /PUBLIC-IP is now DOWN
> INFO [GossipTasks:1] 2019-11-27 20:54:57,551 Gossiper.java:849 - FatClient
> /PUBLIC-IP has been silent for 3ms, removing from gossip
> {noformat}
> Since the bootstrapping node has no tokens, it is treated like a fat client,
> and it is removed from the ring. For correctness purposes, I believe we must
> keep storing hints for the downed bootstrapping node until it is either
> assassinated or until a replacement attempts to bootstrap for the same token.
--
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-19622) Test failure: org.apache.cassandra.distributed.test.ClearSnapshotTest.clearSnapshotSlowTest-_jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-19622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19622:
-
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Local/Snapshots
Discovered By: User Report
Fix Version/s: 5.0.x
Severity: Normal
Status: Open (was: Triage Needed)
Note that this occurred against the 'latest' config.
> Test failure:
> org.apache.cassandra.distributed.test.ClearSnapshotTest.clearSnapshotSlowTest-_jdk17
> --
>
> Key: CASSANDRA-19622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19622
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x
>
>
> https://app.circleci.com/pipelines/github/driftx/cassandra/1625/workflows/d3849d2a-987e-49f8-9f4b-916c7ce85279/jobs/88752/tests
> {quote}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.ClearSnapshotTest.clearSnapshotSlowTest(ClearSnapshotTest.java:123)
> 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)
> {quote}
--
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-19622) Test failure: org.apache.cassandra.distributed.test.ClearSnapshotTest.clearSnapshotSlowTest-_jdk17
Brandon Williams created CASSANDRA-19622:
Summary: Test failure:
org.apache.cassandra.distributed.test.ClearSnapshotTest.clearSnapshotSlowTest-_jdk17
Key: CASSANDRA-19622
URL: https://issues.apache.org/jira/browse/CASSANDRA-19622
Project: Cassandra
Issue Type: Bug
Reporter: Brandon Williams
https://app.circleci.com/pipelines/github/driftx/cassandra/1625/workflows/d3849d2a-987e-49f8-9f4b-916c7ce85279/jobs/88752/tests
{quote}
junit.framework.AssertionFailedError
at
org.apache.cassandra.distributed.test.ClearSnapshotTest.clearSnapshotSlowTest(ClearSnapshotTest.java:123)
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)
{quote}
--
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-19621) Test failure: gossip_test.TestGossip::test_2dc_parallel_startup
Brandon Williams created CASSANDRA-19621:
Summary: Test failure:
gossip_test.TestGossip::test_2dc_parallel_startup
Key: CASSANDRA-19621
URL: https://issues.apache.org/jira/browse/CASSANDRA-19621
Project: Cassandra
Issue Type: Bug
Components: Cluster/Gossip
Reporter: Brandon Williams
As seen at
https://app.circleci.com/pipelines/github/driftx/cassandra/1625/workflows/d3849d2a-987e-49f8-9f4b-916c7ce85279/jobs/88756/tests:
{noformat}
failed on teardown with "Unexpected error found in node logs (see stdout for
full details). Errors: [[node4] 'ERROR [Messaging-EventLoop-3-3] 2024-05-07
20:10:54,261 NoSpamLogger.java:110 -
/127.0.0.4:7004->/127.0.0.1:7001-URGENT_MESSAGES-[no-channel] failed to
connect\njava.nio.channels.ClosedChannelException: null\n\tat
org.apache.cassandra.net.OutboundConnectionInitiator$Handler.channelInactive(OutboundConnectionInitiator.java:322)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat
io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:411)\n\tat
io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:376)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat
io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:301)\n\tat
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)\n\tat
io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:813)\n\tat
io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)\n\tat
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)\n\tat
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)\n\tat
io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)\n\tat
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)\n\tat
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)\n\tat
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
java.base/java.lang.Thread.run(Thread.java:833)']"
{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-19621) Test failure: gossip_test.TestGossip::test_2dc_parallel_startup
[
https://issues.apache.org/jira/browse/CASSANDRA-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19621:
-
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 5.0.x
Severity: Normal
Assignee: Brandon Williams
Status: Open (was: Triage Needed)
> Test failure: gossip_test.TestGossip::test_2dc_parallel_startup
> ---
>
> Key: CASSANDRA-19621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19621
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x
>
>
> As seen at
> https://app.circleci.com/pipelines/github/driftx/cassandra/1625/workflows/d3849d2a-987e-49f8-9f4b-916c7ce85279/jobs/88756/tests:
> {noformat}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node4] 'ERROR [Messaging-EventLoop-3-3] 2024-05-07
> 20:10:54,261 NoSpamLogger.java:110 -
> /127.0.0.4:7004->/127.0.0.1:7001-URGENT_MESSAGES-[no-channel] failed to
> connect\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.OutboundConnectionInitiator$Handler.channelInactive(OutboundConnectionInitiator.java:322)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat
>
> io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:411)\n\tat
>
> io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:376)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:305)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:274)\n\tat
>
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:301)\n\tat
>
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:281)\n\tat
>
> io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)\n\tat
>
> io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:813)\n\tat
>
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)\n\tat
>
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)\n\tat
>
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)\n\tat
> io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)\n\tat
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)\n\tat
>
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:833)']"
> {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-15439) Token metadata for bootstrapping nodes is lost under temporary failures
[
https://issues.apache.org/jira/browse/CASSANDRA-15439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844431#comment-17844431
]
Brandon Williams commented on CASSANDRA-15439:
--
Grabbed Raymond's latest that switches to VV.BOOTSTRAPPING_STATUS for 4.0 and
4.1, adapted it to 5.0, let's check CI once more:
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-15439-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1624/workflows/61edd12a-4f99-4c31-8472-eee73c8ba932],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1624/workflows/60d95bc7-6144-4c7f-a0f1-d89f7dba3158]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-15439-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1623/workflows/acd29d35-c42c-4e11-b237-f97d0bd99481],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1623/workflows/469a5142-4eed-4cc8-a4cc-94f7482bc54a]|
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-15439-5.0]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1625/workflows/9afc2edf-f962-4391-8772-d054d9485fd4],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1625/workflows/d3849d2a-987e-49f8-9f4b-916c7ce85279]|
> Token metadata for bootstrapping nodes is lost under temporary failures
> ---
>
> Key: CASSANDRA-15439
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15439
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Josh Snyder
>Assignee: Raymond Huffman
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In CASSANDRA-8838, [~pauloricardomg] asked "hints will not be stored to the
> bootstrapping node after RING_DELAY, since it will evicted from the TMD
> pending ranges. Should we create a ticket to address this?"
> CASSANDRA-15264 relates to the most likely cause of such situations, where
> the Cassandra daemon on the bootstrapping node completely crashes. Based on
> testing with {{kill -STOP}} on a bootstrapping Cassandra JVM, I believe it
> also is possible to remove token metadata (and thus pending ranges, and thus
> hints) for a bootstrapping node, simply by affecting its status in the
> failure detector.
> A node in the cluster sees the bootstrapping node this way:
> {noformat}
> INFO [GossipStage:1] 2019-11-27 20:41:41,101 Gossiper.java: - Node
> /PUBLIC-IP is now part of the cluster
> INFO [GossipStage:1] 2019-11-27 20:41:41,199 Gossiper.java:1073 -
> InetAddress /PUBLIC-IP is now UP
> INFO [HANDSHAKE-/PRIVATE-IP] 2019-11-27 20:41:41,412
> OutboundTcpConnection.java:565 - Handshaking version with /PRIVATE-IP
> INFO [STREAM-INIT-/PRIVATE-IP:21233] 2019-11-27 20:42:10,019
> StreamResultFuture.java:112 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4
> ID#0] Creating new streaming plan for Bootstrap
> INFO [STREAM-INIT-/PRIVATE-IP:21233] 2019-11-27 20:42:10,020
> StreamResultFuture.java:119 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4,
> ID#0] Received streaming plan for Bootstrap
> INFO [STREAM-INIT-/PRIVATE-IP:56003] 2019-11-27 20:42:10,112
> StreamResultFuture.java:119 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4,
> ID#0] Received streaming plan for Bootstrap
> INFO [STREAM-IN-/PUBLIC-IP] 2019-11-27 20:42:10,179
> StreamResultFuture.java:169 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4
> ID#0] Prepare completed. Receiving 0 files(0 bytes), sending 833
> files(139744616815 bytes)
> INFO [GossipStage:1] 2019-11-27 20:54:47,547 Gossiper.java:1089 -
> InetAddress /PUBLIC-IP is now DOWN
> INFO [GossipTasks:1] 2019-11-27 20:54:57,551 Gossiper.java:849 - FatClient
> /PUBLIC-IP has been silent for 3ms, removing from gossip
> {noformat}
> Since the bootstrapping node has no tokens, it is treated like a fat client,
> and it is removed from the ring. For correctness purposes, I believe we must
> keep storing hints for the downed bootstrapping node until it is either
> assassinated or until a replacement attempts to bootstrap for the same token.
--
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-19335) Default nodetool tablestats to Human-Readable Output
[
https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843829#comment-17843829
]
Brandon Williams commented on CASSANDRA-19335:
--
First let me say you don't have to use docker, I personally don't and just
setup a python venv locally.
In both of your first two attempts, the real issue is that C* isn't working:
{noformat}
Node node1 should be running before waiting for log
message, but C* process is terminated.
{noformat}
I would check that you can run C* manually from /home/cassandra/cassandra.
Your last attempt used the wrong cassandra-dir but it probably would have ended
up the same way, so troubleshooting C* to get it working is the next step.
> Default nodetool tablestats to Human-Readable Output
>
>
> Key: CASSANDRA-19335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19335
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Leo Toff
>Assignee: Leo Toff
>Priority: Low
> Fix For: 5.x
>
> Attachments: c-19335-dtest-bootstraptest-fail.txt,
> c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> *Current Behavior*
> The current implementation of nodetool tablestats in Apache Cassandra outputs
> statistics in a format that is not immediately human-readable. This output
> primarily includes raw byte counts, which require additional calculation or
> conversion to be easily understood by users. This can be inefficient and
> time-consuming, especially for users who frequently monitor these statistics
> for performance tuning or maintenance purposes.
> *Proposed Change*
> We propose that nodetool tablestats should, by default, provide its output in
> a human-readable format. This change would involve converting byte counts
> into more understandable units (KiB, MiB, GiB). The tool could still retain
> the option to display raw data for those who need it, perhaps through a flag
> such as --no-human-readable or --raw.
> *Considerations*
> The change should maintain backward compatibility, ensuring that scripts or
> tools relying on the current output format can continue to function correctly.
> We should provide adequate documentation and examples of both the new default
> output and how to access the raw data format, if needed.
> *Alignment*
> Discussion in the dev mailing list:
> [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9]
> *Related work*
> Previous work in the series:
> # https://issues.apache.org/jira/browse/CASSANDRA-19015
> # https://issues.apache.org/jira/browse/CASSANDRA-19104
--
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-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19557:
-
Fix Version/s: 5.0-beta2
5.0
5.1
(was: 5.x)
(was: 5.0.x)
Source Control Link:
https://github.com/apache/cassandra/commit/049160e70a22bfcc9c751a1fe3afec1e5c329f4c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks for the patch and review!
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at
[jira] [Updated] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19557:
-
Status: Ready to Commit (was: Review In Progress)
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:829)
> {code}
> This Cassandra logic was originally written for the case when there is a
> small number of index entries and all of them are fetched in memory, so it
> was cheap to retrieve the IndexInfo again and again for
[jira] [Updated] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19557:
-
Test and Documentation Plan: run CI
Status: Patch Available (was: Open)
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:829)
> {code}
> This Cassandra logic was originally written for the case when there is a
> small number of index entries and all of them are fetched in memory, so it
> was cheap
[jira] [Updated] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19557:
-
Reviewers: Berenguer Blasi, Brandon Williams, Brandon Williams
Berenguer Blasi, Brandon Williams, Brandon Williams (was:
Berenguer Blasi, Brandon Williams)
Status: Review In Progress (was: Patch Available)
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:829)
> {code}
> This Cassandra logic was
[jira] [Commented] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843772#comment-17843772
]
Brandon Williams commented on CASSANDRA-19557:
--
5.0 under j11 had some timeouts but hit the concurrency limit and they didn't
fail under j17 so I don't think they are concerning. j17 also hit
CASSANDRA-19612.
trunk under j11 hit CASSANDRA-19601, CASSANDRA-19279 and a timeout that didn't
recur. j17 also encountered CASSANDRA-19601, CASSANDRA-18098, and a timeout
under the concurrency limit.
None of this is a concern, and I am +1 here but unfortunately could not
convince myself (as much as I would like to) that this is a bug to fix from
3.11 forward. That said, I will begin committing to 5.0.
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
>
[jira] [Updated] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19565:
-
Reviewers: Berenguer Blasi (was: Berenguer Blasi, Brandon Williams)
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Thomas De Keulenaer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.14, 4.1.6, 5.0-beta2, 5.0, 5.1
>
> Attachments: cassandra_57_debian_jdk11_amd64_attempt1.log.xz,
> cassandra_57_redhat_jdk11_amd64_attempt1.log.xz, hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19565:
-
Fix Version/s: 4.0.14
4.1.6
5.0-beta2
5.0
5.1
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
(was: 5.0.x)
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/f12f928dee2291d0ca98a20c788d545e6ffb623b
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks for the review!
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Thomas De Keulenaer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.14, 4.1.6, 5.0-beta2, 5.0, 5.1
>
> Attachments: cassandra_57_debian_jdk11_amd64_attempt1.log.xz,
> cassandra_57_redhat_jdk11_amd64_attempt1.log.xz, hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19565:
-
Status: Ready to Commit (was: Review In Progress)
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Thomas De Keulenaer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: cassandra_57_debian_jdk11_amd64_attempt1.log.xz,
> cassandra_57_redhat_jdk11_amd64_attempt1.log.xz, hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19565:
-
Reviewers: Berenguer Blasi, Brandon Williams (was: Berenguer Blasi)
Status: Review In Progress (was: Patch Available)
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Thomas De Keulenaer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: cassandra_57_debian_jdk11_amd64_attempt1.log.xz,
> cassandra_57_redhat_jdk11_amd64_attempt1.log.xz, hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19565:
-
Fix Version/s: 4.0.x
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Thomas De Keulenaer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: cassandra_57_debian_jdk11_amd64_attempt1.log.xz,
> cassandra_57_redhat_jdk11_amd64_attempt1.log.xz, hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843565#comment-17843565
]
Brandon Williams commented on CASSANDRA-19565:
--
CI completed successfully, [~bereng] can you find time to take one last look?
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Thomas De Keulenaer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: cassandra_57_debian_jdk11_amd64_attempt1.log.xz,
> cassandra_57_redhat_jdk11_amd64_attempt1.log.xz, hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843369#comment-17843369
]
Brandon Williams commented on CASSANDRA-19557:
--
Running CI:
||Branch||CI||
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19557-5.0]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1619/workflows/9150003c-b1f3-48e3-a6d1-cca4b9844660],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1619/workflows/c57d97b6-bc23-4456-a4ad-2cce22174edd]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19557-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1618/workflows/43bf05a7-8a4a-4a71-88b0-bf94fe586b78],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1618/workflows/1071e4e7-d04d-40a5-9646-7b9bf6ed251e]|
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
>
[jira] [Commented] (CASSANDRA-19534) unbounded queues in native transport requests lead to node instability
[
https://issues.apache.org/jira/browse/CASSANDRA-19534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843358#comment-17843358
]
Brandon Williams commented on CASSANDRA-19534:
--
[~rustyrazorblade] the parameter is actually 'native_transport_timeout' (with a
unit in your value) and the others already default to what you set.
> unbounded queues in native transport requests lead to node instability
> --
>
> Key: CASSANDRA-19534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19534
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Jon Haddad
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Attachments: Scenario 1 - QUEUE + Backpressure.jpg, Scenario 1 -
> QUEUE.jpg, Scenario 1 - Stock.jpg, Scenario 2 - QUEUE + Backpressure.jpg,
> Scenario 2 - QUEUE.jpg, Scenario 2 - Stock.jpg, ci_summary.html
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a node is under pressure, hundreds of thousands of requests can show up
> in the native transport queue, and it looks like it can take way longer to
> timeout than is configured. We should be shedding load much more
> aggressively and use a bounded queue for incoming work. This is extremely
> evident when we combine a resource consuming workload with a smaller one:
> Running 5.0 HEAD on a single node as of today:
> {noformat}
> # populate only
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --maxrlat 100 --populate
> 10m --rate 50k -n 1
> # workload 1 - larger reads
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --rate 200 -d 1d
> # second workload - small reads
> easy-cass-stress run KeyValue -p 1m --rate 20k -r .5 -d 24h{noformat}
> It appears our results don't time out at the requested server time either:
>
> {noformat}
> Writes Reads
> Deletes Errors
> Count Latency (p99) 1min (req/s) | Count Latency (p99) 1min (req/s) |
> Count Latency (p99) 1min (req/s) | Count 1min (errors/s)
> 950286 70403.93 634.77 | 789524 70442.07 426.02 |
> 0 0 0 | 9580484 18980.45
> 952304 70567.62 640.1 | 791072 70634.34 428.36 |
> 0 0 0 | 9636658 18969.54
> 953146 70767.34 640.1 | 791400 70767.76 428.36 |
> 0 0 0 | 9695272 18969.54
> 956833 71171.28 623.14 | 794009 71175.6 412.79 |
> 0 0 0 | 9749377 19002.44
> 959627 71312.58 656.93 | 795703 71349.87 435.56 |
> 0 0 0 | 9804907 18943.11{noformat}
>
> After stopping the load test altogether, it took nearly a minute before the
> requests were no longer queued.
--
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-19557) ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per every read row
[
https://issues.apache.org/jira/browse/CASSANDRA-19557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19557:
-
Complexity: Normal
Fix Version/s: 5.0.x
5.x
Severity: Normal
Assignee: Dmitry Konstantinov
Status: Open (was: Triage Needed)
> ShallowIndexedEntry scenario: the same IndexInfo is read multiple times, per
> every read row
> ---
>
> Key: CASSANDRA-19557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19557
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: 19557-4.1.patch, 19557-5.0.patch
>
>
> When we read rows from a large partition stored in an SSTable and
> ShallowIndexedEntry is used - the same IndexInfo entity is read from disk
> multiple times, it happens per every read row.
> The following stacktrace shows the execution path:
> {code:java}
> at
> org.apache.cassandra.db.RowIndexEntry$ShallowInfoRetriever.fetchIndex(RowIndexEntry.java:742)
> at
> org.apache.cassandra.db.RowIndexEntry$FileIndexInfoRetriever.columnsIndex(RowIndexEntry.java:792)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.index(AbstractSSTableIterator.java:528)
>
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.currentIndex(AbstractSSTableIterator.java:523)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.isPastCurrentBlock(AbstractSSTableIterator.java:513)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:487)
> <=== here we retrieve the current index entry
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:290)
> <== here we iterate over rows
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:182)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:342)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:224)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:110)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:48)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:76)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:27)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:97)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:303)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:308)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1991)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2277)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:137)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:829)
> {code}
> This Cassandra logic was originally written for the case when there is a
> small
[jira] [Comment Edited] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843225#comment-17843225
]
Brandon Williams edited comment on CASSANDRA-19565 at 5/3/24 2:31 PM:
--
Ok, I fixed packaging in CASSANDRA-19606 and I've started CI runs here:
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19565-4.0]|[jenkins|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-before-5-artifacts/11/]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-19565-4.1]|[jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-artifacts/12/]|
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19565-5.0]|[jenkins|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-5/26/]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19565-trunk]|[jenkins|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-5/27/]|
I'll check back when those complete.
was (Author: brandon.williams):
Ok, I fixed packaging in CASSANDRA-19606 and I've started CI runs here:
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19565-4.0]|[jenkins|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-before-5-artifacts/11/]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-19565-4.1]|[jenkins|https://ci-cassandra.apache.org/job/Cassandra-devbranch-before-5-artifacts/12/]|
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19565-5.0]|[jenkins|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-artifacts/2739/]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19565-trunk]|[jenkins|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-artifacts/2740/]|
I'll check back when those complete.
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Thomas De Keulenaer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: cassandra_57_debian_jdk11_amd64_attempt1.log.xz,
> cassandra_57_redhat_jdk11_amd64_attempt1.log.xz, hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19614) Add java version to prepare_release.sh human check step
[ https://issues.apache.org/jira/browse/CASSANDRA-19614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19614: - Fix Version/s: 3.0.31 3.11.18 4.0.13 4.1.5 5.0-beta2 5.1 (was: 3.0.x) (was: 3.11.x) (was: 5.x) (was: 4.0.x) (was: 4.1.x) (was: 5.0.x) Source Control Link: https://github.com/apache/cassandra-builds/commit/8bf8b20c8e474a1d3026bbd3cf3a4772530b33f1 Resolution: Fixed Status: Resolved (was: Ready to Commit) Thanks, committed. > Add java version to prepare_release.sh human check step > --- > > Key: CASSANDRA-19614 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19614 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.31, 3.11.18, 4.0.13, 4.1.5, 5.0-beta2, 5.1 > > > With the many versions of java one may need to float these days, it would be > nice for prepare_release.sh to show the version you are using when it asks > the "Is this what you want?" question showing the latest commit, that way > there is a chance to correct things before it tags. -- 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-19614) Add java version to prepare_release.sh human check step
[ https://issues.apache.org/jira/browse/CASSANDRA-19614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19614: - Reviewers: Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > Add java version to prepare_release.sh human check step > --- > > Key: CASSANDRA-19614 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19614 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > With the many versions of java one may need to float these days, it would be > nice for prepare_release.sh to show the version you are using when it asks > the "Is this what you want?" question showing the latest commit, that way > there is a chance to correct things before it tags. -- 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-19614) Add java version to prepare_release.sh human check step
[ https://issues.apache.org/jira/browse/CASSANDRA-19614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19614: - Status: Ready to Commit (was: Review In Progress) > Add java version to prepare_release.sh human check step > --- > > Key: CASSANDRA-19614 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19614 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > With the many versions of java one may need to float these days, it would be > nice for prepare_release.sh to show the version you are using when it asks > the "Is this what you want?" question showing the latest commit, that way > there is a chance to correct things before it tags. -- 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-19614) Add java version to prepare_release.sh human check step
[ https://issues.apache.org/jira/browse/CASSANDRA-19614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19614: - Change Category: Operability Complexity: Low Hanging Fruit Component/s: Build Fix Version/s: 3.0.x 3.11.x 4.0.x 4.1.x 5.0.x 5.x Assignee: Brandon Williams Status: Open (was: Triage Needed) > Add java version to prepare_release.sh human check step > --- > > Key: CASSANDRA-19614 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19614 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > With the many versions of java one may need to float these days, it would be > nice for prepare_release.sh to show the version you are using when it asks > the "Is this what you want?" question showing the latest commit, that way > there is a chance to correct things before it tags. -- 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-19614) Add java version to prepare_release.sh human check step
[ https://issues.apache.org/jira/browse/CASSANDRA-19614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843021#comment-17843021 ] Brandon Williams commented on CASSANDRA-19614: -- Simple patch to do this [here|https://github.com/driftx/cassandra-builds/tree/CASSANDRA-19614]. > Add java version to prepare_release.sh human check step > --- > > Key: CASSANDRA-19614 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19614 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > With the many versions of java one may need to float these days, it would be > nice for prepare_release.sh to show the version you are using when it asks > the "Is this what you want?" question showing the latest commit, that way > there is a chance to correct things before it tags. -- 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-19614) Add java version to prepare_release.sh human check step
[ https://issues.apache.org/jira/browse/CASSANDRA-19614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19614: - Test and Documentation Plan: manual Status: Patch Available (was: Open) > Add java version to prepare_release.sh human check step > --- > > Key: CASSANDRA-19614 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19614 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > With the many versions of java one may need to float these days, it would be > nice for prepare_release.sh to show the version you are using when it asks > the "Is this what you want?" question showing the latest commit, that way > there is a chance to correct things before it tags. -- 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-19612) flaky IntersectFilteringQueryTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843000#comment-17843000
]
Brandon Williams commented on CASSANDRA-19612:
--
LGTM, +1 when CI is happy.
> flaky IntersectFilteringQueryTest
> -
>
> Key: CASSANDRA-19612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19612
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Stefan Miklosovic
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I start to see flaky IntersectFilteringQueryTest both in 5.0 and trunk.
>
> {code:java}
>
> org.apache.cassandra.distributed.test.guardrails.IntersectFilteringQueryTest
> shouldNotWarnOrFailOnIndexQuery
> com.datastax.driver.core.exceptions.ReadFailureException: Cassandra
> failure during read query at consistency QUORUM (2 responses were required
> but only 1 replica responded, 1 failed)
> at
> com.datastax.driver.core.exceptions.ReadFailureException.copy(ReadFailureException.java:180)
> at
> com.datastax.driver.core.exceptions.ReadFailureException.copy(ReadFailureException.java:30)
> at
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:35)
> at
> com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:293)
> at
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:58)
> at
> org.apache.cassandra.distributed.test.guardrails.GuardrailTester.executeViaDriver(GuardrailTester.java:92)
> at
> org.apache.cassandra.distributed.test.guardrails.IntersectFilteringQueryTest.shouldNotWarnOrFailOnIndexQuery(IntersectFilteringQueryTest.java:115)
> 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)
> Caused by: com.datastax.driver.core.exceptions.ReadFailureException:
> Cassandra failure during read query at consistency QUORUM (2 responses were
> required but only 1 replica responded, 1 failed)
> at
> com.datastax.driver.core.exceptions.ReadFailureException.copy(ReadFailureException.java:192)
> at
> com.datastax.driver.core.Responses$Error.asException(Responses.java:181)
> {code}
>
> It most probably needs a little bit more love and run it through multiplexer
> maybe?
--
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-19614) Add java version to prepare_release.sh human check step
Brandon Williams created CASSANDRA-19614: Summary: Add java version to prepare_release.sh human check step Key: CASSANDRA-19614 URL: https://issues.apache.org/jira/browse/CASSANDRA-19614 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams With the many versions of java one may need to float these days, it would be nice for prepare_release.sh to show the version you are using when it asks the "Is this what you want?" question showing the latest commit, that way there is a chance to correct things before it tags. -- 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-19612) flaky IntersectFilteringQueryTest
[
https://issues.apache.org/jira/browse/CASSANDRA-19612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19612:
-
Fix Version/s: 5.0.x
5.x
(was: 5.0)
(was: 5.1)
> flaky IntersectFilteringQueryTest
> -
>
> Key: CASSANDRA-19612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19612
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Stefan Miklosovic
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> I start to see flaky IntersectFilteringQueryTest both in 5.0 and trunk.
>
> {code:java}
>
> org.apache.cassandra.distributed.test.guardrails.IntersectFilteringQueryTest
> shouldNotWarnOrFailOnIndexQuery
> com.datastax.driver.core.exceptions.ReadFailureException: Cassandra
> failure during read query at consistency QUORUM (2 responses were required
> but only 1 replica responded, 1 failed)
> at
> com.datastax.driver.core.exceptions.ReadFailureException.copy(ReadFailureException.java:180)
> at
> com.datastax.driver.core.exceptions.ReadFailureException.copy(ReadFailureException.java:30)
> at
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:35)
> at
> com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:293)
> at
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:58)
> at
> org.apache.cassandra.distributed.test.guardrails.GuardrailTester.executeViaDriver(GuardrailTester.java:92)
> at
> org.apache.cassandra.distributed.test.guardrails.IntersectFilteringQueryTest.shouldNotWarnOrFailOnIndexQuery(IntersectFilteringQueryTest.java:115)
> 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)
> Caused by: com.datastax.driver.core.exceptions.ReadFailureException:
> Cassandra failure during read query at consistency QUORUM (2 responses were
> required but only 1 replica responded, 1 failed)
> at
> com.datastax.driver.core.exceptions.ReadFailureException.copy(ReadFailureException.java:192)
> at
> com.datastax.driver.core.Responses$Error.asException(Responses.java:181)
> {code}
>
> It most probably needs a little bit more love and run it through multiplexer
> maybe?
--
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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19606:
-
Fix Version/s: 3.0.31
3.11.18
4.0.13
4.1.5
5.0-beta2
5.1
(was: 3.0.x)
(was: 3.11.x)
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
(was: 5.0.x)
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra-builds/commit/4ec20b6979cb97ce5b8f1ecb817cf22ecf92bcae
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thank you for the review!
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.31, 3.11.18, 4.0.13, 4.1.5, 5.0-beta2, 5.1
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19606:
-
Reviewers: Stefan Miklosovic
Status: Review In Progress (was: Needs Committer)
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19606:
-
Status: Ready to Commit (was: Review In Progress)
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19606:
-
Status: Needs Committer (was: Patch Available)
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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] [Comment Edited] (CASSANDRA-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842826#comment-17842826
]
Brandon Williams edited comment on CASSANDRA-19606 at 5/2/24 2:42 AM:
--
Updated severity since we can't propose releases without this working.
was (Author: brandon.williams):
Updated severity since we can't propose 4.x releases without this working.
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842826#comment-17842826
]
Brandon Williams commented on CASSANDRA-19606:
--
Updated severity since we can't propose 4.x releases without this working.
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19606:
-
Severity: Critical (was: Normal)
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842825#comment-17842825 ] Brandon Williams commented on CASSANDRA-19578: -- 4.x releases have been on my radar for weeks, and now the various pieces (this being one) have nearly come together. > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > Fix For: 4.1.5, 5.0-beta2 > > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. > Only impacts 4.1 > test and fix : > https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842768#comment-17842768
]
Brandon Williams commented on CASSANDRA-19606:
--
I'm not sure how (if?) the build is working >= 5.0 since it too seems like it
would pull ed from the sid repo. So yes, I think we should add that there, and
this fix will prevent failures in the future, if those potential failures lie
with ed. To solve this more properly we could set up apt pinning and then only
pull what we need (java) from sid. Right now anything we pull after adding the
sid repo comes from there. Setting that up is a bit more involved though.
[Here|https://github.com/driftx/cassandra/tree/CASSANDRA-19606-5.0] is a branch
for the in-tree image.
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842760#comment-17842760
]
Brandon Williams commented on CASSANDRA-19606:
--
The root of the problem is that 'ed' is broken in sid/unstable:
{noformat}
$ sudo apt install ed
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
libc-devtools libgd3 libnsl-dev libtiff5 libtirpc-dev libwebp6
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
ed
0 upgraded, 1 newly installed, 0 to remove and 424 not upgraded.
Need to get 60.8 kB of archives.
After this operation, 113 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian sid/main amd64 ed amd64 1.20.2-2 [60.8 kB]
Fetched 60.8 kB in 0s (370 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package ed.
(Reading database ... 34230 files and directories currently installed.)
Preparing to unpack .../archives/ed_1.20.2-2_amd64.deb ...
Unpacking ed (1.20.2-2) ...
Setting up ed (1.20.2-2) ...
update-alternatives: error: alternative path /bin/ed doesn't exist
dpkg: error processing package ed (--configure):
installed ed package post-installation script subprocess returned error exit
status 2
Processing triggers for man-db (2.9.4-2) ...
Errors were encountered while processing:
ed
E: Sub-process /usr/bin/dpkg returned an error code (1)
{noformat}
We don't have apt pinning setup so we can't specify to pull ed from bullseye,
but that is difficult anyway since we are using mk-build-deps and then
installing the resulting dummy package to get the deps. That leaves us with
the simplest thing to do being to install ed before we add the sid repo for
java, which I've done
[here|https://github.com/driftx/cassandra-builds/commit/8146ddb5740308400d0f7870185513c88bdf115c].
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19606:
-
Test and Documentation Plan: build packages
Status: Patch Available (was: Open)
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19606:
-
Bug Category: Parent values: Availability(12983)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 3.0.x
3.11.x
4.0.x
4.1.x
5.0.x
5.x
Severity: Normal
Assignee: Brandon Williams
Status: Open (was: Triage Needed)
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {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-19606) Fix building debian packages
Brandon Williams created CASSANDRA-19606:
Summary: Fix building debian packages
Key: CASSANDRA-19606
URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
Project: Cassandra
Issue Type: Bug
Components: CI
Reporter: Brandon Williams
Trying to run cassandra-deb-packaging.sh will result in the docker image
looping:
{noformat}
Errors were encountered while processing:
ed
quilt
cassandra-build-deps
E: Sub-process /usr/bin/dpkg returned an error code (1)
(Reading database ... 36721 files and directories currently installed.)
Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
mk-build-deps: Unable to install all build-dep packages
mk-build-deps failed… trying again after 10s…
{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-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842718#comment-17842718
]
Brandon Williams commented on CASSANDRA-19401:
--
I see. I'm not crazy about sleeping but I don't see a better path currently.
+1
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the keyspace and table are specified on the command line for nodetool
> import, there is not the same requirement as with sstableloader, to have the
> SSTables in a specific directory path. When importing snapshots or
> incremental backups with nodetool import, the SSTables don’t need to be
> copied to another directory.
> {quote}
> However when importing old cassandra snapshots, we figured out, that sstables
> still need to be in a directory called like $KEYSPACE/$TABLENAME files, even
> when keyspace and table name are already present as parameters for the
> nodetool import call.
> Call we used:
> {code}
> nodetool import --copy-data mykeyspace mytable /full_path_to/test1
> {code}
> Log:
> {code}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,565
> SSTableImporter.java:72 - Loading new SSTables for mykeyspace/mytable:
> Options{srcPaths='[/full_path_to/test1]', resetLevel=true,
> clearRepaired=true, verifySSTables=true, verifyTokens=true,
> invalidateCaches=true, extendedVerify=false, copyData= true}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,566
> SSTableImporter.java:173 - No new SSTables were found for mykeyspace/mytable
> {code}
> However, when we move the sstables (.db-Files) to
> {{alternative/mykeyspace/mytable}}
> and import with
> {code}
> nodetool import --copy-data mykeyspace mytable
> /fullpath/alternative/mykeyspace/mytable
> {code}
> the import works
> {code}
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:177 - Loading new SSTables and building secondary
> indexes for mykeyspace/mytable:
> [BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-2-big-Data.db'),
>
> BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-1-big-Data.db')]
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:190 - Done loading load new SSTables for
> mykeyspace/mytable
> {code}
> We experienced this in Cassandra 4.1.3 on Java 11 (Linux)
--
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-19401) Nodetool import expects directory structure
[
https://issues.apache.org/jira/browse/CASSANDRA-19401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842693#comment-17842693
]
Brandon Williams commented on CASSANDRA-19401:
--
bq. added 2s sleep also seem to improve the non-flakiness of the other test
across the branches.
Can you explain what you mean here? Do we know why 2s is needed?
> Nodetool import expects directory structure
> ---
>
> Key: CASSANDRA-19401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19401
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Norbert Schultz
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> According to the
> [documentation|https://cassandra.apache.org/doc/4.1/cassandra/operating/bulk_loading.html]
> the nodetool import should not rely on the folder structure of the imported
> sst files:
> {quote}
> Because the keyspace and table are specified on the command line for nodetool
> import, there is not the same requirement as with sstableloader, to have the
> SSTables in a specific directory path. When importing snapshots or
> incremental backups with nodetool import, the SSTables don’t need to be
> copied to another directory.
> {quote}
> However when importing old cassandra snapshots, we figured out, that sstables
> still need to be in a directory called like $KEYSPACE/$TABLENAME files, even
> when keyspace and table name are already present as parameters for the
> nodetool import call.
> Call we used:
> {code}
> nodetool import --copy-data mykeyspace mytable /full_path_to/test1
> {code}
> Log:
> {code}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,565
> SSTableImporter.java:72 - Loading new SSTables for mykeyspace/mytable:
> Options{srcPaths='[/full_path_to/test1]', resetLevel=true,
> clearRepaired=true, verifySSTables=true, verifyTokens=true,
> invalidateCaches=true, extendedVerify=false, copyData= true}
> INFO [RMI TCP Connection(21)-127.0.0.1] 2024-02-15 10:41:06,566
> SSTableImporter.java:173 - No new SSTables were found for mykeyspace/mytable
> {code}
> However, when we move the sstables (.db-Files) to
> {{alternative/mykeyspace/mytable}}
> and import with
> {code}
> nodetool import --copy-data mykeyspace mytable
> /fullpath/alternative/mykeyspace/mytable
> {code}
> the import works
> {code}
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:177 - Loading new SSTables and building secondary
> indexes for mykeyspace/mytable:
> [BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-2-big-Data.db'),
>
> BigTableReader(path='/mnt/ramdisk/cassandra4/data/mykeyspace/mytable-561a12d0cbe611eead78fbfd293cee40/me-1-big-Data.db')]
> INFO [RMI TCP Connection(23)-127.0.0.1] 2024-02-15 10:43:36,093
> SSTableImporter.java:190 - Done loading load new SSTables for
> mykeyspace/mytable
> {code}
> We experienced this in Cassandra 4.1.3 on Java 11 (Linux)
--
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-19580) Unable to contact any seeds with node in hibernate status
[
https://issues.apache.org/jira/browse/CASSANDRA-19580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842690#comment-17842690
]
Brandon Williams commented on CASSANDRA-19580:
--
bq. My test was with all.
You're right, this got fixed at some point. I added a dtest for replacing with
the same address and compression
[here|https://github.com/driftx/cassandra-dtest/commit/fae1ee2a8b128afc4b544570ef2a650ba096cb5d]
and it passes.
Most of what you've described here are implementation details of how replace
works, like how hibernate is handled, so I'm not sure if anything is wrong.
> Unable to contact any seeds with node in hibernate status
> -
>
> Key: CASSANDRA-19580
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19580
> Project: Cassandra
> Issue Type: Bug
>Reporter: Cameron Zemek
>Priority: Normal
>
> We have customer running into the error 'Unable to contact any seeds!' . I
> have been able to reproduce this issue if I kill Cassandra as its joining
> which will put the node into hibernate status. Once a node is in hibernate it
> will no longer receive any SYN messages from other nodes during startup and
> as it sends only itself as digest in outbound SYN messages it never receives
> any states in any of the ACK replies. So once it gets to the check
> `seenAnySeed` in it fails as the endpointStateMap is empty.
>
> A workaround is copying the system.peers table from other node but this is
> less than ideal. I tested modifying maybeGossipToSeed as follows:
> {code:java}
> /* Possibly gossip to a seed for facilitating partition healing */
> private void maybeGossipToSeed(MessageOut prod)
> {
> int size = seeds.size();
> if (size > 0)
> {
> if (size == 1 &&
> seeds.contains(FBUtilities.getBroadcastAddress()))
> {
> return;
> }
> if (liveEndpoints.size() == 0)
> {
> List gDigests = prod.payload.gDigests;
> if (gDigests.size() == 1 &&
> gDigests.get(0).endpoint.equals(FBUtilities.getBroadcastAddress()))
> {
> gDigests = new ArrayList();
> GossipDigestSyn digestSynMessage = new
> GossipDigestSyn(DatabaseDescriptor.getClusterName(),
>
> DatabaseDescriptor.getPartitionerName(),
>
> gDigests);
> MessageOut message = new
> MessageOut(MessagingService.Verb.GOSSIP_DIGEST_SYN,
>
> digestSynMessage,
>
> GossipDigestSyn.serializer);
> sendGossip(message, seeds);
> }
> else
> {
> sendGossip(prod, seeds);
> }
> }
> else
> {
> /* Gossip with the seed with some probability. */
> double probability = seeds.size() / (double)
> (liveEndpoints.size() + unreachableEndpoints.size());
> double randDbl = random.nextDouble();
> if (randDbl <= probability)
> sendGossip(prod, seeds);
> }
> }
> }
> {code}
> Only problem is this is the same as SYN from shadow round. It does resolve
> the issue however as then receive an ACK with all the states.
--
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-15439) Token metadata for bootstrapping nodes is lost under temporary failures
[
https://issues.apache.org/jira/browse/CASSANDRA-15439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842676#comment-17842676
]
Brandon Williams commented on CASSANDRA-15439:
--
I saw that, but what blocks us here is needing another committer to review and
+1.
> Token metadata for bootstrapping nodes is lost under temporary failures
> ---
>
> Key: CASSANDRA-15439
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15439
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Josh Snyder
>Assignee: Raymond Huffman
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In CASSANDRA-8838, [~pauloricardomg] asked "hints will not be stored to the
> bootstrapping node after RING_DELAY, since it will evicted from the TMD
> pending ranges. Should we create a ticket to address this?"
> CASSANDRA-15264 relates to the most likely cause of such situations, where
> the Cassandra daemon on the bootstrapping node completely crashes. Based on
> testing with {{kill -STOP}} on a bootstrapping Cassandra JVM, I believe it
> also is possible to remove token metadata (and thus pending ranges, and thus
> hints) for a bootstrapping node, simply by affecting its status in the
> failure detector.
> A node in the cluster sees the bootstrapping node this way:
> {noformat}
> INFO [GossipStage:1] 2019-11-27 20:41:41,101 Gossiper.java: - Node
> /PUBLIC-IP is now part of the cluster
> INFO [GossipStage:1] 2019-11-27 20:41:41,199 Gossiper.java:1073 -
> InetAddress /PUBLIC-IP is now UP
> INFO [HANDSHAKE-/PRIVATE-IP] 2019-11-27 20:41:41,412
> OutboundTcpConnection.java:565 - Handshaking version with /PRIVATE-IP
> INFO [STREAM-INIT-/PRIVATE-IP:21233] 2019-11-27 20:42:10,019
> StreamResultFuture.java:112 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4
> ID#0] Creating new streaming plan for Bootstrap
> INFO [STREAM-INIT-/PRIVATE-IP:21233] 2019-11-27 20:42:10,020
> StreamResultFuture.java:119 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4,
> ID#0] Received streaming plan for Bootstrap
> INFO [STREAM-INIT-/PRIVATE-IP:56003] 2019-11-27 20:42:10,112
> StreamResultFuture.java:119 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4,
> ID#0] Received streaming plan for Bootstrap
> INFO [STREAM-IN-/PUBLIC-IP] 2019-11-27 20:42:10,179
> StreamResultFuture.java:169 - [Stream #6219a950-1156-11ea-b45d-4d30364576c4
> ID#0] Prepare completed. Receiving 0 files(0 bytes), sending 833
> files(139744616815 bytes)
> INFO [GossipStage:1] 2019-11-27 20:54:47,547 Gossiper.java:1089 -
> InetAddress /PUBLIC-IP is now DOWN
> INFO [GossipTasks:1] 2019-11-27 20:54:57,551 Gossiper.java:849 - FatClient
> /PUBLIC-IP has been silent for 3ms, removing from gossip
> {noformat}
> Since the bootstrapping node has no tokens, it is treated like a fat client,
> and it is removed from the ring. For correctness purposes, I believe we must
> keep storing hints for the downed bootstrapping node until it is either
> assassinated or until a replacement attempts to bootstrap for the same token.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842667#comment-17842667
]
Brandon Williams commented on CASSANDRA-19565:
--
As I went to commit this, it occurred to me we should go ahead and take this
opportunity to achieve parity with the Debian package from 4.0 onward, and not
create the commitlog, data, etc dirs that tie the packaging to the application,
since we now have correct ownership/perms on the home directory. I have done
this
[here|https://github.com/driftx/cassandra/commit/2f86759d4a3a88e321d0f4232bd132bb9424d699]
but now packaging CI for 4.x is broken so I'll have to sort that first.
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Thomas De Keulenaer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: cassandra_57_debian_jdk11_amd64_attempt1.log.xz,
> cassandra_57_redhat_jdk11_amd64_attempt1.log.xz, hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19578: - Fix Version/s: 4.1.5 5.0-beta2 (was: 4.1.x) (was: 5.0.x) Source Control Link: https://github.com/apache/cassandra/commit/a6e80317ded9cbb500ce68e7d3fb91b5fbcb5e48 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thanks! > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > Fix For: 4.1.5, 5.0-beta2 > > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. > Only impacts 4.1 > test and fix : > https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19578: - Reviewers: Brandon Williams, Jordan West (was: Brandon Williams, Brandon Williams, Jordan West) > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > Fix For: 4.1.x, 5.0.x > > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. > Only impacts 4.1 > test and fix : > https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19578: - Status: Ready to Commit (was: Review In Progress) > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > Fix For: 4.1.x, 5.0.x > > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. > Only impacts 4.1 > test and fix : > https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19578: - Reviewers: Brandon Williams, Jordan West, Brandon Williams Brandon Williams, Jordan West, Brandon Williams (was: Brandon Williams, Brandon Williams, Jordan West) Status: Review In Progress (was: Patch Available) > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > Fix For: 4.1.x, 5.0.x > > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. > Only impacts 4.1 > test and fix : > https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19578: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > Fix For: 4.1.x, 5.0.x > > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. > Only impacts 4.1 > test and fix : > https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-19578: Assignee: Chris Lohfink > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > Fix For: 4.1.x, 5.0.x > > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. > Only impacts 4.1 > test and fix : > https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842448#comment-17842448 ] Brandon Williams commented on CASSANDRA-19578: -- 4.1 ran into CASSANDRA-17928 and 5.0 hit CASSANDRA-17798 and encountered a timeout on IntersectFilteringQueryTest which passes locally, otherwise this is clean. I am +1 here; [~jwest] [~clohfink] if one or both of you are good with the fix and 5.0, we can commit. > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Priority: Normal > Fix For: 4.1.x, 5.0.x > > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. > Only impacts 4.1 > test and fix : > https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
