[jira] [Updated] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18712: -- Status: Changes Suggested (was: Review In Progress) > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (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-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847146#comment-17847146
]
Stefan Miklosovic commented on CASSANDRA-18712:
---
Oh well, so there are failures when upgrading to this version. It is all in the
respective logs.
I think it is not just about bumping the versions ... Naively bumping it
compiles but tests are failing.
The failure is something like this:
{noformat}
failed on teardown with "Unexpected error found in node logs (see stdout for
full details). Errors: [[node1] "WARN [RMI TCP Connection(2)-127.0.0.1]
2024-05-16 13:47:46,320 Slf4jExceptionHandler.java:50 - You've configured your
queue to use a deprecated RollCycle
(net.openhft.chronicle.queue.RollCycles.TEST_SECONDLY) please consider
switching to
net.openhft.chronicle.queue.rollcycles.TestRollCycles.TEST_SECONDLY, as the
RollCycle constant you've nominated will be removed in a future release!"]"
{noformat}
[CASSANDRA-18712|https://github.com/instaclustr/cassandra/tree/CASSANDRA-18712]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 30s
✓ j17_cqlsh_dtests_py311 6m 57s
✓ j17_cqlsh_dtests_py311_vnode 7m 18s
✓ j17_cqlsh_dtests_py387m 17s
✓ j17_cqlsh_dtests_py38_vnode 7m 20s
✓ j17_cqlshlib_cython_tests8m 15s
✓ j17_cqlshlib_tests 6m 42s
✓ j17_jvm_dtests_latest_vnode 21m 0s
✓ j17_unit_tests 14m 12s
✓ j17_utests_oa13m 5s
✕ j17_dtests 36m 30s
auditlog_test.TestAuditlog test_archive_on_shutdown
auditlog_test.TestAuditlog test_archive_on_startup
auditlog_test.TestAuditlog test_archiving
auditlog_test.TestAuditlog test_archiving_fql
auditlog_test.TestAuditlog test_fql_nodetool_options
fqltool_test.TestFQLTool test_compare
fqltool_test.TestFQLTool test_compare_mismatch
fqltool_test.TestFQLTool test_jvmdtest
fqltool_test.TestFQLTool test_replay
fqltool_test.TestFQLTool test_unclean_enable
✕ j17_dtests_latest 36m 43s
auditlog_test.TestAuditlog test_archive_on_shutdown
auditlog_test.TestAuditlog test_archive_on_startup
auditlog_test.TestAuditlog test_archiving
auditlog_test.TestAuditlog test_archiving_fql
auditlog_test.TestAuditlog test_fql_nodetool_options
fqltool_test.TestFQLTool test_compare
fqltool_test.TestFQLTool test_compare_mismatch
fqltool_test.TestFQLTool test_jvmdtest
fqltool_test.TestFQLTool test_replay
configuration_test.TestConfiguration test_change_durable_writes
fqltool_test.TestFQLTool test_unclean_enable
✕ j17_dtests_vnode38m 20s
auditlog_test.TestAuditlog test_archive_on_shutdown
auditlog_test.TestAuditlog test_archive_on_startup
auditlog_test.TestAuditlog test_archiving
auditlog_test.TestAuditlog test_archiving_fql
auditlog_test.TestAuditlog test_fql_nodetool_options
fqltool_test.TestFQLTool test_compare
fqltool_test.TestFQLTool test_compare_mismatch
fqltool_test.TestFQLTool test_jvmdtest
fqltool_test.TestFQLTool test_replay
fqltool_test.TestFQLTool test_unclean_enable
✕ j17_jvm_dtests 22m 57s
✕ j17_utests_latest 14m 25s
org.apache.cassandra.net.ConnectionTest testTimeout
java17_separate_tests
java11_pre-commit_tests
✓ j11_build7m 33s
✓ j11_cqlsh_dtests_py311 8m 26s
✓ j11_cqlsh_dtests_py311_vnode 8m 8s
✓ j11_cqlsh_dtests_py388m 29s
✓ j11_cqlsh_dtests_py38_vnode 10m 33s
✓ j11_cqlshlib_cython_tests11m 8s
✓ j11_cqlshlib_tests 11m 39s
✓ j11_jvm_dtests 27m 21s
✓ j11_jvm_dtests_latest_vnode 21m 8s
✓ j11_unit_tests 17m 33s
✓ j11_utests_oa 18m 53s
✓ j11_utests_system_keyspace_directory18m 43s
✓ j17_cqlsh_dtests_py311 6m 51s
✓ j17_cqlsh_dtests_py311_vnode 7m 20s
✓ j17_cqlsh_dtests_py38 7m 6s
✓ j17_cqlsh_dtests_py38_vnode 7m 33s
✓ j17_cqlshlib_cython_tests7m 28s
✓ j17_cqlshlib_tests 8m 41s
✓ j17_unit_tests 14m 23s
✓ j17_utests_latest
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847145#comment-17847145 ] Stefan Miklosovic commented on CASSANDRA-19556: --- I understand your concern about chasing the last rc blocker but purely in practical terms, as long as e.g. 19534 is not merged first we have time to merge this too. I am not sure what the next steps are. Do you want me to re-iterate the necessity of merging this on the ML in the respective mailing list thread? > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-java-driver) branch 4.x updated: ninja-fix updating repo for releases
This is an automated email from the ASF dual-hosted git repository. absurdfarce pushed a commit to branch 4.x in repository https://gitbox.apache.org/repos/asf/cassandra-java-driver.git The following commit(s) were added to refs/heads/4.x by this push: new ac4523363 ninja-fix updating repo for releases ac4523363 is described below commit ac452336356c30b125524f31dfa82cf8a465d716 Author: absurdfarce AuthorDate: Thu May 16 20:55:25 2024 -0500 ninja-fix updating repo for releases --- pom.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pom.xml b/pom.xml index 7decc9663..b4102b338 100644 --- a/pom.xml +++ b/pom.xml @@ -755,7 +755,7 @@ limitations under the License.]]> true ossrh - https://oss.sonatype.org/ + https://repository.apache.org/ false true - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19617) Paxos may re-distribute stale commits that predate a collectable tombstone
[
https://issues.apache.org/jira/browse/CASSANDRA-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847118#comment-17847118
]
Jeremiah Jordan commented on CASSANDRA-19617:
-
Where are we at with this? It is the final ticket blocking releases at the
moment.
> Paxos may re-distribute stale commits that predate a collectable tombstone
> --
>
> Key: CASSANDRA-19617
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19617
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Note: this bug only affects {{paxos_state_purging: {gc_grace, repaired}}},
> i.e. those introduced alongside Paxos v2.
> There are two problems:
> 1) Purging is applied only on compaction, not on load, which can lead to very
> old commits being resurfaced in certain circumstances
> 2) PaxosPrepare does not filter commits based on paxos repair low bound
> This permits surprising situations to arise, where some replicas purge a
> stale commit _and all newer commits_, but due to compaction peculiarities
> some other replica may purge only the newer commits, leaving a stale commit
> in some compaction "purgatory"\[1] to be returned to reads indefinitely.
> So long as there are no newer commits, the paxos coordinator will see this
> commit is not universally known and redistribute it - no matter how old it
> is. This can permit an insert to be reapplied after GC grace has elapsed and
> the tombstone has been collected.
> For proposals this is not a problem, as we correctly filter proposals based
> on the last paxos repair time. This also does not affect clusters with the
> legacy (and default) paxos state purging using TTL. Problem (1) only applies
> also to the new {{gc_grace}} compatibility mode for purging.
> \[1] Compaction purgatory can arise for instance because paxos purging allows
> whole sstables to be erased quite effectively, and if this is able to
> ordinarily prevent sstables being promoted to L1, then if for some abnormal
> reason sstables reach L1 (e.g. repairs being disabled for some time), those
> that collect may remain uncompacted for an extended period without purging
> being applied.
--
This message was sent by Atlassian Jira
(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-19617) Paxos may re-distribute stale commits that predate a collectable tombstone
[
https://issues.apache.org/jira/browse/CASSANDRA-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremiah Jordan updated CASSANDRA-19617:
Test and Documentation Plan: Patch includes tests
Status: Patch Available (was: Open)
> Paxos may re-distribute stale commits that predate a collectable tombstone
> --
>
> Key: CASSANDRA-19617
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19617
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Note: this bug only affects {{paxos_state_purging: {gc_grace, repaired}}},
> i.e. those introduced alongside Paxos v2.
> There are two problems:
> 1) Purging is applied only on compaction, not on load, which can lead to very
> old commits being resurfaced in certain circumstances
> 2) PaxosPrepare does not filter commits based on paxos repair low bound
> This permits surprising situations to arise, where some replicas purge a
> stale commit _and all newer commits_, but due to compaction peculiarities
> some other replica may purge only the newer commits, leaving a stale commit
> in some compaction "purgatory"\[1] to be returned to reads indefinitely.
> So long as there are no newer commits, the paxos coordinator will see this
> commit is not universally known and redistribute it - no matter how old it
> is. This can permit an insert to be reapplied after GC grace has elapsed and
> the tombstone has been collected.
> For proposals this is not a problem, as we correctly filter proposals based
> on the last paxos repair time. This also does not affect clusters with the
> legacy (and default) paxos state purging using TTL. Problem (1) only applies
> also to the new {{gc_grace}} compatibility mode for purging.
> \[1] Compaction purgatory can arise for instance because paxos purging allows
> whole sstables to be erased quite effectively, and if this is able to
> ordinarily prevent sstables being promoted to L1, then if for some abnormal
> reason sstables reach L1 (e.g. repairs being disabled for some time), those
> that collect may remain uncompacted for an extended period without purging
> being applied.
--
This message was sent by Atlassian Jira
(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-18732) Baseline Diagnostic vtables for Accord
[
https://issues.apache.org/jira/browse/CASSANDRA-18732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18732:
Reviewers: David Capwell
> Baseline Diagnostic vtables for Accord
> --
>
> Key: CASSANDRA-18732
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18732
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: pull-request-available
> Fix For: 5.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In addition to JMX-based metrics, there are bits of diagnostic information
> for Accord that we should consider exposing through vtables:
> 1.) We should ensure that coordinator-level CQL transactions and the local
> reads and writes they spawn are visible to the existing {{QueriesTable}}
> vtable.
> The first may already just work. We may need to make some tweaks to
> {{TxnNamedRead}} and {{TxnWrite}} for the local operations though.
> ({{CommandStore}} tasks are out of scope here, as they would probably be more
> confusing than useful in {{QueriesTable}}?)
> 2.) A new vtable for pending commands for a key.
> - Disable SELECT */require a partition key
> - Might require partial back-port of stringifying table/partition key from
> Accord to be correct
> - ex. {{SELECT timestamps FROM myawesometable where ks=? and table=? and
> partition_key=?}}
> - Clustering can be the Accord timestamp elements, no further normal columns.
> 3.) A new vtable for command store-specific cache stats
> - Gather via {{Store.execute()}} for correctness.
> - Store id should be partition key (see {{AccordCommandStore}})
> - hits, misses, total (maybe just throw out the keyspaces and coalesce
> ranges?)
> 4.) (Requires [~aweisberg]'s outstanding work) A new vtable for live
> migration state
> - {{TableMigrationState}} could be flattened into a row
> - Is this already persisted? If so, why a new vtable?
> 5.) A vtable to expose {{accord.local.Node#coordinating()}} as a map
> - ex. {{SELECT txn_id, type}}
--
This message was sent by Atlassian Jira
(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-19639) Read fail with NullPointerException after migrating data from 2.2.19 to 3.0.30
[
https://issues.apache.org/jira/browse/CASSANDRA-19639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klay updated CASSANDRA-19639:
-
Description:
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}
ERROR [SharedPool-Worker-8] 2024-05-16 22:01:55,742
AbstractLocalAwareExecutorService.java:166 - Uncaught exception on thread
Thread[SharedPool-Worker-8,10,main]
java.lang.RuntimeException: java.lang.NullPointerException
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.NullPointerException: null
at org.apache.cassandra.db.Slice$Bound.exclusiveStartOf(Slice.java:386)
at
org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:570)
at
org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:503)
at
org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:329)
at
org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.handlePreSliceData(SSTableIterator.java:105)
at
org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:164)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:336)
at
org.apache.cassandra.db.Slices$ArrayBackedSlices$1.prepareNext(Slices.java:506)
at
org.apache.cassandra.db.Slices$ArrayBackedSlices$1.hasNext(Slices.java:474)
at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
at
org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:71)
at
org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDiskInternal(SinglePartitionReadCommand.java:799)
at
org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDisk(SinglePartitionReadCommand.java:654)
at
org.apache.cassandra.db.SinglePartitionReadCommand.queryStorage(SinglePartitionReadCommand.java:489)
at
org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:417)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1912)
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
{code:java}
CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
CREATE TABLE IF NOT EXISTS ks.tb (c0 TEXT,W_Col set,c2 INT,c3 INT,c4
INT,c5 set, PRIMARY KEY (c3, c2, c0, c4));
DELETE FROM ks.tb WHERE c3 = 2 AND c2 = 2;
INSERT INTO ks.tb (c5, W_Col, c0, c4, c3, c2) VALUES
({'nAA','A','AA','A','A'},{0,1,2,3,4},'A',1320973978,2,2);
DELETE FROM ks.tb WHERE c3 = 2 AND c2 = 1584505374 AND c0 = 'z';
ALTER TABLE ks.tb DROP W_Col ; {code}
3. Drain 2.2.19.
{code:java}
bin/nodetool -h :::127.0.0.1 drain
bin/nodetool -h :::127.0.0.1 stopdaemon; {code}
4. Start up 3.0.30 (with default config is enough) and execute the following
read command
{code:java}
cqlsh> SELECT * FROM ks.tb WHERE c3 = 2 AND c2 = 100;
ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read]
message="Operation failed - received 0 responses and 1 failures"
info={'failures': 1, 'received_responses': 0,
[jira] [Updated] (CASSANDRA-19639) Read fail with NullPointerException after migrating data from 2.2.19 to 3.0.30
[
https://issues.apache.org/jira/browse/CASSANDRA-19639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klay updated CASSANDRA-19639:
-
Attachment: data.tar.gz
system.log
> Read fail with NullPointerException after migrating data from 2.2.19 to 3.0.30
> --
>
> Key: CASSANDRA-19639
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19639
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Klay
>Priority: Normal
> Attachments: 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}
> ERROR [SharedPool-Worker-8] 2024-05-16 22:01:55,742
> AbstractLocalAwareExecutorService.java:166 - Uncaught exception on thread
> Thread[SharedPool-Worker-8,10,main]
> java.lang.RuntimeException: java.lang.NullPointerException
> 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.NullPointerException: null
> at
> org.apache.cassandra.db.Slice$Bound.exclusiveStartOf(Slice.java:386)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:570)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:503)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:329)
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.handlePreSliceData(SSTableIterator.java:105)
> at
> org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:164)
> at
> org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:336)
> at
> org.apache.cassandra.db.Slices$ArrayBackedSlices$1.prepareNext(Slices.java:506)
> at
> org.apache.cassandra.db.Slices$ArrayBackedSlices$1.hasNext(Slices.java:474)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:71)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDiskInternal(SinglePartitionReadCommand.java:799)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDisk(SinglePartitionReadCommand.java:654)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.queryStorage(SinglePartitionReadCommand.java:489)
> at
> org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:417)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1912)
> 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
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE IF NOT EXISTS ks.tb (c0 TEXT,W_Col set,c2 INT,c3 INT,c4
> INT,c5 set, PRIMARY KEY (c3, c2, c0, c4));
> DELETE FROM ks.tb WHERE c3 = 2 AND c2 = 2;
> INSERT INTO ks.tb (c5, W_Col, c0, c4, c3, c2) VALUES
>
[jira] [Created] (CASSANDRA-19639) Read fail with NullPointerException after migrating data from 2.2.19 to 3.0.30
Klay created CASSANDRA-19639:
Summary: Read fail with NullPointerException after migrating data
from 2.2.19 to 3.0.30
Key: CASSANDRA-19639
URL: https://issues.apache.org/jira/browse/CASSANDRA-19639
Project: Cassandra
Issue Type: Bug
Components: Legacy/Local Write-Read Paths
Reporter: Klay
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}
ERROR [SharedPool-Worker-8] 2024-05-16 22:01:55,742
AbstractLocalAwareExecutorService.java:166 - Uncaught exception on thread
Thread[SharedPool-Worker-8,10,main]
java.lang.RuntimeException: java.lang.NullPointerException
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.NullPointerException: null
at org.apache.cassandra.db.Slice$Bound.exclusiveStartOf(Slice.java:386)
at
org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:570)
at
org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:503)
at
org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:329)
at
org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.handlePreSliceData(SSTableIterator.java:105)
at
org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:164)
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:336)
at
org.apache.cassandra.db.Slices$ArrayBackedSlices$1.prepareNext(Slices.java:506)
at
org.apache.cassandra.db.Slices$ArrayBackedSlices$1.hasNext(Slices.java:474)
at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129)
at
org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:71)
at
org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDiskInternal(SinglePartitionReadCommand.java:799)
at
org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDisk(SinglePartitionReadCommand.java:654)
at
org.apache.cassandra.db.SinglePartitionReadCommand.queryStorage(SinglePartitionReadCommand.java:489)
at
org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:417)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1912)
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
{code:java}
CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
CREATE TABLE IF NOT EXISTS ks.tb (c0 TEXT,W_Col set,c2 INT,c3 INT,c4
INT,c5 set, PRIMARY KEY (c3, c2, c0, c4));
DELETE FROM ks.tb WHERE c3 = 2 AND c2 = 2;
INSERT INTO ks.tb (c5, W_Col, c0, c4, c3, c2) VALUES
({'nAA','A','AA','A','A'},{0,1,2,3,4},'A',1320973978,2,2);
DELETE FROM ks.tb WHERE c3 = 2 AND c2 = 1584505374 AND c0 = 'z';
ALTER TABLE ks.tb DROP W_Col ; {code}
3. Drain 2.2.19.
{code:java}
bin/nodetool -h :::127.0.0.1 drain
bin/nodetool -h :::127.0.0.1 stopdaemon; {code}
4. Start up 3.0.30 (with default config is enough) and execute the following
read command
{code:java}
cqlsh> SELECT * FROM ks.tb WHERE
[jira] [Commented] (CASSANDRA-19638) In StressProfile line 843 equalsIgnoreCase() called on itself
[
https://issues.apache.org/jira/browse/CASSANDRA-19638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847086#comment-17847086
]
Dmitrii Kriukov commented on CASSANDRA-19638:
-
I can handle this change then :) But let's give some time for other opinions
> In StressProfile line 843 equalsIgnoreCase() called on itself
> -
>
> Key: CASSANDRA-19638
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19638
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dmitrii Kriukov
>Priority: Normal
>
> if (!e.getKey().equalsIgnoreCase(e.getKey()))
> { ...
> Need advice how to fix that.
--
This message was sent by Atlassian Jira
(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-19638) In StressProfile line 843 equalsIgnoreCase() called on itself
[
https://issues.apache.org/jira/browse/CASSANDRA-19638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847082#comment-17847082
]
Brandon Williams commented on CASSANDRA-19638:
--
I imagine it actually wants to check if e.getKey equals e.getKey.toLowerCase
instead.
> In StressProfile line 843 equalsIgnoreCase() called on itself
> -
>
> Key: CASSANDRA-19638
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19638
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dmitrii Kriukov
>Priority: Normal
>
> if (!e.getKey().equalsIgnoreCase(e.getKey()))
> { ...
> Need advice how to fix that.
--
This message was sent by Atlassian Jira
(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-19638) In StressProfile line 843 equalsIgnoreCase() called on itself
[
https://issues.apache.org/jira/browse/CASSANDRA-19638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847071#comment-17847071
]
Brandon Williams commented on CASSANDRA-19638:
--
That looks intentional and that line has been there for 10 years. What problem
are you trying to solve?
> In StressProfile line 843 equalsIgnoreCase() called on itself
> -
>
> Key: CASSANDRA-19638
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19638
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dmitrii Kriukov
>Priority: Normal
>
> if (!e.getKey().equalsIgnoreCase(e.getKey()))
> { ...
> Need advice how to fix that.
--
This message was sent by Atlassian Jira
(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-19638) In StressProfile line 843 equalsIgnoreCase() called on itself
Dmitrii Kriukov created CASSANDRA-19638:
---
Summary: In StressProfile line 843 equalsIgnoreCase() called on
itself
Key: CASSANDRA-19638
URL: https://issues.apache.org/jira/browse/CASSANDRA-19638
Project: Cassandra
Issue Type: Bug
Reporter: Dmitrii Kriukov
if (!e.getKey().equalsIgnoreCase(e.getKey()))
{ ...
Need advice how to fix that.
--
This message was sent by Atlassian Jira
(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-19637) LWT conditions on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847065#comment-17847065
]
David Capwell commented on CASSANDRA-19637:
---
I was curious so tried to run this in Accord to see what happens...
{code}
String cql = "BEGIN TRANSACTION\n" +
"LET a = (SELECT * FROM "+qualifiedTableName+" WHERE
k=?);\n" +
"SELECT a.v >= null;\n" +
"IF a.v >= null THEN\n" +
" INSERT INTO " + qualifiedTableName + "(k, v) VALUES
(?, ?);\n" +
"END IF\n" +
"COMMIT TRANSACTION";
{code}
* both the SELECT and the IF reject the syntax of a.v >= null, right now we use
"IS NULL" and "IS NOT NULL" here...
* SELECT doesn't allow "a.v IS NULL", so if you wish to know if your if block
was taken, then there isn't a way to do that in this case?
* when dropping the select and switching to "IS NULL", I had the following bind
values: 0, 0, []. When I query the table it returns [0, null]. // Empty and
Null look the same
* Testing out ">= []" ; select doesn't allow but IF does. The statement was
false as the row doesn't exist (null >= [] is false). When we add row [0, []]
we and change insert to do [0, [42]] the if statement is now true! a.v was
written as an empty list, so is it not "null" internally but instead byte[0]?
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell collections are implemented, it is not possible to
> differentiate between {{null}} and empty collections like it is feasible for
> single cell (frozen) collections. Therefore an empty multicell collection
> will always be treated as {{null}}.
> Unfortunately, the way LWT conditions handle that is not consistent with that.
> For example for {{colA list}} non null: {code}.. IF colA >= null{code}
> will throw an invalid request error whereas {code}..IF colA >= []{code} will
> returns {{true}}.
> Moreover, if we insert an empty list through:
> {code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
> and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
> results will be {code}{false, null}{code}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations is
> to consider empty multicell collection input as {{null}} and reject the
> {{null}} input for non {{=}} and {{!=}} operators.
>
--
This message was sent by Atlassian Jira
(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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847061#comment-17847061
]
Jacek Lewandowski commented on CASSANDRA-19636:
---
[~aweisberg] can I assume that you are ok with this ticket?
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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=17847056#comment-17847056
]
Brandon Williams commented on CASSANDRA-18098:
--
Given the CASSANDRA-19557 case, where all the sstables were deleted after the
test failed, the only way to fix this is to check after cleanup is completed.
I don't think that's really in the spirit of why CASSANDRA-11179 added this
test though, which was to make sure we weren't causing any undue stress on free
space during cleanup. With the deletion being asynchronous now, I guess we
technically are doing that, though in the real world it is probably not an
issue as much as in this test which has a trivial amount of data. [~marcuse]
WDYT?
> 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] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847040#comment-17847040 ] Michael Semb Wever commented on CASSANDRA-19556: CASSANDRA-19534 is a bug, it's not the same thing. We have _effectively_ been in rc mode for months now (chasing that "last" rc blocker, again and again…). Furthermore, we have defined our [release lifecycle doc|https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle] so to avoid changes like this once beta1 is released. Sam's argument above is the crux for me. If we see this as critical to do in 5.0.0 (and not 5.0.1) for 5.1/5.0 then let's explain that as the waiver. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (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-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[
https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847034#comment-17847034
]
Stefan Miklosovic commented on CASSANDRA-19556:
---
{quote}I really think that the silver bullet does exist and that is just
removing alter_table_enabled while it is not late and introducing ddl_enabled
in 5.0 GA.
{quote}
I still think this is completely reasonable to do even now. There will be still
at least one rc1 anyway. What are the _objective_ reasons this can't be
incorporated now? There are way bigger patches like CASSANDRA-19534 which seem
to be completely OK to be introduced even now, this patch is magnitude less
complicated.
> Add guardrail to block DDL/DCL queries and replace alter_table_enabled
> guardrail
>
>
> Key: CASSANDRA-19556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19556
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Yuqi Yan
>Assignee: Yuqi Yan
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Sometimes we want to block DDL/DCL queries to stop new schemas being created
> or roles created. (e.g. when doing live-upgrade)
> For DDL guardrail current implementation won't block the query if it's no-op
> (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The
> guardrail check is added in apply() right after all the existence check)
> I don't have preference on either block every DDL query or check whether if
> it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS..
> at startup, which is no-op but will be blocked by this guardrail and failed
> to start.
>
> 4.1 PR: [https://github.com/apache/cassandra/pull/3248]
> trunk PR: [https://github.com/apache/cassandra/pull/3275]
>
--
This message was sent by Atlassian Jira
(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-19601) Test failure: test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847016#comment-17847016
]
Brandon Williams commented on CASSANDRA-19601:
--
I have found that the flush is actually caused by AbstractCommitLogService
every 5 minutes, regardless of CL mode. In both direct and legacy mode there
is system table data being written on each flush. The difference between them
though is that legacy mode allocates the full segment size on disk before using
it, where direct mode allocates 4k and then it grows with usage, which is what
occasionally trips the test when it is run and intersects with that 5 minute
interval.
bq. one thing we can try is to check that the commit log's dirty regions don't
contain anything from that keyspace
I think that's what I'll have to do, since this discovery shows how measuring
segment size is not a valid way to determine if anything was written at all,
let alone know if it was appropriate or not, and this test relies on that
exclusively.
All of that said, I do think it would be better if direct mode had the same
on-disk semantics as legacy mode, but it's not a huge deal.
> 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
[jira] [Commented] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846989#comment-17846989 ] Michael Semb Wever commented on CASSANDRA-18712: Upgrading these dependencies repeatedly is a PITA – you have to make sure they're compatible with each other, have a clean transitive tree with no conflicts, all found in public repos, all found in the bom, and ideally not early-access versions. But we do want to encourage s390x work, or it'll never have any chance of being _officially accepted_. [~Nayana], how difficult it is for you to continue your s390x work having to manually re-apply this patch…? bq. I checked that the versions match the versions in the bom. Which bom version ? (link please) bq. there is not any "not early access" of 2.24, they stopped with 2.24ea28 and next one was 2.25ea0. 2.24 releases do exist, ref: https://github.com/OpenHFT/Chronicle-Bytes/releases/tag/chronicle-bytes-2.24.29. And the bom in repo1 has them ( https://repo1.maven.org/maven2/net/openhft/chronicle-bom/ ) but I've no idea about where the other 2.24 releases are to be found in public maven repos. We can build and deploy them to https://repository.apache.org/content/groups/public/ if we really want to… > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (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-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846988#comment-17846988 ] Brandon Williams commented on CASSANDRA-18712: -- It looks like this version has the same concerns as we had in CASSANDRA-18538, namely that chronicle will spy on users. See https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.25ea13/DISCLAIMER.adoc We first upgraded to a problematic version in CASSANDRA-18049 though. I think we need to revisit this. /cc [~mck] > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846984#comment-17846984
]
Jacek Lewandowski commented on CASSANDRA-19636:
---
Yes, this is a separate thing, I'll create a ticket for further cleanups.
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846980#comment-17846980
]
Ariel Weisberg edited comment on CASSANDRA-19636 at 5/16/24 2:37 PM:
-
Great!
I assume separately the [[upgrade_manifest.py|http://example.com]] to not
depend on the JAVAX_HOME so we have a more canonical set of things to test?
was (Author: aweisberg):
Great!
I assume separately the
[upgrade_manifest.py](https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py#L228)
to not depend on the JAVAX_HOME so we have a more canonical set of things to
test?
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846980#comment-17846980
]
Ariel Weisberg edited comment on CASSANDRA-19636 at 5/16/24 2:37 PM:
-
Great!
I assume separately the [upgrade_manifest.py|http://example.com] to not depend
on the JAVAX_HOME so we have a more canonical set of things to test?
was (Author: aweisberg):
Great!
I assume separately the [[upgrade_manifest.py|http://example.com]] to not
depend on the JAVAX_HOME so we have a more canonical set of things to test?
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846980#comment-17846980
]
Ariel Weisberg commented on CASSANDRA-19636:
Great!
I assume separately the
[upgrade_manifest.py](https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py#L228)
to not depend on the JAVAX_HOME so we have a more canonical set of things to
test?
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19637) LWT conditions on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846979#comment-17846979
]
Benjamin Lerer commented on CASSANDRA-19637:
[~maedhroz] You might be interested about that one for Accord.
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell collections are implemented, it is not possible to
> differentiate between {{null}} and empty collections like it is feasible for
> single cell (frozen) collections. Therefore an empty multicell collection
> will always be treated as {{null}}.
> Unfortunately, the way LWT conditions handle that is not consistent with that.
> For example for {{colA list}} non null: {code}.. IF colA >= null{code}
> will throw an invalid request error whereas {code}..IF colA >= []{code} will
> returns {{true}}.
> Moreover, if we insert an empty list through:
> {code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
> and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
> results will be {code}{false, null}{code}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations is
> to consider empty multicell collection input as {{null}} and reject the
> {{null}} input for non {{=}} and {{!=}} operators.
>
--
This message was sent by Atlassian Jira
(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-19637) LWT conditions on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19637:
---
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: Code Inspection
Severity: Low
Assignee: Benjamin Lerer
Status: Open (was: Triage Needed)
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell collections are implemented, it is not possible to
> differentiate between {{null}} and empty collections like it is feasible for
> single cell (frozen) collections. Therefore an empty multicell collection
> will always be treated as {{null}}.
> Unfortunately, the way LWT conditions handle that is not consistent with that.
> For example for {{colA list}} non null: {code}.. IF colA >= null{code}
> will throw an invalid request error whereas {code}..IF colA >= []{code} will
> returns {{true}}.
> Moreover, if we insert an empty list through:
> {code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
> and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
> results will be {code}{false, null}{code}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations is
> to consider empty multicell collection input as {{null}} and reject the
> {{null}} input for non {{=}} and {{!=}} operators.
>
--
This message was sent by Atlassian Jira
(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-19637) LWT conditions on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19637:
---
Description:
Due to the way multicell collections are implemented, it is not possible to
differentiate between {{null}} and empty collections like it is feasible for
single cell (frozen) collections. Therefore an empty multicell collection will
always be treated as {{null}}.
Unfortunately, the way LWT conditions handle that is not consistent with that.
For example for {{colA list}} non null: {code}.. IF colA >= null{code}
will throw an invalid request error whereas {code}..IF colA >= []{code} will
returns {{true}}.
Moreover, if we insert an empty list through:
{code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
results will be {code}{false, null}{code}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations is to
consider empty multicell collection input as {{null}} and reject the {{null}}
input for non {{=}} and {{!=}} operators.
was:
Due to the way multicell collections are implemented, it is not possible to
differentiate between {{null}} and empty collections like it is feasible for
single cell (frozen) collections. Therefore an empty multicell collection will
always be treated as {{null}}.
Unfortunately, the way LWT conditions handle that is not consistent with that.
For example for {{colA list}} non null: {code}.. IF colA >= null{code}
will throw an invalid request error whereas {code}..IF colA >= []{code} will
returns {{true}}.
Moreover, if we insert an empty list through:
{code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
results will be {code}{false, null}{code}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations is to
consider empty multicell collection input as {{null}} and reject the {{null}}
input for non {{=}} and {{!=}} operator.
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell collections are implemented, it is not possible to
> differentiate between {{null}} and empty collections like it is feasible for
> single cell (frozen) collections. Therefore an empty multicell collection
> will always be treated as {{null}}.
> Unfortunately, the way LWT conditions handle that is not consistent with that.
> For example for {{colA list}} non null: {code}.. IF colA >= null{code}
> will throw an invalid request error whereas {code}..IF colA >= []{code} will
> returns {{true}}.
> Moreover, if we insert an empty list through:
> {code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
> and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
> results will be {code}{false, null}{code}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations is
> to consider empty multicell collection input as {{null}} and reject the
> {{null}} input for non {{=}} and {{!=}} operators.
>
--
This message was sent by Atlassian Jira
(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-19637) LWT conditions on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19637:
---
Description:
Due to the way multicell collections are implemented, it is not possible to
differentiate between {{null}} and empty collections like it is feasible for
single cell (frozen) collections. Therefore an empty multicell collection will
always be treated as {{null}}.
Unfortunately, the way LWT conditions handle that is not consistent with that.
For example for {{colA list}} non null: {code}.. IF colA >= null{code}
will throw an invalid request error whereas {code}..IF colA >= []{code} will
returns {{true}}.
Moreover, if we insert an empty list through:
{code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
results will be {code}{false, null}{code}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations is to
consider empty multicell collection input as {{null}} and reject the {{null}}
input for non {{=}} and {{!=}} operator.
was:
Due to the way multicell collections are implemented, it is not possible to
differentiate between {{null}} and empty collections like it is feasible for
single cell (frozen) collections. Therefore an empty multicell collection will
always be treated as {{null}}.
Unfortunately, the way LWT conditions handle that is not consistent with that.
For example for {{colA list}} non null: {code}.. IF colA >= null{code}
will throw an invalid request error whereas {code}..IF colA >= []{code} will
returns {{true}}.
Moreover, if we insert an empty list through:
{code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
results will be {code}{false, null}{code}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations is to
consider empty multicell collection input as {{null}}.
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell collections are implemented, it is not possible to
> differentiate between {{null}} and empty collections like it is feasible for
> single cell (frozen) collections. Therefore an empty multicell collection
> will always be treated as {{null}}.
> Unfortunately, the way LWT conditions handle that is not consistent with that.
> For example for {{colA list}} non null: {code}.. IF colA >= null{code}
> will throw an invalid request error whereas {code}..IF colA >= []{code} will
> returns {{true}}.
> Moreover, if we insert an empty list through:
> {code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
> and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
> results will be {code}{false, null}{code}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations is
> to consider empty multicell collection input as {{null}} and reject the
> {{null}} input for non {{=}} and {{!=}} operator.
>
--
This message was sent by Atlassian Jira
(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-19637) LWT conditions on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19637:
---
Description:
Due to the way multicell collections are implemented, it is not possible to
differentiate between {{null}} and empty collections like it is feasible for
single cell (frozen) collections. Therefore an empty multicell collection will
always be treated as {{null}}.
Unfortunately, the way LWT conditions handle that is not consistent with that.
For example for {{colA list}} non null: {code}.. IF colA >= null{code}
will throw an invalid request error whereas {code}..IF colA >= []{code} will
returns {{true}}.
Moreover, if we insert an empty list through:
{code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
results will be {code}{false, null}{code}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations is to
consider empty multicell collection input as {{null}}.
was:
Due to the way multicell collections are implemented, it is not possible to
differentiate between {{null}} and empty collections like it is feasible for
single cell (frozen) collections. Therefore an empty multicell collection will
always be treated as {{null}}.
Unfortunately, the way LWT conditions handle that is not consistent with that.
For example for {{colA list}} non null: {code}.. IF colA >= null{code}
will throw an invalid request error whereas {code}..IF colA >= []{code} will
returns {{true}}.
Moreover, if we insert an empty list through:
{code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
results will be {code}{false, null}{code}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations like
is to consider empty multicell collection input as {{null}}.
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell collections are implemented, it is not possible to
> differentiate between {{null}} and empty collections like it is feasible for
> single cell (frozen) collections. Therefore an empty multicell collection
> will always be treated as {{null}}.
> Unfortunately, the way LWT conditions handle that is not consistent with that.
> For example for {{colA list}} non null: {code}.. IF colA >= null{code}
> will throw an invalid request error whereas {code}..IF colA >= []{code} will
> returns {{true}}.
> Moreover, if we insert an empty list through:
> {code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
> and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
> results will be {code}{false, null}{code}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations is
> to consider empty multicell collection input as {{null}}.
>
--
This message was sent by Atlassian Jira
(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-19637) LWT conditions on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19637:
---
Description:
Due to the way multicell collections are implemented, it is not possible to
differentiate between {{null}} and empty collections like it is feasible for
single cell (frozen) collections. Therefore an empty multicell collection will
always be treated as {{null}}.
Unfortunately, the way LWT conditions handle that is not consistent with that.
For example for {{colA list}} non null: {code}.. IF colA >= null{code}
will throw an invalid request error whereas {code}..IF colA >= []{code} will
returns {{true}}.
Moreover, if we insert an empty list through:
{code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
results will be {false, null}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations like
is to consider empty multicell collection input as {{null}}.
was:
Due to the way multicell collections are implemented, it is not possible to
differentiate between {{null}} and empty collections like it is feasible for
single cell (frozen) collections. Therefore an empty multicell collection will
always be treated as {{null}}.
Unfortunately, the way LWT conditions handle that is not consistent with that.
For example for {{colA list}} non null: {code}.. IF colA >= null{code}
will throw an invalid request error whereas {code}..IF colA >= []{code} will
returns {{true}}.
Moreover, if we insert en empty list through:
{code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
results will be {false, null}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations like
is to consider empty multicell collection input as {{null}}.
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell collections are implemented, it is not possible to
> differentiate between {{null}} and empty collections like it is feasible for
> single cell (frozen) collections. Therefore an empty multicell collection
> will always be treated as {{null}}.
> Unfortunately, the way LWT conditions handle that is not consistent with that.
> For example for {{colA list}} non null: {code}.. IF colA >= null{code}
> will throw an invalid request error whereas {code}..IF colA >= []{code} will
> returns {{true}}.
> Moreover, if we insert an empty list through:
> {code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
> and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
> results will be {false, null}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations
> like is to consider empty multicell collection input as {{null}}.
>
--
This message was sent by Atlassian Jira
(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-19637) LWT conditions on MultiCell collections return invalid results
[
https://issues.apache.org/jira/browse/CASSANDRA-19637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-19637:
---
Description:
Due to the way multicell collections are implemented, it is not possible to
differentiate between {{null}} and empty collections like it is feasible for
single cell (frozen) collections. Therefore an empty multicell collection will
always be treated as {{null}}.
Unfortunately, the way LWT conditions handle that is not consistent with that.
For example for {{colA list}} non null: {code}.. IF colA >= null{code}
will throw an invalid request error whereas {code}..IF colA >= []{code} will
returns {{true}}.
Moreover, if we insert an empty list through:
{code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
results will be {code}{false, null}{code}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations like
is to consider empty multicell collection input as {{null}}.
was:
Due to the way multicell collections are implemented, it is not possible to
differentiate between {{null}} and empty collections like it is feasible for
single cell (frozen) collections. Therefore an empty multicell collection will
always be treated as {{null}}.
Unfortunately, the way LWT conditions handle that is not consistent with that.
For example for {{colA list}} non null: {code}.. IF colA >= null{code}
will throw an invalid request error whereas {code}..IF colA >= []{code} will
returns {{true}}.
Moreover, if we insert an empty list through:
{code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
results will be {false, null}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations like
is to consider empty multicell collection input as {{null}}.
> LWT conditions on MultiCell collections return invalid results
> --
>
> Key: CASSANDRA-19637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Benjamin Lerer
>Priority: Normal
>
> Due to the way multicell collections are implemented, it is not possible to
> differentiate between {{null}} and empty collections like it is feasible for
> single cell (frozen) collections. Therefore an empty multicell collection
> will always be treated as {{null}}.
> Unfortunately, the way LWT conditions handle that is not consistent with that.
> For example for {{colA list}} non null: {code}.. IF colA >= null{code}
> will throw an invalid request error whereas {code}..IF colA >= []{code} will
> returns {{true}}.
> Moreover, if we insert an empty list through:
> {code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
> and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
> results will be {code}{false, null}{code}. Which can be quite confusing.
> The way to fix that behaviour to make it consistent with other operations
> like is to consider empty multicell collection input as {{null}}.
>
--
This message was sent by Atlassian Jira
(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-19637) LWT conditions on MultiCell collections return invalid results
Benjamin Lerer created CASSANDRA-19637:
--
Summary: LWT conditions on MultiCell collections return invalid
results
Key: CASSANDRA-19637
URL: https://issues.apache.org/jira/browse/CASSANDRA-19637
Project: Cassandra
Issue Type: Bug
Components: CQL/Semantics
Reporter: Benjamin Lerer
Due to the way multicell collections are implemented, it is not possible to
differentiate between {{null}} and empty collections like it is feasible for
single cell (frozen) collections. Therefore an empty multicell collection will
always be treated as {{null}}.
Unfortunately, the way LWT conditions handle that is not consistent with that.
For example for {{colA list}} non null: {code}.. IF colA >= null{code}
will throw an invalid request error whereas {code}..IF colA >= []{code} will
returns {{true}}.
Moreover, if we insert en empty list through:
{code}INSERT INTO mytable (pk, colA) VALUES (1, []);{code}
and use {code}DELETE FROM mytable WHERE pk=1 IF colA >= []{code} the returned
results will be {false, null}. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations like
is to consider empty multicell collection input as {{null}}.
--
This message was sent by Atlassian Jira
(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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846966#comment-17846966
]
Jacek Lewandowski commented on CASSANDRA-19636:
---
This reverts my previous changes so in terms of automatic selection of Java
version is works mostly as before.
{quote}
* Allowing specifying JDK version as a parameter and then look up the actual
JDK location from JAVAX_HOME
{quote}
This is implemented
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846964#comment-17846964
]
Michael Semb Wever edited comment on CASSANDRA-19636 at 5/16/24 1:59 PM:
-
+1 to the patch. we just need CI for (some) <5 branches.
(EDIT: didn't see Ariel's comment, not overriding it)
was (Author: michaelsembwever):
+1 to the patch. we just need CI for (some) <5 branches.
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846964#comment-17846964
]
Michael Semb Wever commented on CASSANDRA-19636:
+1 to the patch. we just need CI for (some) <5 branches.
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846957#comment-17846957
]
Ariel Weisberg commented on CASSANDRA-19636:
In terms of future direction for CCM behavior. If CCM automatically selecting a
compatible version goes away we should minimize the number of things you need
to manage to make CCM do the thing.
* Ignore PATH and only use JAVA_HOME
* If JAVA_HOME JDK is incompatible return an error
* Allowing specifying JDK version as a parameter and then look up the actual
JDK location from JAVAX_HOME
Existing users now don't need to modify environment variables to do whatever it
is they are trying to do with CCM.
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19592) Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
[ https://issues.apache.org/jira/browse/CASSANDRA-19592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846953#comment-17846953 ] Alex Petrov commented on CASSANDRA-19592: - [~samt] looks good to me! > Expand CREATE TABLE CQL on a coordinating node before submitting to CMS > --- > > Key: CASSANDRA-19592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19592 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Attachments: ci_summary-1.html, ci_summary.html > > > This is done to unblock CASSANDRA-12937 and allow preserving defaults with > which the table was created between node bounces and between nodes with > different configurations. For now, we are preserving 5.0 behaviour. -- This message was sent by Atlassian Jira (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-19592) Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
[ https://issues.apache.org/jira/browse/CASSANDRA-19592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846952#comment-17846952 ] Sam Tunnicliffe commented on CASSANDRA-19592: - [~ifesdjeen] I'm +1 on this version, wdyt? > Expand CREATE TABLE CQL on a coordinating node before submitting to CMS > --- > > Key: CASSANDRA-19592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19592 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Attachments: ci_summary-1.html, ci_summary.html > > > This is done to unblock CASSANDRA-12937 and allow preserving defaults with > which the table was created between node bounces and between nodes with > different configurations. For now, we are preserving 5.0 behaviour. -- This message was sent by Atlassian Jira (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-19592) Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
[ https://issues.apache.org/jira/browse/CASSANDRA-19592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19592: Attachment: ci_summary-1.html > Expand CREATE TABLE CQL on a coordinating node before submitting to CMS > --- > > Key: CASSANDRA-19592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19592 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Attachments: ci_summary-1.html, ci_summary.html > > > This is done to unblock CASSANDRA-12937 and allow preserving defaults with > which the table was created between node bounces and between nodes with > different configurations. For now, we are preserving 5.0 behaviour. -- This message was sent by Atlassian Jira (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-19592) Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
[ https://issues.apache.org/jira/browse/CASSANDRA-19592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19592: Status: Review In Progress (was: Changes Suggested) Discussed with Alex and made a few tweaks. Pushed the latest version and attached updated CI summary. The single test failure is unrelated. > Expand CREATE TABLE CQL on a coordinating node before submitting to CMS > --- > > Key: CASSANDRA-19592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19592 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Attachments: ci_summary.html > > > This is done to unblock CASSANDRA-12937 and allow preserving defaults with > which the table was created between node bounces and between nodes with > different configurations. For now, we are preserving 5.0 behaviour. -- This message was sent by Atlassian Jira (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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846945#comment-17846945
]
Michael Semb Wever commented on CASSANDRA-19636:
CI
- 5.0
[^CASSANDRA-19636_50_75_ci_summary.html] ,
[^CASSANDRA-19636_50_75_results_details.tar.xz]
- trunk
[^CASSANDRA-19636_trunk_76_ci_summary.html] ,
[^CASSANDRA-19636_trunk_76_results_details.tar.xz]
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19636:
---
Attachment: CASSANDRA-19636_trunk_76_ci_summary.html
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19636:
---
Attachment: CASSANDRA-19636_trunk_76_results_details.tar.xz
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz,
> CASSANDRA-19636_trunk_76_ci_summary.html,
> CASSANDRA-19636_trunk_76_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19158) Reuse native transport-driven futures in Debounce
[ https://issues.apache.org/jira/browse/CASSANDRA-19158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-19158: Attachment: ci_summary.html > Reuse native transport-driven futures in Debounce > - > > Key: CASSANDRA-19158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19158 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Attachments: ci_summary-1.html, ci_summary.html > > Time Spent: 1h > Remaining Estimate: 0h > > Currently, we create a future in Debounce, then create one more future in > RemoteProcessor#sendWithCallback. This is further exacerbated by chaining > calls, when we first attempt to catch up from peer, and then from CMS. > First of all, we should always only use a native transport timeout driven > futures returned from sendWithCallback, since they implement reasonable > retries under the hood, and are easy to bulk-configure (ie you can simply > change timeout in yaml and have all futures change their behaviour). > Second, we should _chain_ futures and use map or andThen for fallback > operations such as trying to catch up from CMS after an unsuccesful attemp to > catch up from peer. > This should significantly simplify the code and number of blocked/waiting > threads. -- This message was sent by Atlassian Jira (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-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846941#comment-17846941 ] Stefan Miklosovic commented on CASSANDRA-18712: --- What I would personally do is that I would wait with this ticket until 5.1 is imminent. The reason for doing so is that while we release 5.1, we will most likely want to update these dependencies again because they are being actively developed. I do not see any critical reason why should be this merged _right now_ - only if we want to enable people to test trunk on s390x as mentioned in the description that this is a blocker for them, but we do not officially support that architecture anyway ... > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19636:
---
Attachment: CASSANDRA-19636_50_75_ci_summary.html
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19636:
---
Reviewers: Michael Semb Wever, Michael Semb Wever
Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever)
Status: Review In Progress (was: Patch Available)
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-19636) Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19636:
---
Attachment: CASSANDRA-19636_50_75_results_details.tar.xz
> Fix CCM for Cassandra 5.0 and add arg to the command line which let the user
> explicitly select JVM
> --
>
> Key: CASSANDRA-19636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19636
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Attachments: CASSANDRA-19636_50_75_ci_summary.html,
> CASSANDRA-19636_50_75_results_details.tar.xz
>
>
> CCM fails to select the right Java version for Cassandra 5 binary
> distribution.
> There are also two additional changes proposed here:
> * add {{--jvm-version}} argument to let the user explicitly select Java
> version when starting a node from command line
> * fail if {{java}} command is available on the {{PATH}} and points to a
> different Java version than Java distribution defined in {{JAVA_HOME}}
> because there is no obvious way for the user to figure out which one is going
> to be used
>
--
This message was sent by Atlassian Jira
(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-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846919#comment-17846919
]
Stefan Miklosovic edited comment on CASSANDRA-18712 at 5/16/24 11:41 AM:
-
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
I checked that the versions match the versions in the bom.
When it comes to pom.xml (after ant mvn-install), it is same (checking with mvn
dependency:tree)
I am not sure what is their policy when it comes to release versioning.
[https://central.sonatype.com/artifact/net.openhft/chronicle-core/versions]
E.g. there is not any "not early access" of 2.24, they stopped with 2.24ea28
and next one was 2.25ea0.
[https://repo1.maven.org/maven2/net/openhft/chronicle-core/]
was (Author: smiklosovic):
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
When it comes to pom.xml (after ant mvn-install), it is same (checking with mvn
dependency:tree)
I am not sure what is their policy when it comes to release versioning.
[https://central.sonatype.com/artifact/net.openhft/chronicle-core/versions]
E.g. there is not any "not early access" of 2.24, they stopped with 2.24ea28
and next one was 2.25ea0.
[https://repo1.maven.org/maven2/net/openhft/chronicle-core/]
> Update Chronicle bytes
> --
>
> Key: CASSANDRA-18712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18712
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Nayana Thorat
>Assignee: Nayana Thorat
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of
> cassandra on s390x.
> This patch is merged and available in chronicle-bytes-2.24ea7 and later
> releases.
> possible to update Chronicle bytes and related pkg versions in Cassandra
> (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)?
>
--
This message was sent by Atlassian Jira
(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-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846919#comment-17846919
]
Stefan Miklosovic edited comment on CASSANDRA-18712 at 5/16/24 11:40 AM:
-
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
When it comes to pom.xml (after ant mvn-install), it is same (checking with mvn
dependency:tree)
I am not sure what is their policy when it comes to release versioning.
[https://central.sonatype.com/artifact/net.openhft/chronicle-core/versions]
E.g. there is not any "not early access" of 2.24, they stopped with 2.24ea28
and next one was 2.25ea0.
[https://repo1.maven.org/maven2/net/openhft/chronicle-core/]
was (Author: smiklosovic):
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
When it comes to pom.xml (after ant mvn-install), it is same.
> Update Chronicle bytes
> --
>
> Key: CASSANDRA-18712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18712
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Nayana Thorat
>Assignee: Nayana Thorat
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of
> cassandra on s390x.
> This patch is merged and available in chronicle-bytes-2.24ea7 and later
> releases.
> possible to update Chronicle bytes and related pkg versions in Cassandra
> (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)?
>
--
This message was sent by Atlassian Jira
(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-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846919#comment-17846919
]
Stefan Miklosovic commented on CASSANDRA-18712:
---
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
When it comes to pom.xml (after ant mvn-install), it is same.
> Update Chronicle bytes
> --
>
> Key: CASSANDRA-18712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18712
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Nayana Thorat
>Assignee: Nayana Thorat
>Priority: Normal
> Fix For: 5.x
>
>
> [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of
> cassandra on s390x.
> This patch is merged and available in chronicle-bytes-2.24ea7 and later
> releases.
> possible to update Chronicle bytes and related pkg versions in Cassandra
> (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)?
>
--
This message was sent by Atlassian Jira
(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-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846897#comment-17846897 ] Stefan Miklosovic commented on CASSANDRA-18712: --- thanks [~Nayana] , I ll take a look. > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (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-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18712: -- Reviewers: Stefan Miklosovic Status: Review In Progress (was: Patch Available) > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (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-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18712: -- Test and Documentation Plan: ci Status: Patch Available (was: In Progress) > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (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-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned CASSANDRA-18712: - Assignee: Nayana Thorat > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (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-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846889#comment-17846889
]
Nayana Thorat commented on CASSANDRA-18712:
---
[~mck] I have verified current Cassandra master (commit :
48f6a318796c02ba8e2f22b078958200ba37c9a6) with upgraded chronicle versions.
Build is successful as well as tests are passing.
Below are the chronicle versions tested:
{code:java}
diff --git a/.build/parent-pom-template.xml b/.build/parent-pom-template.xml
index 0c0e5d4ccc..89334e943c 100644
--- a/.build/parent-pom-template.xml
+++ b/.build/parent-pom-template.xml
@@ -828,7 +828,7 @@
net.openhft
chronicle-queue
- 5.23.37
+ 5.25ea13
tools
@@ -844,7 +844,7 @@
net.openhft
chronicle-core
- 2.23.36
+ 2.25ea13
chronicle-analytics
@@ -859,7 +859,7 @@
net.openhft
chronicle-bytes
- 2.23.33
+ 2.25ea9
annotations
@@ -870,7 +870,7 @@
net.openhft
chronicle-wire
- 2.23.39
+ 2.25ea12
compiler
@@ -886,7 +886,7 @@
net.openhft
chronicle-threads
- 2.23.25
+ 2.25ea6
{code}
> Update Chronicle bytes
> --
>
> Key: CASSANDRA-18712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18712
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Nayana Thorat
>Priority: Normal
> Fix For: 5.x
>
>
> [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of
> cassandra on s390x.
> This patch is merged and available in chronicle-bytes-2.24ea7 and later
> releases.
> possible to update Chronicle bytes and related pkg versions in Cassandra
> (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)?
>
--
This message was sent by Atlassian Jira
(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-19158) Reuse native transport-driven futures in Debounce
[ https://issues.apache.org/jira/browse/CASSANDRA-19158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-19158: Attachment: (was: ci_summary.html) > Reuse native transport-driven futures in Debounce > - > > Key: CASSANDRA-19158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19158 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Attachments: ci_summary-1.html > > Time Spent: 1h > Remaining Estimate: 0h > > Currently, we create a future in Debounce, then create one more future in > RemoteProcessor#sendWithCallback. This is further exacerbated by chaining > calls, when we first attempt to catch up from peer, and then from CMS. > First of all, we should always only use a native transport timeout driven > futures returned from sendWithCallback, since they implement reasonable > retries under the hood, and are easy to bulk-configure (ie you can simply > change timeout in yaml and have all futures change their behaviour). > Second, we should _chain_ futures and use map or andThen for fallback > operations such as trying to catch up from CMS after an unsuccesful attemp to > catch up from peer. > This should significantly simplify the code and number of blocked/waiting > threads. -- This message was sent by Atlassian Jira (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-19599) Remove unused config params for out of range token requests
[
https://issues.apache.org/jira/browse/CASSANDRA-19599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19599:
Fix Version/s: 5.1
(was: 5.x)
Source Control Link:
https://github.com/apache/cassandra/commit/a15b137b7c8c84773453dbe264fcd2d4b76222c0
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks
> Remove unused config params for out of range token requests
> ---
>
> Key: CASSANDRA-19599
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19599
> Project: Cassandra
> Issue Type: Task
> Components: Local/Config
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.1
>
> Attachments: ci_summary.html
>
>
> The fields {{log_out_of_token_range_requests}} and
> {{reject_out_of_token_range_requests}} in {{Config.java}} have never actually
> been used and are just vestiges from early development on CEP-21.
> We should remove them and the related accessors in {{DatabaseDescriptor}}.
--
This message was sent by Atlassian Jira
(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-19599) Remove unused config params for out of range token requests
[
https://issues.apache.org/jira/browse/CASSANDRA-19599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19599:
Status: Ready to Commit (was: Review In Progress)
> Remove unused config params for out of range token requests
> ---
>
> Key: CASSANDRA-19599
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19599
> Project: Cassandra
> Issue Type: Task
> Components: Local/Config
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> The fields {{log_out_of_token_range_requests}} and
> {{reject_out_of_token_range_requests}} in {{Config.java}} have never actually
> been used and are just vestiges from early development on CEP-21.
> We should remove them and the related accessors in {{DatabaseDescriptor}}.
--
This message was sent by Atlassian Jira
(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-19599) Remove unused config params for out of range token requests
[
https://issues.apache.org/jira/browse/CASSANDRA-19599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19599:
Reviewers: Marcus Eriksson
Status: Review In Progress (was: Patch Available)
> Remove unused config params for out of range token requests
> ---
>
> Key: CASSANDRA-19599
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19599
> Project: Cassandra
> Issue Type: Task
> Components: Local/Config
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> The fields {{log_out_of_token_range_requests}} and
> {{reject_out_of_token_range_requests}} in {{Config.java}} have never actually
> been used and are just vestiges from early development on CEP-21.
> We should remove them and the related accessors in {{DatabaseDescriptor}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated: Remove unused fields from config
This is an automated email from the ASF dual-hosted git repository.
samt pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new a15b137b7c Remove unused fields from config
a15b137b7c is described below
commit a15b137b7c8c84773453dbe264fcd2d4b76222c0
Author: Sam Tunnicliffe
AuthorDate: Tue Apr 30 09:04:09 2024 +0100
Remove unused fields from config
Patch by Sam Tunnicliffe; reviewed by Marcus Eriksson for CASSANDRA-19599
---
CHANGES.txt | 1 +
src/java/org/apache/cassandra/config/Config.java | 2 --
.../apache/cassandra/config/DatabaseDescriptor.java | 20
3 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index b0ba04f3e2..34e4825d26 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
5.1
+ * Remove unused fields from config (CASSANDRA-19599)
* Refactor Relation and Restriction hierarchies (CASSANDRA-19341)
* Raise priority of TCM internode messages during critical operations
(CASSANDRA-19517)
* Add nodetool command to unregister LEFT nodes (CASSANDRA-19581)
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index db1d07c542..17e9e99cb7 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -1299,8 +1299,6 @@ public class Config
* collect enough nodes.
*/
public volatile ConsistencyLevel progress_barrier_min_consistency_level =
ConsistencyLevel.EACH_QUORUM;
-public volatile boolean log_out_of_token_range_requests = true;
-public volatile boolean reject_out_of_token_range_requests = true;
public volatile ConsistencyLevel
progress_barrier_default_consistency_level = ConsistencyLevel.EACH_QUORUM;
public volatile DurationSpec.LongMillisecondsBound
progress_barrier_timeout = new DurationSpec.LongMillisecondsBound("360ms");
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index 7b747e9c02..bea35ef16b 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -5094,26 +5094,6 @@ public class DatabaseDescriptor
conf.progress_barrier_min_consistency_level = newLevel;
}
-public static boolean getLogOutOfTokenRangeRequests()
-{
-return conf.log_out_of_token_range_requests;
-}
-
-public static void setLogOutOfTokenRangeRequests(boolean enabled)
-{
-conf.log_out_of_token_range_requests = enabled;
-}
-
-public static boolean getRejectOutOfTokenRangeRequests()
-{
-return conf.reject_out_of_token_range_requests;
-}
-
-public static void setRejectOutOfTokenRangeRequests(boolean enabled)
-{
-conf.reject_out_of_token_range_requests = enabled;
-}
-
public static ConsistencyLevel getProgressBarrierDefaultConsistencyLevel()
{
return conf.progress_barrier_default_consistency_level;
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
