[jira] [Updated] (CASSANDRA-18811) Set right client auth for creating SSL context in mTLS optional mode
[ https://issues.apache.org/jira/browse/CASSANDRA-18811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18811: --- Fix Version/s: 5.0.x (was: 5.0-beta) > Set right client auth for creating SSL context in mTLS optional mode > > > Key: CASSANDRA-18811 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18811 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.1.x, 5.0.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Adding a new value `optional` for require_client_auth in Encryption options. > when require_client_auth is optional, the SSL context that is created will > allow client connections that provide a client certificate along with the > client connections that do not provide certificates. -- This message was sent by Atlassian Jira (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-18811) Set right client auth for creating SSL context in mTLS optional mode
[ https://issues.apache.org/jira/browse/CASSANDRA-18811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18811: --- Fix Version/s: 5.0-beta (was: 5.0-alpha) > Set right client auth for creating SSL context in mTLS optional mode > > > Key: CASSANDRA-18811 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18811 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.1.x, 5.0-beta, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Adding a new value `optional` for require_client_auth in Encryption options. > when require_client_auth is optional, the SSL context that is created will > allow client connections that provide a client certificate along with the > client connections that do not provide certificates. -- This message was sent by Atlassian Jira (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-18948) Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18948:
---
Fix Version/s: 5.0-rc
(was: 5.0.x)
> Test failure:
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
>
> ---
>
> Key: CASSANDRA-18948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18948
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc
>
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/71/testReport/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testReplayLogic_compression_jdk17_arch_x86_64_python2_7/
> h3.
> {code:java}
> Error Message
> Missing old CDCIndexData in new set after replay:
> CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData in new set of
> indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214
> Stacktrace
> junit.framework.AssertionFailedError: Missing old CDCIndexData in new set
> after replay: CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData
> in new set of indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214 at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic(CommitLogSegmentManagerCDCTest.java:319)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18798) Appending to list in Accord transactions uses insertion timestamp
[
https://issues.apache.org/jira/browse/CASSANDRA-18798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18798:
---
Fix Version/s: (was: 5.0-beta)
> Appending to list in Accord transactions uses insertion timestamp
> -
>
> Key: CASSANDRA-18798
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18798
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Jaroslaw Kijanowski
>Assignee: Henrik Ingo
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-2023-09-26-20-05-25-846.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Given the following schema:
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS accord WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 3};
> CREATE TABLE IF NOT EXISTS accord.list_append(id int PRIMARY KEY,contents
> LIST);
> TRUNCATE accord.list_append;{code}
> And the following two possible queries executed by 10 threads in parallel:
> {code:java}
> BEGIN TRANSACTION
> LET row = (SELECT * FROM list_append WHERE id = ?);
> SELECT row.contents;
> COMMIT TRANSACTION;"
> BEGIN TRANSACTION
> UPDATE list_append SET contents += ? WHERE id = ?;
> COMMIT TRANSACTION;"
> {code}
> there seems to be an issue with transaction guarantees. Here's an excerpt in
> the edn format from a test.
> {code:java}
> {:type :invoke :process 8 :value [[:append 5 352]] :tid 3 :n 52
> :time 1692607285967116627}
> {:type :invoke :process 9 :value [[:r 5 nil]] :tid 1 :n 54
> :time 1692607286078732473}
> {:type :invoke :process 6 :value [[:append 5 553]] :tid 5 :n 53
> :time 1692607286133833428}
> {:type :invoke :process 7 :value [[:append 5 455]] :tid 4 :n 55
> :time 1692607286149702511}
> {:type :ok :process 8 :value [[:append 5 352]] :tid 3 :n 52
> :time 1692607286156314099}
> {:type :invoke :process 5 :value [[:r 5 nil]] :tid 9 :n 52
> :time 1692607286167090389}
> {:type :ok :process 9 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352]]] :tid 1 :n 54 :time 1692607286168657534}
> {:type :invoke :process 1 :value [[:r 5 nil]] :tid 0 :n 51
> :time 1692607286201762938}
> {:type :ok :process 7 :value [[:append 5 455]] :tid 4 :n 55
> :time 1692607286245571513}
> {:type :invoke :process 7 :value [[:r 5 nil]] :tid 4 :n 56
> :time 1692607286245655775}
> {:type :ok :process 5 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 455]]] :tid 9 :n 52 :time 1692607286253928906}
> {:type :invoke :process 5 :value [[:r 5 nil]] :tid 9 :n 53
> :time 1692607286254095215}
> {:type :ok :process 6 :value [[:append 5 553]] :tid 5 :n 53
> :time 1692607286266263422}
> {:type :ok :process 1 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 553 455]]] :tid 0 :n 51 :time 1692607286271617955}
> {:type :ok :process 7 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 553 455]]] :tid 4 :n 56 :time 1692607286271816933}
> {:type :ok :process 5 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 553 455]]] :tid 9 :n 53 :time 1692607286281483026}
> {:type :invoke :process 9 :value [[:r 5 nil]] :tid 1 :n 56
> :time 1692607286284097561}
> {:type :ok :process 9 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 553 455]]] :tid 1 :n 56 :time 1692607286306445242}
> {code}
> Processes process 6 and process 7 are appending the values 553 and 455
> respectively. 455 succeeded and a read by process 5 confirms that. But then
> also 553 is appended and a read by process 1 confirms that as well, however
> it sees 553 before 455.
> process 5 reads [...
[jira] [Updated] (CASSANDRA-18945) Unified Compaction Strategy is creating too many sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18945:
---
Fix Version/s: 5.0-beta
(was: 5.x)
(was: 5.0)
> Unified Compaction Strategy is creating too many sstables
> -
>
> Key: CASSANDRA-18945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18945
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Branimir Lambov
>Assignee: Ethan Brown
>Priority: Normal
> Fix For: 5.0-beta
>
> Attachments: file_ucs_shenandoah.html, file_ucs_shenandoah_3.html,
> file_ucs_shenandoah_off_heap_memtable.html,
> file_ucs_shenandoah_on_heap_memtable_2.html,
> file_ucs_shenandoah_on_heap_memtable_3.html, key-value-oss.html
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The unified compaction strategy currently aims to create sstables with close
> to the same size, defaulting to 1 GiB. Unfortunately tests show that
> Cassandra starts to have performance problems when the number of sstables
> grows to the order of a thousand, and in particular that even 1 TiB of data
> with the default configuration is creating too many sstables for efficient
> processing. This matters even more for SAI, where the number of sstables in
> the system can have a proportional effect on the complexity of operations.
> It is quite easy to create a configuration option that allows sstables to
> take some part of the data growth by adding a multiplier to [the shard count
> calculation|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md#sharding]
> formula, replacing
> {{2 ^ round(log2(d / (t * b))) * b}}
> with
> {{2 ^ round((1 - 휆) * log2(d / (t * b))) * b}},
> where 휆 is a parameter whose value is between 0 and 1.
> With this, a 휆 of 0.5 would mean that shard count and sstable size grow in
> parallel at the square root of the data size growth. 0 would result in no
> growth, and 1 in always using the same number of shards.
> It may also be valuable to introduce a threshold for engaging the base shard
> count to avoid splitting lowest-level sstables into fragments that are too
> small.
> Once both of these are in place, we can set defaults that better suit all
> node densities, including 10 TiB and beyond, for example:
> - target size of 1 GiB
> - 휆 of 1/3
> - base shard count of 4
> - minimum size 100 MiB
--
This message was sent by Atlassian Jira
(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-18534) Make sstable format configurable per table
[
https://issues.apache.org/jira/browse/CASSANDRA-18534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18534:
---
Fix Version/s: 5.x
(was: 5.0)
> Make sstable format configurable per table
> --
>
> Key: CASSANDRA-18534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18534
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema, Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Maxwell Guo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Some SSTable format settings need to be configurable per table for better
> efficiency. This includes:
> - {{row_index_granularity}}
> - {{bloom_filter_fp_chance}}
> - {{crc_check_chance}}
> - {{min/max_index_interval}}
> Some of these are currently configurable using direct properties of tables.
> Having them as format properties makes better sense and should also support
> specifying useable combinations of settings, e.g.
> {code:java}
> CREATE TABLE ... WITH sstable_format = "bti-fast";
> CREATE TABLE ... WITH sstable_format = "bti-small";
> {code}
> where {{bti-fast}} and {{bti-small}} can be defined in {{cassandra.yaml}}
> e.g. as
> {code:java}
> sstable.format.options:
> - bti-fast:
> row_index_granularity: 1kiB
> bloom_filter_fp_chance: 0.01
> - bti-small:
> row_index_granularity: 32kiB
> bloom_filter_fp_chance: 0.1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18330) Delivery of CEP-21: Transactional Cluster Metadata
[ https://issues.apache.org/jira/browse/CASSANDRA-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18330: --- Reviewers: Benjamin Lerer, Ekaterina Dimitrova, Jacek Lewandowski > Delivery of CEP-21: Transactional Cluster Metadata > -- > > Key: CASSANDRA-18330 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18330 > Project: Cassandra > Issue Type: Epic > Components: Cluster/Membership, Cluster/Schema >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > -- This message was sent by Atlassian Jira (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-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apac
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774832#comment-17774832
]
Benjamin Lerer edited comment on CASSANDRA-18747 at 10/13/23 9:08 AM:
--
I looked at the code of 4.0 and 4.1 and thinking a bit more about it, I do not
understand why the keyspaces were split into several groups.
Some methods look also wrong. There seem to be some confusions between what is
called distributed keyspaces, non-system keyspaces and local keyspaces.
It feels to me that we should revisit that code more carefully.
was (Author: blerer):
I looked at the code of 4.0 and 4.1 and thinking a bit more about it, I do not
understand why the keyspaces were split into several groups.
Some methods look also wrong. There seems to be some confusions between what is
called distributed keyspaces, non-system keyspaces and local keyspaces.
It feels to me that we should revisit that code more carefully.
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
>
[jira] [Comment Edited] (CASSANDRA-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apac
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774832#comment-17774832
]
Benjamin Lerer edited comment on CASSANDRA-18747 at 10/13/23 9:08 AM:
--
I looked at the code of 4.0 and 4.1 and thinking a bit more about it, I do not
understand why the keyspaces were split into several groups.
Some methods look also wrong. There seems to be some confusions between what is
called distributed keyspaces, non-system keyspaces and local keyspaces.
It feels to me that we should revisit that code more carefully.
was (Author: blerer):
I looked at the code of 4.0 and 4.1 and thinking a bit more about it, I do not
understand why the keyspaces were split into several groups.
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch -
>
[jira] [Commented] (CASSANDRA-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apache.ca
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774832#comment-17774832
]
Benjamin Lerer commented on CASSANDRA-18747:
I looked at the code of 4.0 and 4.1 and thinking a bit more about it, I do not
understand why the keyspaces were split into several groups.
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2475/workflows/2086619e-0f21-464b-a866-84aca516b5e5/jobs/36716/tests]
> test_gcgs_validation -
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1666/testReport/junit/dtest.materialized_views_test/TestMaterializedViews/test_gcgs_validation/]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail:
[jira] [Updated] (CASSANDRA-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apache.cass
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18747:
---
Status: Changes Suggested (was: Ready to Commit)
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2475/workflows/2086619e-0f21-464b-a866-84aca516b5e5/jobs/36716/tests]
> test_gcgs_validation -
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1666/testReport/junit/dtest.materialized_views_test/TestMaterializedViews/test_gcgs_validation/]
--
This message was sent by Atlassian Jira
(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-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apache.ca
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774828#comment-17774828
]
Benjamin Lerer commented on CASSANDRA-18747:
It seems to me that the proposed solution is going in the opposite direction of
where it should go. The issue mainly comes from the fact that we have
duplicated some information in a multithreaded code. Rather than making that
logic more complex we should simplify it an remove the duplication. Looking at
where those 2 variables are used and how they get used I really do not see the
need for the {{distributedAndLocalKeyspaces}} variable. Am I missing something?
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2475/workflows/2086619e-0f21-464b-a866-84aca516b5e5/jobs/36716/tests]
> test_gcgs_validation -
>
[jira] [Commented] (CASSANDRA-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765520#comment-17765520
]
Benjamin Lerer commented on CASSANDRA-18813:
I updated the patch which now:
* removes the {{MultiItemTerminal}} and {{MultiColumnRaw}} interfaces
* represents IN bind marker as {{Terms}} instead of having 2 different
representations (a list of terms and a single {{MultiItemTerminal}}).
* replaces the {{AbstractMarker}} hierachy by the {{Marker}} class
* introduces a new {{MultiElementType}} that becomes a super class of all the
{{CollectionTypes}}, {{TupleType}}, {{UserType}} and {{VectorType}}
(standardizing the {{pack}} and {{unpack}} method names and their modifiers)
* It replaces the {{Value}} and {{DelayedValue}} implementations for the
{{Lists}}, {{Sets}}, {{Maps}}, {{Tuples}}, {{UserTypes}} and {{Vectors}}
classes by the {{MultiElements}} Value and {{DelayedValue}} classes.
CI [Java
11|https://app.circleci.com/pipelines/github/blerer/cassandra/358/workflows/efc7db24-d110-4f45-a273-c71e685b39a5]
and [Java
17|https://app.circleci.com/pipelines/github/blerer/cassandra/358/workflows/deec9a8e-132c-484c-b8dc-496d4a837072]
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
This message was sent by Atlassian Jira
(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-16787) Copy from csv file with duration type fields fails to import
[
https://issues.apache.org/jira/browse/CASSANDRA-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763609#comment-17763609
]
Benjamin Lerer commented on CASSANDRA-16787:
The people working on the driver have been a bit overloaded those last years.
Hopefully, things will change once the python driver is donated (hopefully this
year).
I do not personally mind letting this ticket open.
> Copy from csv file with duration type fields fails to import
>
>
> Key: CASSANDRA-16787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16787
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Brijesh Dungarakoti
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: error_cassandra_copy_from_1.JPG,
> error_cassandra_copy_from_2.JPG
>
>
> Getting error:
> {code:java}
> cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv'
> WITH HEADER = FALSE AND NULL='null';
> Using 3 child processes
> Starting copy of users.user_credentials_by_email with columns [email,
> la_duration].
> Failed to make batch statement: Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.)_
> Failed to import 1 rows: TypeError - Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.), given up
> without retries
> Failed to process 1 rows; failed rows written to
> import_users_user_credentials_by_email.err
> Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s
> 0 rows imported from 1 files in 0.431 seconds (0 skipped).
> {code}
> *To Reproduce:*
> {code:java}
> CREATE KEYSPACE users WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor' : 1 } AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (
> email text,
> la_duration duration,
> PRIMARY KEY(email)
> );
> {code}
> create users.csv file with:
> {code:java}
> l...@la.com,8m26s482ms
> {code}
> Run:
> {code:java}
> COPY users.user_credentials_by_email FROM 'users.csv' WITH HEADER = FALSE AND
> NULL='null';
> {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-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762716#comment-17762716
]
Benjamin Lerer commented on CASSANDRA-18322:
Rather than doing some type checks on the statement, will it not make sense to
add a {{shouldUseFullyQualifiedTableName}} method to {{CQLStatement}} ? We
could also do it the other way around by flagging statements that do not need
to be prepared.
It seems to me that the patch missed the {{BatchStatement}}.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(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-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18322:
---
Reviewers: Benjamin Lerer
Status: Review In Progress (was: Needs Committer)
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(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-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18813:
---
Test and Documentation Plan: The refactoring does not change the logic and
relies on the existing tests
Status: Patch Available (was: Open)
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
This message was sent by Atlassian Jira
(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-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760915#comment-17760915
]
Benjamin Lerer commented on CASSANDRA-18813:
PR:
[https://github.com/apache/cassandra/pull/2655|https://github.com/apache/cassandra/pull/2655]
CI [Java
11|https://app.circleci.com/pipelines/github/blerer/cassandra/350/workflows/cfab461e-8d9c-4f1e-acc1-00d03f11cd53]
and [Java
17|https://app.circleci.com/pipelines/github/blerer/cassandra/350/workflows/311ea931-f109-419c-a358-98fdcb612575]
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
This message was sent by Atlassian Jira
(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-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18813:
---
Change Category: Code Clarity
Complexity: Normal
Fix Version/s: 5.x
Reviewers: Ekaterina Dimitrova
Status: Open (was: Triage Needed)
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
This message was sent by Atlassian Jira
(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-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18813:
---
Summary: Simplify the bind marker and Term logic (was: Simplify the Bind
Marker and Term logic)
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
This message was sent by Atlassian Jira
(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-18813) Simplify the Bind Marker and Term logic
Benjamin Lerer created CASSANDRA-18813:
--
Summary: Simplify the Bind Marker and Term logic
Key: CASSANDRA-18813
URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
Project: Cassandra
Issue Type: Improvement
Components: CQL/Interpreter
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
The current logic around {{Term}} and {{Terms}} classes is confusing specially
with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to handle
different use cases that could be handled simply with the {{Term}} interface.
On top of that IN marker add to the confusion because the are represented as
single Term where in practice they are a set of terms. Representing them as a
{{Terms}} could simplify the way we handle IN restrictions.
The goal of this ticket is:
* to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
* Represents IN bind marker as {{Terms}} instead of having 2 different
representations (a list of terms and a single {{MultiItemTerminal}}.
* Simplify the {{AbstractMarker}} hierachy
--
This message was sent by Atlassian Jira
(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-18579) No link to source packages
[ https://issues.apache.org/jira/browse/CASSANDRA-18579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18579: --- Status: Ready to Commit (was: Review In Progress) > No link to source packages > -- > > Key: CASSANDRA-18579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18579 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Sebb >Assignee: Michael Semb Wever >Priority: Normal > Labels: policy > > I could not find a link to download source releases. > They should be provided alongside the binary releases. -- This message was sent by Atlassian Jira (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-18579) No link to source packages
[ https://issues.apache.org/jira/browse/CASSANDRA-18579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754969#comment-17754969 ] Benjamin Lerer commented on CASSANDRA-18579: Thanks [~mck]. The patch looks good to me. > No link to source packages > -- > > Key: CASSANDRA-18579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18579 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Sebb >Assignee: Michael Semb Wever >Priority: Normal > Labels: policy > > I could not find a link to download source releases. > They should be provided alongside the binary releases. -- This message was sent by Atlassian Jira (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-18579) No link to source packages
[ https://issues.apache.org/jira/browse/CASSANDRA-18579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18579: --- Reviewers: Benjamin Lerer, Benjamin Lerer Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer) Status: Review In Progress (was: Patch Available) > No link to source packages > -- > > Key: CASSANDRA-18579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18579 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Sebb >Assignee: Michael Semb Wever >Priority: Normal > Labels: policy > > I could not find a link to download source releases. > They should be provided alongside the binary releases. -- This message was sent by Atlassian Jira (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-18579) No link to source packages
[ https://issues.apache.org/jira/browse/CASSANDRA-18579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754148#comment-17754148 ] Benjamin Lerer commented on CASSANDRA-18579: There is a link to the source package for all the versions. Unfortunately it is true that these links are accessible through the archive link which is confusing. > No link to source packages > -- > > Key: CASSANDRA-18579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18579 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Sebb >Priority: Normal > > I could not find a link to download source releases. > They should be provided alongside the binary releases. -- This message was sent by Atlassian Jira (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-15254) Allow UPDATE on settings virtual table to change running configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753947#comment-17753947 ] Benjamin Lerer commented on CASSANDRA-15254: It is :-) > Allow UPDATE on settings virtual table to change running configurations > --- > > Key: CASSANDRA-15254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15254 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Chris Lohfink >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Attachments: Configuration Registry Diagram.png > > Time Spent: 19h 50m > Remaining Estimate: 0h > > Allow using UPDATE on the system_views.settings virtual table to update > configs at runtime for the equivalent of the dispersed JMX > attributes/operations. -- This message was sent by Atlassian Jira (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-17163) High CAS failures in MemtablePool.SubPool.tryAllocate
[
https://issues.apache.org/jira/browse/CASSANDRA-17163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17163:
---
Resolution: Duplicate
Status: Resolved (was: Open)
> High CAS failures in MemtablePool.SubPool.tryAllocate
> -
>
> Key: CASSANDRA-17163
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17163
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> In a cluster using {{memtable_allocation_type: offheap_buffers}} which handle
> a high amount of writes we are seeing some high contentions on
> {{MemtablePool.SubPool.tryAllocate}}.
> {code}"MutationStage-561" #5457 daemon prio=5 os_prio=0
> tid=0x7f35dd3cfa50 nid=0x1407a runnable [0x7f2357fd5000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.tryAllocate(MemtablePool.java:159)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.allocate(MemtableAllocator.java:175)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.allocate(SlabAllocator.java:89)
> at
> org.apache.cassandra.utils.memory.ContextAllocator.allocate(ContextAllocator.java:57)
> at
> org.apache.cassandra.utils.memory.ContextAllocator.clone(ContextAllocator.java:47)
> at org.apache.cassandra.db.rows.BufferCell.copy(BufferCell.java:140)
> at
> org.apache.cassandra.utils.memory.AbstractAllocator$CloningBTreeRowBuilder.addCell(AbstractAllocator.java:89)
> at org.apache.cassandra.db.rows.Rows.copy(Rows.java:49)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:370)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:333)
> at org.apache.cassandra.utils.btree.BTree.buildLeaf(BTree.java:195)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:208)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:227)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:254)
> at org.apache.cassandra.utils.btree.BTree.build(BTree.java:177)
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:283)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDeltaInternal(AtomicBTreePartition.java:143)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDelta(AtomicBTreePartition.java:184)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:295)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1335)
> at
> org.apache.cassandra.db.CassandraTableWriteHandler.write(CassandraTableWriteHandler.java:40)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:661)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:513)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:215)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:220)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:229)
> at
> org.apache.cassandra.service.StorageProxy$$Lambda$1019/640627333.run(Unknown
> Source)
> at
> org.apache.cassandra.service.StorageProxy$4.runMayThrow(StorageProxy.java:1544)
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable$1.runMayThrow(StorageProxy.java:2314)
> at
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2352)
> 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:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {code}
> This issue is similar to CASSANDRA-15922.
--
This message was sent by Atlassian Jira
(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-18702) Add jmh microbenchmarks to eclipse IDE
[ https://issues.apache.org/jira/browse/CASSANDRA-18702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18702: --- Reviewers: Benjamin Lerer > Add jmh microbenchmarks to eclipse IDE > -- > > Key: CASSANDRA-18702 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18702 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.x > > > Currently jmh tests are not being picked up by the Eclipse IDE. -- This message was sent by Atlassian Jira (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-18708) Test failure: org.apache.cassandra.tools.StandaloneSplitterWithCQLTesterTest.testNoSnapshotOption-.jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-18708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18708:
---
Reviewers: Benjamin Lerer
> Test failure:
> org.apache.cassandra.tools.StandaloneSplitterWithCQLTesterTest.testNoSnapshotOption-.jdk17
>
>
> Key: CASSANDRA-18708
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18708
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1650/testReport/junit/org.apache.cassandra.tools/StandaloneSplitterWithCQLTesterTest/testNoSnapshotOption__jdk17/]
> h3.
> {code:java}
> Error Message
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> final sun.nio.fs.UnixFileSystem sun.nio.fs.UnixPath.fs accessible: module
> java.base does not "opens sun.nio.fs" to unnamed module @1f28c152 at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172) at
> org.apache.cassandra.utils.concurrent.Ref.getFields(Ref.java:656) at
> org.apache.cassandra.utils.concurrent.Ref$Visitor.traverse(Ref.java:613) at
> org.apache.cassandra.utils.concurrent.Ref$Visitor.run(Ref.java:568) at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at
> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> {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-18655) Unfinalise AbstractVirtualTable.select(..) for downstream patches
[
https://issues.apache.org/jira/browse/CASSANDRA-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742328#comment-17742328
]
Benjamin Lerer commented on CASSANDRA-18655:
After thinking a bit more about it, I realised that I am confused by this
ticket.
This ticket is not a proposal for a new virtual table implementation. It is
just a request for removing some {{final}} keywords. As there is no mechanims
to dynamically add virtual tables or virtual keyspaces to the virtual schema
this change is simply useless and confusing.
If we want to allow to plug-in virtual tables, I think that the proposal hould
be done as a CEP where the scope of what we want to allow as well as the API is
clearly defined.
> Unfinalise AbstractVirtualTable.select(..) for downstream patches
> -
>
> Key: CASSANDRA-18655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18655
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> In AbstractVirtualTable the select methods are final. This prevents
> downstream C* engineers from implementing their own virtual tables where the
> select needs to be overridden.
> This is not a C* API and is not intended for C* users and operators.
> Extension of these methods should also clearly marked as experimental with no
> maintenance or compatibility provided from any release to another (including
> patch versions).
> The original proposal for Virtual Tables (CASSANDRA-7622) was to have a table
> "backed by an API, rather than data explicitly managed and stored as
> sstables". A number of people on the ticket supported the eventual idea of
> user-defined Virtual Tables. The consensus was that an incremental approach
> should be taken, where this should not be part of the initial implementation,
> and that use-cases and careful consideration around API security and
> compatibility would be needed.
> The next incremental approach can be to permit downstream patches to
> experiment against an explicitly labelled experimental (non-stable) internal
> code (so to protect the C* community from security and compatibility
> concerns). Such experiments will help smoke out and promote more grounded
> discussions for further work, if so found and desired.
> The patch is two lines: to remove the final keyword from both select(..)
> methods; and adding whatever comment/annotation we need to state their
> experimental/non-stable state and limited audience.
--
This message was sent by Atlassian Jira
(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-18655) Unfinalise AbstractVirtualTable.select(..) for downstream patches
[
https://issues.apache.org/jira/browse/CASSANDRA-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740954#comment-17740954
]
Benjamin Lerer commented on CASSANDRA-18655:
If people wish to create their own VirtualTable implementation they can simply
extend the {{VirtualTable}} interface. The {{final}} keyword in
{{AbstractVirtualTable}} is to prevent people extending that class to misuse
it.
??The consensus was that an incremental approach should be taken, where this
should not be part of the initial implementation, and that use-cases and
careful consideration around API security and compatibility would be needed.??
I do not recall such consensus. On the other hand I recall long discussions
that blocked the ticket for around 2 years. In the end the choice was made to
use Virtual tables only for exposing local node internal information and that
is what the current implementation support.
> Unfinalise AbstractVirtualTable.select(..) for downstream patches
> -
>
> Key: CASSANDRA-18655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18655
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
>
> In AbstractVirtualTable the select methods are final. This prevents
> downstream C* engineers from implementing their own virtual tables where the
> select needs to be overridden.
> This is not a C* API and is not intended for C* users and operators.
> Extension of these methods should also clearly marked as experimental with no
> maintenance or compatibility provided from any release to another (including
> patch versions).
> The original proposal for Virtual Tables (CASSANDRA-7622) was to have a table
> "backed by an API, rather than data explicitly managed and stored as
> sstables". A number of people on the ticket supported the eventual idea of
> user-defined Virtual Tables. The consensus was that an incremental approach
> should be taken, where this should not be part of the initial implementation,
> and that use-cases and careful consideration around API security and
> compatibility would be needed.
> The next incremental approach can be to permit downstream patches to
> experiment against an explicitly labelled experimental (non-stable) internal
> code (so to protect the C* community from security and compatibility
> concerns). Such experiments will help smoke out and promote more grounded
> discussions for further work, if so found and desired.
> The patch is two lines: to remove the final keyword from both select(..)
> methods; and adding whatever comment/annotation we need to state their
> experimental/non-stable state and limited audience.
--
This message was sent by Atlassian Jira
(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-18584) CEP-29: NOT operator
[ https://issues.apache.org/jira/browse/CASSANDRA-18584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18584: --- Reviewers: Benjamin Lerer > CEP-29: NOT operator > > > Key: CASSANDRA-18584 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18584 > Project: Cassandra > Issue Type: New Feature > Components: CQL/Interpreter, CQL/Semantics, CQL/Syntax, Feature/SAI >Reporter: Piotr Kolaczkowski >Assignee: Piotr Kolaczkowski >Priority: Normal > > Implement new CQL operators: > - NOT CONTAINS, > - NOT CONTAINS KEY, > - NOT IN > - NOT LIKE > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+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-18584) CEP-29: NOT operator
[ https://issues.apache.org/jira/browse/CASSANDRA-18584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18584: --- Change Category: Semantic Complexity: Normal Status: Open (was: Triage Needed) > CEP-29: NOT operator > > > Key: CASSANDRA-18584 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18584 > Project: Cassandra > Issue Type: New Feature > Components: CQL/Interpreter, CQL/Semantics, CQL/Syntax, Feature/SAI >Reporter: Piotr Kolaczkowski >Assignee: Piotr Kolaczkowski >Priority: Normal > > Implement new CQL operators: > - NOT CONTAINS, > - NOT CONTAINS KEY, > - NOT IN > - NOT LIKE > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+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] [Commented] (CASSANDRA-11745) Add bytes limit to queries and paging
[
https://issues.apache.org/jira/browse/CASSANDRA-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730489#comment-17730489
]
Benjamin Lerer commented on CASSANDRA-11745:
After quickly skimming the patch, it feels to me that the is a difference
between the original goal of this ticket and of the patch. My understanding of
[~slebresne] explanation was that the goal of this patch is about allowing the
user to LIMIT by byte and _page_ by byte. What the patch does is to introduce
a way to page by bytes instead of by rows but it seems to use that mechanism
only for 2 scenarios which are internal paging for {{aggregation}}/{{group by}}
queries and for rebuilding secondary indices. The values for those have to be
configured within the config file. It is valuable but different from the
original goal even if the functionality can probably be reused to build those
other functionalities. So we should probably open another ticket with a clear
description of the goal and moved the patch there to avoid confusing people.
The patch being significant in terms of changes. The review will take some time
in my side.
> Add bytes limit to queries and paging
> -
>
> Key: CASSANDRA-11745
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11745
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Richard Low
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For some data models, values may be of very different sizes. When querying
> data, limit by count doesn’t work well and leads to timeouts. It would be
> much better to limit by size of the response, probably by stopping at the
> first row that goes above the limit. This applies to paging too so you can
> safely page through such data without timeout worries.
--
This message was sent by Atlassian Jira
(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-11745) Add bytes limit to queries and paging
[ https://issues.apache.org/jira/browse/CASSANDRA-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-11745: --- Reviewers: Benjamin Lerer, Josh McKenzie (was: Josh McKenzie) > Add bytes limit to queries and paging > - > > Key: CASSANDRA-11745 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11745 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Richard Low >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > For some data models, values may be of very different sizes. When querying > data, limit by count doesn’t work well and leads to timeouts. It would be > much better to limit by size of the response, probably by stopping at the > first row that goes above the limit. This applies to paging too so you can > safely page through such data without timeout worries. -- This message was sent by Atlassian Jira (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-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729727#comment-17729727
]
Benjamin Lerer edited comment on CASSANDRA-17047 at 6/6/23 12:57 PM:
-
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
was (Author: blerer):
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
>
[jira] [Comment Edited] (CASSANDRA-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729727#comment-17729727
]
Benjamin Lerer edited comment on CASSANDRA-17047 at 6/6/23 12:56 PM:
-
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
was (Author: blerer):
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[
j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
>
[jira] [Comment Edited] (CASSANDRA-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729727#comment-17729727
]
Benjamin Lerer edited comment on CASSANDRA-17047 at 6/6/23 12:55 PM:
-
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[
j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
was (Author: blerer):
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11,
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[
j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
>
[jira] [Commented] (CASSANDRA-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729727#comment-17729727
]
Benjamin Lerer commented on CASSANDRA-17047:
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11,
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[
j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[main/:na]
> ...
> {code}
> Note that it doesn't matter if we {{SELECT *}} or {{SELECT id, v1}}
> CASSANDRA-15899 tried to fix the problem when columns are dropped as well as
> when columns are added. Unfortunately the fix introduced an issue and had to
> be reverted in CASSANDRA-16735.
> If the scenario for ADDED columns is tricky, the original scenario for
> DROPPED columns can be solved in a safe way at the {{ColumnFilter}} level.
> By consequence, I think that we should at least solve that scenario.
> [~bdeggleston], [~samt], [~ifesdjeen] does my proposal makes sense to you?
--
This message was sent by Atlassian Jira
(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-18566) Avoid unnecessary deserialization of terminal arguments when executing CQL functions
[
https://issues.apache.org/jira/browse/CASSANDRA-18566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18566:
---
Reviewers: Benjamin Lerer
> Avoid unnecessary deserialization of terminal arguments when executing CQL
> functions
>
>
> Key: CASSANDRA-18566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18566
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CQL functions unnecessarily deserialize their terminal arguments on every
> call.
> For example, the function call in {{SELECT mask_inner(column, 1, 0) FROM t}}
> deserializes {{1}} and {{2}} for each returned row. As another example, the
> selector in {{SELECT column * 2 FROM t}} also deserializes {{2}} for each
> returned row.
> The goal of this ticket is to improve the function execution code to avoid
> those deserializations.
--
This message was sent by Atlassian Jira
(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-18329) Upgrade jamm
[ https://issues.apache.org/jira/browse/CASSANDRA-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-18329: -- Assignee: Benjamin Lerer > Upgrade jamm > > > Key: CASSANDRA-18329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18329 > Project: Cassandra > Issue Type: Task > Components: Jamm >Reporter: Ekaterina Dimitrova >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Jamm is currently under maintenance that will solve JDK11 issues and enable > it to work with post JDK11+ versions up to JDK17. > This ticket will serve as a placeholder for upgrading Jamm in Cassandra when > the new Jamm release is out. -- This message was sent by Atlassian Jira (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-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725692#comment-17725692
]
Benjamin Lerer commented on CASSANDRA-17047:
I will refresh the work and push new patches today.
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[main/:na]
> ...
> {code}
> Note that it doesn't matter if we {{SELECT *}} or {{SELECT id, v1}}
> CASSANDRA-15899 tried to fix the problem when columns are dropped as well as
> when columns are added. Unfortunately the fix introduced an issue and had to
> be reverted in CASSANDRA-16735.
> If the scenario for ADDED columns is tricky, the original scenario for
> DROPPED columns can be solved in a safe way at the {{ColumnFilter}} level.
> By consequence, I think that we should at least solve that scenario.
> [~bdeggleston], [~samt], [~ifesdjeen] does my proposal makes sense to you?
--
This message was sent by Atlassian Jira
(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-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721839#comment-17721839
]
Benjamin Lerer edited comment on CASSANDRA-17918 at 5/11/23 4:07 PM:
-
Sorry, I am late but adding my +1 for the record. Thanks [~smiklosovic]
was (Author: blerer):
Sorry, I am late but adding my +1 for the record.
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.10, 4.1.2, 5.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> SchemaElement.toCqlString}}
--
This message was sent by Atlassian Jira
(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-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721839#comment-17721839
]
Benjamin Lerer commented on CASSANDRA-17918:
Sorry, I am late but adding my +1 for the record.
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.10, 4.1.2, 5.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> SchemaElement.toCqlString}}
--
This message was sent by Atlassian Jira
(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-18346) Error Unknown column during deserialization missing keyspace and table name
[
https://issues.apache.org/jira/browse/CASSANDRA-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720862#comment-17720862
]
Benjamin Lerer commented on CASSANDRA-18346:
The main reason for a Column to be missing is schema propagation. See
CASSANDRA-17047 and CASSANDRA-15899.
> Error Unknown column during deserialization missing keyspace and table name
> ---
>
> Key: CASSANDRA-18346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18346
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Low
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> The ERROR message generated in ColumnSubselection.java when a column name is
> not found only prints the column name, not the keyspace and table. It can be
> difficult to track down the source when more than one table uses the same
> name. E.g., 'id'.
> {quote}{{if (column == null)}}
> {
> {{ column = metadata.getDroppedColumn(name);}}
> {{ if (column == null)}}
> {{ throw new UnknownColumnException("Unknown column " +
> UTF8Type.instance.getString(name) + " during deserialization");}}
> {{}}}
> {quote}
> Example:
> [ERROR] cluster_id=15 ip_address=192.168.65.10 java.lang.RuntimeException:
> Unknown column id during deserialization
> Proposed:
> [ERROR] cluster_id=15 ip_address=192.168.65.10 java.lang.RuntimeException:
> Unknown column id in table cycling.route during deserialization
--
This message was sent by Atlassian Jira
(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-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719855#comment-17719855
]
Benjamin Lerer commented on CASSANDRA-17047:
I will.
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[main/:na]
> ...
> {code}
> Note that it doesn't matter if we {{SELECT *}} or {{SELECT id, v1}}
> CASSANDRA-15899 tried to fix the problem when columns are dropped as well as
> when columns are added. Unfortunately the fix introduced an issue and had to
> be reverted in CASSANDRA-16735.
> If the scenario for ADDED columns is tricky, the original scenario for
> DROPPED columns can be solved in a safe way at the {{ColumnFilter}} level.
> By consequence, I think that we should at least solve that scenario.
> [~bdeggleston], [~samt], [~ifesdjeen] does my proposal makes sense to you?
--
This message was sent by Atlassian Jira
(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-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719776#comment-17719776
]
Benjamin Lerer commented on CASSANDRA-17918:
[~smiklosovic] I would just add some function and aggregate to the
{{testDescribeRoundtrip}} testcase as a safety net to the problem you raised
but otherwise your patch looks good to me.
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> SchemaElement.toCqlString}}
--
This message was sent by Atlassian Jira
(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-18386) SelectStatement.asCQL fails with IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-18386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719761#comment-17719761
]
Benjamin Lerer commented on CASSANDRA-18386:
The problem is that the {{queriedColumns()}} is broken for any query that use
bind variables. As that method was only used by the logic used to create MVs it
was not originally a problem. We should change the signature to provide the
{{QueryOptions}} as an argument and probably change the method name as it is
confusing. What the method returns is a {{ColumnFilter}} not the queried
columns (that can be retrieved from the {{ColumnFilter}}.
There is no need for {{asCQL}} to call {{queriedColumns()}} as it has already
created the {{ColumnFilter}} correctly with the proper bind variable.
> SelectStatement.asCQL fails with IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-18386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18386
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Aleksandr Volochnev
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> See
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1934/workflows/2525f75d-a819-43db-8e89-c9d58cc8f4d7/jobs/18594
> {code}
> java.lang.IndexOutOfBoundsException: Index: 0
> at java.util.Collections$EmptyList.get(Collections.java:4456)
> at
> org.apache.cassandra.cql3.Constants$Marker.bindAndGet(Constants.java:470)
> at
> org.apache.cassandra.cql3.selection.ElementsSelector$1.newInstance(ElementsSelector.java:129)
> at
> org.apache.cassandra.cql3.selection.SelectorFactories.newInstances(SelectorFactories.java:206)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing$1.(Selection.java:564)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing.newSelectors(Selection.java:562)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.queriedColumns(SelectStatement.java:195)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.asCQL(SelectStatement.java:1634)
> {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] [Assigned] (CASSANDRA-18386) SelectStatement.asCQL fails with IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-18386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-18386:
--
Assignee: Aleksandr Volochnev (was: Benjamin Lerer)
> SelectStatement.asCQL fails with IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-18386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18386
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Aleksandr Volochnev
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> See
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1934/workflows/2525f75d-a819-43db-8e89-c9d58cc8f4d7/jobs/18594
> {code}
> java.lang.IndexOutOfBoundsException: Index: 0
> at java.util.Collections$EmptyList.get(Collections.java:4456)
> at
> org.apache.cassandra.cql3.Constants$Marker.bindAndGet(Constants.java:470)
> at
> org.apache.cassandra.cql3.selection.ElementsSelector$1.newInstance(ElementsSelector.java:129)
> at
> org.apache.cassandra.cql3.selection.SelectorFactories.newInstances(SelectorFactories.java:206)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing$1.(Selection.java:564)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing.newSelectors(Selection.java:562)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.queriedColumns(SelectStatement.java:195)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.asCQL(SelectStatement.java:1634)
> {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] [Assigned] (CASSANDRA-18386) SelectStatement.asCQL fails with IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-18386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-18386:
--
Assignee: Benjamin Lerer
> SelectStatement.asCQL fails with IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-18386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18386
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> See
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1934/workflows/2525f75d-a819-43db-8e89-c9d58cc8f4d7/jobs/18594
> {code}
> java.lang.IndexOutOfBoundsException: Index: 0
> at java.util.Collections$EmptyList.get(Collections.java:4456)
> at
> org.apache.cassandra.cql3.Constants$Marker.bindAndGet(Constants.java:470)
> at
> org.apache.cassandra.cql3.selection.ElementsSelector$1.newInstance(ElementsSelector.java:129)
> at
> org.apache.cassandra.cql3.selection.SelectorFactories.newInstances(SelectorFactories.java:206)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing$1.(Selection.java:564)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing.newSelectors(Selection.java:562)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.queriedColumns(SelectStatement.java:195)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.asCQL(SelectStatement.java:1634)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18386) SelectStatement.asCQL fails with IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-18386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18386:
---
Complexity: Low Hanging Fruit (was: Normal)
> SelectStatement.asCQL fails with IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-18386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18386
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> See
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1934/workflows/2525f75d-a819-43db-8e89-c9d58cc8f4d7/jobs/18594
> {code}
> java.lang.IndexOutOfBoundsException: Index: 0
> at java.util.Collections$EmptyList.get(Collections.java:4456)
> at
> org.apache.cassandra.cql3.Constants$Marker.bindAndGet(Constants.java:470)
> at
> org.apache.cassandra.cql3.selection.ElementsSelector$1.newInstance(ElementsSelector.java:129)
> at
> org.apache.cassandra.cql3.selection.SelectorFactories.newInstances(SelectorFactories.java:206)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing$1.(Selection.java:564)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing.newSelectors(Selection.java:562)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.queriedColumns(SelectStatement.java:195)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.asCQL(SelectStatement.java:1634)
> {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] (CASSANDRA-18386) SelectStatement.asCQL fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/CASSANDRA-18386 ]
Benjamin Lerer deleted comment on CASSANDRA-18386:
was (Author: blerer):
The problem is more complex than it looks at first.
{{SelectStatement.queriedColumns}} is obviously broken. Any query that use bind
variables will break on this method. It was not a problem in the past because
that method was only used for Materialized Views that do not use bind
variables. The error show up because the method is now used by {{asCQL}}.
I would like to mention here that {{asCQL}} should not exist. When a query
string is needed we should always use the original one and not attempt to
recreate one as this one might differ from the original query and will probably
differ more and more in the future as we will start rewriting queries more and
more for optimization purpose.
I believe that we need to do 2 things here:
# remove the asCQL method
# fix the {{queriedColumns}} method or refactor the code to make it clear that
the method is only for MVs or queries that do not have bind variables.
Removing the LHF flag as it is probably not a LHF ticket.
> SelectStatement.asCQL fails with IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-18386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18386
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> See
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1934/workflows/2525f75d-a819-43db-8e89-c9d58cc8f4d7/jobs/18594
> {code}
> java.lang.IndexOutOfBoundsException: Index: 0
> at java.util.Collections$EmptyList.get(Collections.java:4456)
> at
> org.apache.cassandra.cql3.Constants$Marker.bindAndGet(Constants.java:470)
> at
> org.apache.cassandra.cql3.selection.ElementsSelector$1.newInstance(ElementsSelector.java:129)
> at
> org.apache.cassandra.cql3.selection.SelectorFactories.newInstances(SelectorFactories.java:206)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing$1.(Selection.java:564)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing.newSelectors(Selection.java:562)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.queriedColumns(SelectStatement.java:195)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.asCQL(SelectStatement.java:1634)
> {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-18386) SelectStatement.asCQL fails with IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-18386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719748#comment-17719748
]
Benjamin Lerer commented on CASSANDRA-18386:
The problem is more complex than it looks at first.
{{SelectStatement.queriedColumns}} is obviously broken. Any query that use bind
variables will break on this method. It was not a problem in the past because
that method was only used for Materialized Views that do not use bind
variables. The error show up because the method is now used by {{asCQL}}.
I would like to mention here that {{asCQL}} should not exist. When a query
string is needed we should always use the original one and not attempt to
recreate one as this one might differ from the original query and will probably
differ more and more in the future as we will start rewriting queries more and
more for optimization purpose.
I believe that we need to do 2 things here:
# remove the asCQL method
# fix the {{queriedColumns}} method or refactor the code to make it clear that
the method is only for MVs or queries that do not have bind variables.
Removing the LHF flag as it is probably not a LHF ticket.
> SelectStatement.asCQL fails with IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-18386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18386
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> See
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1934/workflows/2525f75d-a819-43db-8e89-c9d58cc8f4d7/jobs/18594
> {code}
> java.lang.IndexOutOfBoundsException: Index: 0
> at java.util.Collections$EmptyList.get(Collections.java:4456)
> at
> org.apache.cassandra.cql3.Constants$Marker.bindAndGet(Constants.java:470)
> at
> org.apache.cassandra.cql3.selection.ElementsSelector$1.newInstance(ElementsSelector.java:129)
> at
> org.apache.cassandra.cql3.selection.SelectorFactories.newInstances(SelectorFactories.java:206)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing$1.(Selection.java:564)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing.newSelectors(Selection.java:562)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.queriedColumns(SelectStatement.java:195)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.asCQL(SelectStatement.java:1634)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18386) SelectStatement.asCQL fails with IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-18386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18386:
---
Complexity: Normal (was: Low Hanging Fruit)
> SelectStatement.asCQL fails with IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-18386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18386
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> See
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1934/workflows/2525f75d-a819-43db-8e89-c9d58cc8f4d7/jobs/18594
> {code}
> java.lang.IndexOutOfBoundsException: Index: 0
> at java.util.Collections$EmptyList.get(Collections.java:4456)
> at
> org.apache.cassandra.cql3.Constants$Marker.bindAndGet(Constants.java:470)
> at
> org.apache.cassandra.cql3.selection.ElementsSelector$1.newInstance(ElementsSelector.java:129)
> at
> org.apache.cassandra.cql3.selection.SelectorFactories.newInstances(SelectorFactories.java:206)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing$1.(Selection.java:564)
> at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing.newSelectors(Selection.java:562)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.queriedColumns(SelectStatement.java:195)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.asCQL(SelectStatement.java:1634)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18493) Add LIKE prefix/suffix support to SAI
[ https://issues.apache.org/jira/browse/CASSANDRA-18493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-18493: --- Summary: Add LIKE prefix/suffix support to SAI (was: Add LIKE prefix/suffix support) > Add LIKE prefix/suffix support to SAI > - > > Key: CASSANDRA-18493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18493 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Mike Adamson >Priority: Normal > > This should provide the following functionality: > * LIKE abc% - prefix support > * LIKE %bcd - suffix support > * LIKE %bc% - prefix/suffix support -- This message was sent by Atlassian Jira (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-15803) Separate out allow filtering scanning through a partition versus scanning over the table
[
https://issues.apache.org/jira/browse/CASSANDRA-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717514#comment-17717514
]
Benjamin Lerer edited comment on CASSANDRA-15803 at 4/28/23 8:19 AM:
-
I realized that my previous comment was confusing and simply wrong on some
parts. The problem of trying to do too much multi-tasking. So I want to have
another round at it ;-)
When I mentioned row filtering I was thinking at things like {{CONTAINS}} or
{{CONTAINS KEY}} that can pottentially have to go through a large collections
but we do not use AF for that so please ignore my over-heating brain.
For me {{ALLOW FILTERING}} is wrong at multiple level. The idea behind SQL was
a separation of concerns a user could ask for some data and it is up to the
database system to return them in the most efficient way. Which could be
through filtering (scan) if it was the most cost efficient thing. Like the
query that [~smiklosovic] mentioned. Filtering is not necessary bad in itself,
which is I believe is what [~jeromatron] has been trying to raise here.
Cassandra does not have a proper query optimizer yet (it is one thing I believe
will change soon) but if it had one, something like AF would not make sense at
the query level anymore because a user will be less efficient than a proper
optimizer at picking up the best access pattern. At this point we might still
want to be able to configure some safety nets but that will be an operator
level decision about what they believe is acceptable or not. I am not
advocating for removing AF at this point. Only when we will have a proper
optimizer.
was (Author: blerer):
I realized that my previous comment was confusing and simply wrong on some
parts. The problem of trying to do too much multi-tasking. So I want to have
another round at it ;-)
When I mentioned row filtering I was thinking at things like {{CONTAINS}} or
{{CONTAINS KEY}} that can pottentially have to go through a large collections
but we do not use AF for that so please ignore my over-heating brain.
For me {{ALLOW FILTERING}} is wrong at multiple level. The idea behind SQL was
a separation of concerns a user could ask for some data and it is up to the
database system to return them in the most efficient way. Which could be
through filtering (scan) if it was the most cost efficient thing. Like the
query that [~smiklosovic] mentioned. Filtering is not necessary bad in itself,
which is I believe what [~jeromatron] has been trying to raise here.
Cassandra does not have a proper query optimizer yet (it is one thing I believe
will change soon) but if it had something like AF would not make sense at the
query level anymore because a user will be less efficient than a proper
optimizer at picking up the best access pattern. At this point we might still
want to be able to configure some safety nets but that will be an operator
level decision about what they believe is acceptable or not. I am not
advocating for removing AF at this point only when we will have a proper
optimizer.
> Separate out allow filtering scanning through a partition versus scanning
> over the table
>
>
> Key: CASSANDRA-15803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15803
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Jeremy Hanna
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Currently allow filtering can mean two things in the spirit of "avoid
> operations that don't seek to a specific row or sequential rows of data."
> First, it can mean scanning across the entire table to meet the criteria of
> the query. That's almost always a bad thing and should be discouraged or
> disabled (see CASSANDRA-8303). Second, it can mean filtering within a
> specific partition. For example, in a query you could specify the full
> partition key and if you specify a criterion on a non-key field, it requires
> allow filtering.
> The second reason to require allow filtering is significantly less work to
> scan through a partition. It is still extra work over seeking to a specific
> row and getting N sequential rows though. So while an application developer
> and/or operator needs to be cautious about this second type, it's not
> necessarily a bad thing, depending on the table and the use case.
> I propose that we separate the way to specify allow filtering across an
> entire table from specifying allow filtering across a partition in a
> backwards compatible way. One idea that was brought up in Slack in the
> cassandra-dev room was to have allow filtering mean the superset - scanning
> across the table. Then if you want to specify that you *only* want to scan
> within a
[jira] [Comment Edited] (CASSANDRA-15803) Separate out allow filtering scanning through a partition versus scanning over the table
[
https://issues.apache.org/jira/browse/CASSANDRA-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717514#comment-17717514
]
Benjamin Lerer edited comment on CASSANDRA-15803 at 4/28/23 8:18 AM:
-
I realized that my previous comment was confusing and simply wrong on some
parts. The problem of trying to do too much multi-tasking. So I want to have
another round at it ;-)
When I mentioned row filtering I was thinking at things like {{CONTAINS}} or
{{CONTAINS KEY}} that can pottentially have to go through a large collections
but we do not use AF for that so please ignore my over-heating brain.
For me {{ALLOW FILTERING}} is wrong at multiple level. The idea behind SQL was
a separation of concerns a user could ask for some data and it is up to the
database system to return them in the most efficient way. Which could be
through filtering (scan) if it was the most cost efficient thing. Like the
query that [~smiklosovic] mentioned. Filtering is not necessary bad in itself,
which is I believe what [~jeromatron] has been trying to raise here.
Cassandra does not have a proper query optimizer yet (it is one thing I believe
will change soon) but if it had something like AF would not make sense at the
query level anymore because a user will be less efficient than a proper
optimizer at picking up the best access pattern. At this point we might still
want to be able to configure some safety nets but that will be an operator
level decision about what they believe is acceptable or not. I am not
advocating for removing AF at this point only when we will have a proper
optimizer.
was (Author: blerer):
I realized that my previous comment was confusing and simply wrong on some
parts. The problem of trying to do too much multi-tasking. So I want to have
another round at it ;-)
When I mentioned row filtering I was thinking at things like {{CONTAINS}} or
{{CONTAINS KEY}} that can pottentially have to go through a large collections
but we do not use AF for that so please ignore my over-heating brain.
For me {{ALLOW FILTERING}} is wrong at multiple level. The idea behind SQL was
a separation of concerns a user could ask for some data and it is up to the
database system to return them in the most efficient way. Which could be
through filtering (scan) if it was the most cost efficient thing. Like the
query that [~smiklosovic] mentioned. Filtering is not necessary bad in itself,
which is I believe what [~jeromatron] has been trying to raise here.
> Separate out allow filtering scanning through a partition versus scanning
> over the table
>
>
> Key: CASSANDRA-15803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15803
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Jeremy Hanna
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Currently allow filtering can mean two things in the spirit of "avoid
> operations that don't seek to a specific row or sequential rows of data."
> First, it can mean scanning across the entire table to meet the criteria of
> the query. That's almost always a bad thing and should be discouraged or
> disabled (see CASSANDRA-8303). Second, it can mean filtering within a
> specific partition. For example, in a query you could specify the full
> partition key and if you specify a criterion on a non-key field, it requires
> allow filtering.
> The second reason to require allow filtering is significantly less work to
> scan through a partition. It is still extra work over seeking to a specific
> row and getting N sequential rows though. So while an application developer
> and/or operator needs to be cautious about this second type, it's not
> necessarily a bad thing, depending on the table and the use case.
> I propose that we separate the way to specify allow filtering across an
> entire table from specifying allow filtering across a partition in a
> backwards compatible way. One idea that was brought up in Slack in the
> cassandra-dev room was to have allow filtering mean the superset - scanning
> across the table. Then if you want to specify that you *only* want to scan
> within a partition you would use something like
> {{ALLOW FILTERING [WITHIN PARTITION]}}
> So it will succeed if you specify non-key criteria within a single partition,
> but fail with a message to say it requires the full allow filtering. This
> would allow for a backwards compatible full allow filtering while allowing a
> user to specify that they want to just scan within a partition, but error out
> if trying to scan a full table.
> This is potentially also related to the capability limitation framework by
> which operators could more granularly
[jira] [Commented] (CASSANDRA-15803) Separate out allow filtering scanning through a partition versus scanning over the table
[
https://issues.apache.org/jira/browse/CASSANDRA-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717514#comment-17717514
]
Benjamin Lerer commented on CASSANDRA-15803:
I realized that my previous comment was confusing and simply wrong on some
parts. The problem of trying to do too much multi-tasking. So I want to have
another round at it ;-)
When I mentioned row filtering I was thinking at things like {{CONTAINS}} or
{{CONTAINS KEY}} that can pottentially have to go through a large collections
but we do not use AF for that so please ignore my over-heating brain.
For me {{ALLOW FILTERING}} is wrong at multiple level. The idea behind SQL was
a separation of concerns a user could ask for some data and it is up to the
database system to return them in the most efficient way. Which could be
through filtering (scan) if it was the most cost efficient thing. Like the
query that [~smiklosovic] mentioned. Filtering is not necessary bad in itself,
which is I believe what [~jeromatron] has been trying to raise here.
> Separate out allow filtering scanning through a partition versus scanning
> over the table
>
>
> Key: CASSANDRA-15803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15803
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Jeremy Hanna
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Currently allow filtering can mean two things in the spirit of "avoid
> operations that don't seek to a specific row or sequential rows of data."
> First, it can mean scanning across the entire table to meet the criteria of
> the query. That's almost always a bad thing and should be discouraged or
> disabled (see CASSANDRA-8303). Second, it can mean filtering within a
> specific partition. For example, in a query you could specify the full
> partition key and if you specify a criterion on a non-key field, it requires
> allow filtering.
> The second reason to require allow filtering is significantly less work to
> scan through a partition. It is still extra work over seeking to a specific
> row and getting N sequential rows though. So while an application developer
> and/or operator needs to be cautious about this second type, it's not
> necessarily a bad thing, depending on the table and the use case.
> I propose that we separate the way to specify allow filtering across an
> entire table from specifying allow filtering across a partition in a
> backwards compatible way. One idea that was brought up in Slack in the
> cassandra-dev room was to have allow filtering mean the superset - scanning
> across the table. Then if you want to specify that you *only* want to scan
> within a partition you would use something like
> {{ALLOW FILTERING [WITHIN PARTITION]}}
> So it will succeed if you specify non-key criteria within a single partition,
> but fail with a message to say it requires the full allow filtering. This
> would allow for a backwards compatible full allow filtering while allowing a
> user to specify that they want to just scan within a partition, but error out
> if trying to scan a full table.
> This is potentially also related to the capability limitation framework by
> which operators could more granularly specify what features are allowed or
> disallowed per user, discussed in CASSANDRA-8303. This way an operator could
> disallow the more general allow filtering while allowing the partition scan
> (or disallow them both at their discretion).
--
This message was sent by Atlassian Jira
(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-17919) Capital P gets confused in the parser for a Duration in places where IDENT are needed
[
https://issues.apache.org/jira/browse/CASSANDRA-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717043#comment-17717043
]
Benjamin Lerer commented on CASSANDRA-17919:
+1 :-)
> Capital P gets confused in the parser for a Duration in places where IDENT
> are needed
> -
>
> Key: CASSANDRA-17919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17919
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: David Capwell
>Assignee: Maxim Chanturiay
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This was found while adding Accord Transaction syntax into CQL and fuzz
> testing to validate all possible cases… in doing this the following was found
> {code}
> String query = "BEGIN TRANSACTION\n" +
>" LET P = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" LET row2 = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" SELECT v FROM " + keyspace + ".tbl WHERE k=?
> AND c=?;\n" +
>" IF P IS NULL AND row2.v = ? THEN\n" +
>"INSERT INTO " + keyspace + ".tbl (k, c, v)
> VALUES (?, ?, ?);\n" +
>" END IF\n" +
>"COMMIT TRANSACTION";
> {code}
> Fails with
> {code}
> SyntaxException: line 2:6 mismatched input 'P' expecting IDENT (BEGIN
> TRANSACTION LET [P]...)
> {code}
> The new LET syntax found this, but was able to reproduce in other cases
> {code}
> cqlsh:ks> CREATE TABLE P (k INT PRIMARY KEY);
> SyntaxException: line 1:13 no viable alternative at input 'P' (CREATE TABLE
> [P]...)
> cqlsh:ks>
> cqlsh:ks> CREATE TABLE p (k INT PRIMARY KEY);
> cqlsh:ks>
> {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-15803) Separate out allow filtering scanning through a partition versus scanning over the table
[
https://issues.apache.org/jira/browse/CASSANDRA-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717039#comment-17717039
]
Benjamin Lerer commented on CASSANDRA-15803:
I believe that we should be careful here. The way {{ALLOW FILTERING}} work
today is relatively simple. It will be required every time somebody does some
filtering. It does not matter at which level (across partitions, across rows or
within rows). Potentially each of them can be bad. Now, I agree that people
should decide what they are fine with: Multi-Partitions scan, Partitions scan
or Row scan. The question is what do you do with index queries that filter
across multiple rows? Do you consider it as equivalent to a partition scan?
Trying to extend the {{ALLOW FILTERING}} syntax will just make the language
more complicated. Most people already fail to understand it. It makes sense to
me to remove it and simply rely on a capability limitation framework, which
would let operator decide at a more granular level what to authorize and for
which keyspace or table.
> Separate out allow filtering scanning through a partition versus scanning
> over the table
>
>
> Key: CASSANDRA-15803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15803
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Jeremy Hanna
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Currently allow filtering can mean two things in the spirit of "avoid
> operations that don't seek to a specific row or sequential rows of data."
> First, it can mean scanning across the entire table to meet the criteria of
> the query. That's almost always a bad thing and should be discouraged or
> disabled (see CASSANDRA-8303). Second, it can mean filtering within a
> specific partition. For example, in a query you could specify the full
> partition key and if you specify a criterion on a non-key field, it requires
> allow filtering.
> The second reason to require allow filtering is significantly less work to
> scan through a partition. It is still extra work over seeking to a specific
> row and getting N sequential rows though. So while an application developer
> and/or operator needs to be cautious about this second type, it's not
> necessarily a bad thing, depending on the table and the use case.
> I propose that we separate the way to specify allow filtering across an
> entire table from specifying allow filtering across a partition in a
> backwards compatible way. One idea that was brought up in Slack in the
> cassandra-dev room was to have allow filtering mean the superset - scanning
> across the table. Then if you want to specify that you *only* want to scan
> within a partition you would use something like
> {{ALLOW FILTERING [WITHIN PARTITION]}}
> So it will succeed if you specify non-key criteria within a single partition,
> but fail with a message to say it requires the full allow filtering. This
> would allow for a backwards compatible full allow filtering while allowing a
> user to specify that they want to just scan within a partition, but error out
> if trying to scan a full table.
> This is potentially also related to the capability limitation framework by
> which operators could more granularly specify what features are allowed or
> disallowed per user, discussed in CASSANDRA-8303. This way an operator could
> disallow the more general allow filtering while allowing the partition scan
> (or disallow them both at their discretion).
--
This message was sent by Atlassian Jira
(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-17919) Capital P gets confused in the parser for a Duration in places where IDENT are needed
[
https://issues.apache.org/jira/browse/CASSANDRA-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17919:
---
Status: Review In Progress (was: Needs Committer)
> Capital P gets confused in the parser for a Duration in places where IDENT
> are needed
> -
>
> Key: CASSANDRA-17919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17919
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: David Capwell
>Assignee: Maxim Chanturiay
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This was found while adding Accord Transaction syntax into CQL and fuzz
> testing to validate all possible cases… in doing this the following was found
> {code}
> String query = "BEGIN TRANSACTION\n" +
>" LET P = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" LET row2 = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" SELECT v FROM " + keyspace + ".tbl WHERE k=?
> AND c=?;\n" +
>" IF P IS NULL AND row2.v = ? THEN\n" +
>"INSERT INTO " + keyspace + ".tbl (k, c, v)
> VALUES (?, ?, ?);\n" +
>" END IF\n" +
>"COMMIT TRANSACTION";
> {code}
> Fails with
> {code}
> SyntaxException: line 2:6 mismatched input 'P' expecting IDENT (BEGIN
> TRANSACTION LET [P]...)
> {code}
> The new LET syntax found this, but was able to reproduce in other cases
> {code}
> cqlsh:ks> CREATE TABLE P (k INT PRIMARY KEY);
> SyntaxException: line 1:13 no viable alternative at input 'P' (CREATE TABLE
> [P]...)
> cqlsh:ks>
> cqlsh:ks> CREATE TABLE p (k INT PRIMARY KEY);
> cqlsh:ks>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17919) Capital P gets confused in the parser for a Duration in places where IDENT are needed
[
https://issues.apache.org/jira/browse/CASSANDRA-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17919:
---
Reviewers: Benjamin Lerer, Stefan Miklosovic (was: Stefan Miklosovic)
> Capital P gets confused in the parser for a Duration in places where IDENT
> are needed
> -
>
> Key: CASSANDRA-17919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17919
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: David Capwell
>Assignee: Maxim Chanturiay
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This was found while adding Accord Transaction syntax into CQL and fuzz
> testing to validate all possible cases… in doing this the following was found
> {code}
> String query = "BEGIN TRANSACTION\n" +
>" LET P = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" LET row2 = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" SELECT v FROM " + keyspace + ".tbl WHERE k=?
> AND c=?;\n" +
>" IF P IS NULL AND row2.v = ? THEN\n" +
>"INSERT INTO " + keyspace + ".tbl (k, c, v)
> VALUES (?, ?, ?);\n" +
>" END IF\n" +
>"COMMIT TRANSACTION";
> {code}
> Fails with
> {code}
> SyntaxException: line 2:6 mismatched input 'P' expecting IDENT (BEGIN
> TRANSACTION LET [P]...)
> {code}
> The new LET syntax found this, but was able to reproduce in other cases
> {code}
> cqlsh:ks> CREATE TABLE P (k INT PRIMARY KEY);
> SyntaxException: line 1:13 no viable alternative at input 'P' (CREATE TABLE
> [P]...)
> cqlsh:ks>
> cqlsh:ks> CREATE TABLE p (k INT PRIMARY KEY);
> cqlsh:ks>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17919) Capital P gets confused in the parser for a Duration in places where IDENT are needed
[
https://issues.apache.org/jira/browse/CASSANDRA-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17919:
---
Status: Requires Testing (was: Review In Progress)
> Capital P gets confused in the parser for a Duration in places where IDENT
> are needed
> -
>
> Key: CASSANDRA-17919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17919
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: David Capwell
>Assignee: Maxim Chanturiay
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This was found while adding Accord Transaction syntax into CQL and fuzz
> testing to validate all possible cases… in doing this the following was found
> {code}
> String query = "BEGIN TRANSACTION\n" +
>" LET P = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" LET row2 = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" SELECT v FROM " + keyspace + ".tbl WHERE k=?
> AND c=?;\n" +
>" IF P IS NULL AND row2.v = ? THEN\n" +
>"INSERT INTO " + keyspace + ".tbl (k, c, v)
> VALUES (?, ?, ?);\n" +
>" END IF\n" +
>"COMMIT TRANSACTION";
> {code}
> Fails with
> {code}
> SyntaxException: line 2:6 mismatched input 'P' expecting IDENT (BEGIN
> TRANSACTION LET [P]...)
> {code}
> The new LET syntax found this, but was able to reproduce in other cases
> {code}
> cqlsh:ks> CREATE TABLE P (k INT PRIMARY KEY);
> SyntaxException: line 1:13 no viable alternative at input 'P' (CREATE TABLE
> [P]...)
> cqlsh:ks>
> cqlsh:ks> CREATE TABLE p (k INT PRIMARY KEY);
> cqlsh:ks>
> {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-17919) Capital P gets confused in the parser for a Duration in places where IDENT are needed
[
https://issues.apache.org/jira/browse/CASSANDRA-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716607#comment-17716607
]
Benjamin Lerer commented on CASSANDRA-17919:
The patches look good to me. Thanks [~maximc]
> Capital P gets confused in the parser for a Duration in places where IDENT
> are needed
> -
>
> Key: CASSANDRA-17919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17919
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: David Capwell
>Assignee: Maxim Chanturiay
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> This was found while adding Accord Transaction syntax into CQL and fuzz
> testing to validate all possible cases… in doing this the following was found
> {code}
> String query = "BEGIN TRANSACTION\n" +
>" LET P = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" LET row2 = (SELECT v FROM " + keyspace + ".tbl
> WHERE k=? AND c=?);\n" +
>" SELECT v FROM " + keyspace + ".tbl WHERE k=?
> AND c=?;\n" +
>" IF P IS NULL AND row2.v = ? THEN\n" +
>"INSERT INTO " + keyspace + ".tbl (k, c, v)
> VALUES (?, ?, ?);\n" +
>" END IF\n" +
>"COMMIT TRANSACTION";
> {code}
> Fails with
> {code}
> SyntaxException: line 2:6 mismatched input 'P' expecting IDENT (BEGIN
> TRANSACTION LET [P]...)
> {code}
> The new LET syntax found this, but was able to reproduce in other cases
> {code}
> cqlsh:ks> CREATE TABLE P (k INT PRIMARY KEY);
> SyntaxException: line 1:13 no viable alternative at input 'P' (CREATE TABLE
> [P]...)
> cqlsh:ks>
> cqlsh:ks> CREATE TABLE p (k INT PRIMARY KEY);
> cqlsh:ks>
> {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-17281) Add hooks for the Javascript UDF to enable people to plugin their own implementations of scripted UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-17281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716245#comment-17716245 ] Benjamin Lerer commented on CASSANDRA-17281: [~mck] there is a relation somehow but I do not intend to tackle CASSANDRA-9892 at this point. > Add hooks for the Javascript UDF to enable people to plugin their own > implementations of scripted UDFs > -- > > Key: CASSANDRA-17281 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17281 > Project: Cassandra > Issue Type: Task > Components: Feature/UDF >Reporter: Ekaterina Dimitrova >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 5.x > > > [Consensus |https://lists.apache.org/thread/mnxh94lg9v94bfntq88051z3ww16q2fk] > was reached to remove JavaScript UDF with the next major release. > We need to leave an interface for those who would like to supply a UDF > implementation. -- This message was sent by Atlassian Jira (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-17850) Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without opening internals
[
https://issues.apache.org/jira/browse/CASSANDRA-17850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17850:
--
Assignee: Benjamin Lerer
> Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without
> opening internals
> ---
>
> Key: CASSANDRA-17850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17850
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
>
> With Java 17 if we do not add below to the jvm17 server options:
> {code:java}
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED{code}
> we get on startup (considering I comment out the scripted UDFs and apply a
> few changes to the startup scripts):
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:29:25,652
> JVMStabilityInspector.java:68 - Exception in thread
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException:
> Unable to make field private int java.io.FileDescriptor.fd accessible: module
> java.base does not "opens java.io" to unnamed module @11d8ae8b
> at
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:84)
> at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
> at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
> at
> org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
> at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
> at
> org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
> at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
> at
> org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
> at org.apache.cassandra.service.StorageService.(StorageService.java:376)
> at
> org.apache.cassandra.service.StorageService.(StorageService.java:226)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private int java.io.FileDescriptor.fd accessible: module java.base does
> not "opens java.io" to unnamed module @11d8ae8b
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
> ... 20 common frames omitted
> {code}
> and
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:31:18,443
> JVMStabilityInspector.java:68 - Exception in thread
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException:
> Unable to make field private final java.io.FileDescriptor
> sun.nio.ch.FileChannelImpl.fd accessible: module java.base does not "opens
> sun.nio.ch" to unnamed module @4c012563
> at
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:87)
> at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
> at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
> at
> org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
> at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
> at
> org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
> at
[jira] [Commented] (CASSANDRA-18329) Upgrade jamm
[
https://issues.apache.org/jira/browse/CASSANDRA-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715639#comment-17715639
]
Benjamin Lerer commented on CASSANDRA-18329:
We have heavily worked on Jamm and at this point its outcome will be more
correct than the results provided by {{RamUsageEstimator}} for the different
JVM versions. Jamm is also able to measure things that {{RamUsageEstimator}}
will fail to measure like (module protected fields, hidden classes or records).
Jamm provides also some features used by C* that {{RamUsageEstimator}} does
not provide (the ability to ignore some classes, advanced filtering to avoid
scanning large portion of the JVM internals ...).
One thing that {{RamUsageEstimator}} has and that we did not provide is caching
when crawling a graph of object but we can add that feature.
> Upgrade jamm
>
>
> Key: CASSANDRA-18329
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18329
> Project: Cassandra
> Issue Type: Task
> Components: Jamm
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> Jamm is currently under maintenance that will solve JDK11 issues and enable
> it to work with post JDK11+ versions up to JDK17.
> This ticket will serve as a placeholder for upgrading Jamm in Cassandra when
> the new Jamm release is out.
--
This message was sent by Atlassian Jira
(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-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17708424#comment-17708424 ] Benjamin Lerer commented on CASSANDRA-16895: Once Accord is working as part of the C* code base I do not understand how it could use a different JDK. I have never looked into the simulator but my understanding was that it is run together with C* for testing. I am a bit confused. > Build with Java 17 > -- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Epic > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > This ticket is intended to group all issues found to support Java 17 in the > future. > Upgrade steps: > * [Dependencies > |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to > be updated (not all but at least those that require an update in order to > work with Java 17) > * More encapsulated JDK internal APIs. Some of the issues might be solved > with the dependencies updates > * Currently trunk compiles if we remove the Nashorn dependency (ant script > tag, used for the test environment; UDFs) . The oracle recommendation to use > Nashorn-core won't work for the project as it is under GPL 2.0. Most probably > we will opt in for graal-sdk licensed under UPL > * All tests to be cleaned > * CI environment to be setup > *NOTE:* GC tuning, performance testing were never agreed to be part of this > ticket. > Below is a snapshot of current CI failures with JDK17, it will be updated on > a regular basis with a date of update > *March 19th 2023* > || ||Failing Test Classes||Ticket Numbers|| > | |_Python DTests_| | > |1|test_sjk|CASSANDRA-18343| > | |_Java Ditributed Tests_| | > |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all > tests, > org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, > org.apache.cassandra.distributed.test.IPMembershipTest - both tests, > org.apache.cassandra.distributed.test.MixedModeFuzzTest, > org.apache.cassandra.distributed.test.ReprepareFuzzTest, > org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| > |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest > - all tests > org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all > tests|Could be related to CASSANDRA-18180, to be checked | > |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - > 2 tests|CASSANDRA-18180| > | |_Unit Tests_| | > |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| > |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| > |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest, > org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329| > |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest, > org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190| > | | | | > | | | | > -- This message was sent by Atlassian Jira (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-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707940#comment-17707940 ] Benjamin Lerer edited comment on CASSANDRA-16895 at 4/3/23 12:06 PM: - I must admit that I am touchy on the subject because what I learned from working on Jamm was that we really under estimated the potential impact of the JDK changes. My guess is that some of our dependencies had also to adapt a lot. So as much as I would like to support more JDK versions, I believe that we have to be realistic about it and do not only assume that because it compiles with a JDK version people can use it with that version safely. It is for me a big _swim at your own risk ... and by the way this area is known for its vast variety of sharks_ . was (Author: blerer): I must admit that I am touchy on the subject because what I learned from working on Jamm was that we really under estimated the potential impact of the JDK changes. My guess is that some of our dependencies had also to adapt a lot. So as much as I would like to support more JDK versions, I believe that we have to be realistic about it and do not only assume that because it compiles with a JDK version people can use it with that version safely. It is for me a big _swim at your own risk ... and by the way this area its know for its vast variety of sharks_ . > Build with Java 17 > -- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Epic > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > This ticket is intended to group all issues found to support Java 17 in the > future. > Upgrade steps: > * [Dependencies > |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to > be updated (not all but at least those that require an update in order to > work with Java 17) > * More encapsulated JDK internal APIs. Some of the issues might be solved > with the dependencies updates > * Currently trunk compiles if we remove the Nashorn dependency (ant script > tag, used for the test environment; UDFs) . The oracle recommendation to use > Nashorn-core won't work for the project as it is under GPL 2.0. Most probably > we will opt in for graal-sdk licensed under UPL > * All tests to be cleaned > * CI environment to be setup > *NOTE:* GC tuning, performance testing were never agreed to be part of this > ticket. > Below is a snapshot of current CI failures with JDK17, it will be updated on > a regular basis with a date of update > *March 19th 2023* > || ||Failing Test Classes||Ticket Numbers|| > | |_Python DTests_| | > |1|test_sjk|CASSANDRA-18343| > | |_Java Ditributed Tests_| | > |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all > tests, > org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, > org.apache.cassandra.distributed.test.IPMembershipTest - both tests, > org.apache.cassandra.distributed.test.MixedModeFuzzTest, > org.apache.cassandra.distributed.test.ReprepareFuzzTest, > org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| > |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest > - all tests > org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all > tests|Could be related to CASSANDRA-18180, to be checked | > |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - > 2 tests|CASSANDRA-18180| > | |_Unit Tests_| | > |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| > |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| > |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest, > org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329| > |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest, > org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190| > | | | | > | | | | > -- This message was sent by Atlassian Jira (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-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707940#comment-17707940 ] Benjamin Lerer edited comment on CASSANDRA-16895 at 4/3/23 12:05 PM: - I must admit that I am touchy on the subject because what I learned from working on Jamm was that we really under estimated the potential impact of the JDK changes. My guess is that some of our dependencies had also to adapt a lot. So as much as I would like to support more JDK versions, I believe that we have to be realistic about it and do not only assume that because it compiles with a JDK version people can use it with that version safely. It is for me a big _swim at your own risk ... and by the way this area its know for its vast variety of sharks_ . was (Author: blerer): I must admit that I am touchy on the subject because what I learned from working on Jamm was that we really under estimated the potential impact of the JDK changes. My guess is that some of our dependencies had also to adapt a lot. So as much as I would like to support more JDK, I believe that we have to be realistic about it and do not only assume that because it compiles with a JDK version people can use it with that version safely. It is for me a big _swim at your own risk ... and by the way this area its know for its vast variety of sharks_ . > Build with Java 17 > -- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Epic > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > This ticket is intended to group all issues found to support Java 17 in the > future. > Upgrade steps: > * [Dependencies > |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to > be updated (not all but at least those that require an update in order to > work with Java 17) > * More encapsulated JDK internal APIs. Some of the issues might be solved > with the dependencies updates > * Currently trunk compiles if we remove the Nashorn dependency (ant script > tag, used for the test environment; UDFs) . The oracle recommendation to use > Nashorn-core won't work for the project as it is under GPL 2.0. Most probably > we will opt in for graal-sdk licensed under UPL > * All tests to be cleaned > * CI environment to be setup > *NOTE:* GC tuning, performance testing were never agreed to be part of this > ticket. > Below is a snapshot of current CI failures with JDK17, it will be updated on > a regular basis with a date of update > *March 19th 2023* > || ||Failing Test Classes||Ticket Numbers|| > | |_Python DTests_| | > |1|test_sjk|CASSANDRA-18343| > | |_Java Ditributed Tests_| | > |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all > tests, > org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, > org.apache.cassandra.distributed.test.IPMembershipTest - both tests, > org.apache.cassandra.distributed.test.MixedModeFuzzTest, > org.apache.cassandra.distributed.test.ReprepareFuzzTest, > org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| > |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest > - all tests > org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all > tests|Could be related to CASSANDRA-18180, to be checked | > |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - > 2 tests|CASSANDRA-18180| > | |_Unit Tests_| | > |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| > |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| > |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest, > org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329| > |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest, > org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190| > | | | | > | | | | > -- This message was sent by Atlassian Jira (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-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707940#comment-17707940 ] Benjamin Lerer commented on CASSANDRA-16895: I must admit that I am touchy on the subject because what I learned from working on Jamm was that we really under estimated the potential impact of the JDK changes. My guess is that some of our dependencies had also to adapt a lot. So as much as I would like to support more JDK, I believe that we have to be realistic about it and do not only assume that because it compiles with a JDK version people can use it with that version safely. It is for me a big _swim at your own risk ... and by the way this area its know for its vast variety of sharks_ . > Build with Java 17 > -- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Epic > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > This ticket is intended to group all issues found to support Java 17 in the > future. > Upgrade steps: > * [Dependencies > |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to > be updated (not all but at least those that require an update in order to > work with Java 17) > * More encapsulated JDK internal APIs. Some of the issues might be solved > with the dependencies updates > * Currently trunk compiles if we remove the Nashorn dependency (ant script > tag, used for the test environment; UDFs) . The oracle recommendation to use > Nashorn-core won't work for the project as it is under GPL 2.0. Most probably > we will opt in for graal-sdk licensed under UPL > * All tests to be cleaned > * CI environment to be setup > *NOTE:* GC tuning, performance testing were never agreed to be part of this > ticket. > Below is a snapshot of current CI failures with JDK17, it will be updated on > a regular basis with a date of update > *March 19th 2023* > || ||Failing Test Classes||Ticket Numbers|| > | |_Python DTests_| | > |1|test_sjk|CASSANDRA-18343| > | |_Java Ditributed Tests_| | > |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all > tests, > org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, > org.apache.cassandra.distributed.test.IPMembershipTest - both tests, > org.apache.cassandra.distributed.test.MixedModeFuzzTest, > org.apache.cassandra.distributed.test.ReprepareFuzzTest, > org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| > |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest > - all tests > org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all > tests|Could be related to CASSANDRA-18180, to be checked | > |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - > 2 tests|CASSANDRA-18180| > | |_Unit Tests_| | > |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| > |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| > |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest, > org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329| > |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest, > org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190| > | | | | > | | | | > -- This message was sent by Atlassian Jira (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-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707934#comment-17707934 ] Benjamin Lerer edited comment on CASSANDRA-16895 at 4/3/23 11:44 AM: - I am not sure what development you are talking about as from the C* development point of view you need to be compatible with the lowest JDK supported by C* to provide a patch. If people want to introduce support for other version I am totally fine with it but I believe that it need to be done properly. Which was not the case for Java 11 for example. was (Author: blerer): I am not sure what development you are talking about as from a development point of view you need to be compatible with the lowest JDK supported by C* to provide a patch. If people want to introduce support for other version I am totally fine with it but I believe that it need to be done properly. Which was not the case for Java 11 for example. > Build with Java 17 > -- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Epic > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > This ticket is intended to group all issues found to support Java 17 in the > future. > Upgrade steps: > * [Dependencies > |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to > be updated (not all but at least those that require an update in order to > work with Java 17) > * More encapsulated JDK internal APIs. Some of the issues might be solved > with the dependencies updates > * Currently trunk compiles if we remove the Nashorn dependency (ant script > tag, used for the test environment; UDFs) . The oracle recommendation to use > Nashorn-core won't work for the project as it is under GPL 2.0. Most probably > we will opt in for graal-sdk licensed under UPL > * All tests to be cleaned > * CI environment to be setup > *NOTE:* GC tuning, performance testing were never agreed to be part of this > ticket. > Below is a snapshot of current CI failures with JDK17, it will be updated on > a regular basis with a date of update > *March 19th 2023* > || ||Failing Test Classes||Ticket Numbers|| > | |_Python DTests_| | > |1|test_sjk|CASSANDRA-18343| > | |_Java Ditributed Tests_| | > |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all > tests, > org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, > org.apache.cassandra.distributed.test.IPMembershipTest - both tests, > org.apache.cassandra.distributed.test.MixedModeFuzzTest, > org.apache.cassandra.distributed.test.ReprepareFuzzTest, > org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| > |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest > - all tests > org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all > tests|Could be related to CASSANDRA-18180, to be checked | > |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - > 2 tests|CASSANDRA-18180| > | |_Unit Tests_| | > |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| > |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| > |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest, > org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329| > |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest, > org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190| > | | | | > | | | | > -- This message was sent by Atlassian Jira (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-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707934#comment-17707934 ] Benjamin Lerer commented on CASSANDRA-16895: I am not sure what development you are talking about as from a development point of view you need to be compatible with the lowest JDK supported by C* to provide a patch. If people want to introduce support for other version I am totally fine with it but I believe that it need to be done properly. Which was not the case for Java 11 for example. > Build with Java 17 > -- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Epic > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > This ticket is intended to group all issues found to support Java 17 in the > future. > Upgrade steps: > * [Dependencies > |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to > be updated (not all but at least those that require an update in order to > work with Java 17) > * More encapsulated JDK internal APIs. Some of the issues might be solved > with the dependencies updates > * Currently trunk compiles if we remove the Nashorn dependency (ant script > tag, used for the test environment; UDFs) . The oracle recommendation to use > Nashorn-core won't work for the project as it is under GPL 2.0. Most probably > we will opt in for graal-sdk licensed under UPL > * All tests to be cleaned > * CI environment to be setup > *NOTE:* GC tuning, performance testing were never agreed to be part of this > ticket. > Below is a snapshot of current CI failures with JDK17, it will be updated on > a regular basis with a date of update > *March 19th 2023* > || ||Failing Test Classes||Ticket Numbers|| > | |_Python DTests_| | > |1|test_sjk|CASSANDRA-18343| > | |_Java Ditributed Tests_| | > |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all > tests, > org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, > org.apache.cassandra.distributed.test.IPMembershipTest - both tests, > org.apache.cassandra.distributed.test.MixedModeFuzzTest, > org.apache.cassandra.distributed.test.ReprepareFuzzTest, > org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| > |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest > - all tests > org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all > tests|Could be related to CASSANDRA-18180, to be checked | > |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - > 2 tests|CASSANDRA-18180| > | |_Unit Tests_| | > |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| > |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| > |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest, > org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329| > |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest, > org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190| > | | | | > | | | | > -- This message was sent by Atlassian Jira (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-16895) Build with Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707210#comment-17707210
]
Benjamin Lerer commented on CASSANDRA-16895:
{quote}so long as relatively costless{quote}
Let's be fully honest here. It is costly. I have been working on Jamm for the
last 4 months to get a correct support up to Java 17 and it is only a tiny bit
of the puzzle. Once we reach full support for 17, we can decide how we want to
progress on other versions but it is not a tiny work to officially support
another release and build + green CI is probably not enough in my opinion. Jamm
will simply return you the wrong results and other projects might do the same.
I agree that we must do it but if we do it, it should be done properly and not
how it was done for Java 11.
> Build with Java 17
> --
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Epic
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> This ticket is intended to group all issues found to support Java 17 in the
> future.
> Upgrade steps:
> * [Dependencies
> |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to
> be updated (not all but at least those that require an update in order to
> work with Java 17)
> * More encapsulated JDK internal APIs. Some of the issues might be solved
> with the dependencies updates
> * Currently trunk compiles if we remove the Nashorn dependency (ant script
> tag, used for the test environment; UDFs) . The oracle recommendation to use
> Nashorn-core won't work for the project as it is under GPL 2.0. Most probably
> we will opt in for graal-sdk licensed under UPL
> * All tests to be cleaned
> * CI environment to be setup
> *NOTE:* GC tuning, performance testing were never agreed to be part of this
> ticket.
> Below is a snapshot of current CI failures with JDK17, it will be updated on
> a regular basis with a date of update
> *March 19th 2023*
> || ||Failing Test Classes||Ticket Numbers||
> | |_Python DTests_| |
> |1|test_sjk|CASSANDRA-18343|
> | |_Java Ditributed Tests_| |
> |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all
> tests,
> org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests,
> org.apache.cassandra.distributed.test.IPMembershipTest - both tests,
> org.apache.cassandra.distributed.test.MixedModeFuzzTest,
> org.apache.cassandra.distributed.test.ReprepareFuzzTest,
> org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304|
> |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> - all tests
> org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all
> tests|Could be related to CASSANDRA-18180, to be checked |
> |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest -
> 2 tests|CASSANDRA-18180|
> | |_Unit Tests_| |
> |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884|
> |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992|
> |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest,
> org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329|
> |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest,
> org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190|
> | | | |
> | | | |
>
--
This message was sent by Atlassian Jira
(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-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17706798#comment-17706798 ] Benjamin Lerer commented on CASSANDRA-16895: [~slachiewicz] Thanks for the information. The plan is to target only LTS versions. We do not have the capacity to target other versions. Simply looking at the build for one Java version is not enough. We need to upgrade all our CI environment, dependencies, ... It is a significant work which is why this epic is taking so long. :-) > Build with Java 17 > -- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Epic > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > This ticket is intended to group all issues found to support Java 17 in the > future. > Upgrade steps: > * [Dependencies > |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to > be updated (not all but at least those that require an update in order to > work with Java 17) > * More encapsulated JDK internal APIs. Some of the issues might be solved > with the dependencies updates > * Currently trunk compiles if we remove the Nashorn dependency (ant script > tag, used for the test environment; UDFs) . The oracle recommendation to use > Nashorn-core won't work for the project as it is under GPL 2.0. Most probably > we will opt in for graal-sdk licensed under UPL > * All tests to be cleaned > * CI environment to be setup > *NOTE:* GC tuning, performance testing were never agreed to be part of this > ticket. > Below is a snapshot of current CI failures with JDK17, it will be updated on > a regular basis with a date of update > *March 19th 2023* > || ||Failing Test Classes||Ticket Numbers|| > | |_Python DTests_| | > |1|test_sjk|CASSANDRA-18343| > | |_Java Ditributed Tests_| | > |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all > tests, > org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, > org.apache.cassandra.distributed.test.IPMembershipTest - both tests, > org.apache.cassandra.distributed.test.MixedModeFuzzTest, > org.apache.cassandra.distributed.test.ReprepareFuzzTest, > org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| > |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest > - all tests > org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all > tests|Could be related to CASSANDRA-18180, to be checked | > |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - > 2 tests|CASSANDRA-18180| > | |_Unit Tests_| | > |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| > |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| > |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest, > org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329| > |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest, > org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190| > | | | | > | | | | > -- This message was sent by Atlassian Jira (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-16895) Build with Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704571#comment-17704571
]
Benjamin Lerer commented on CASSANDRA-16895:
{quote}Anyway, we should perhaps simply bring JAMM's functionality in-tree.
There's no reason to keep it in a separate tree that is presently
unmaintained.{quote}
There are other people using it outside of C* and I believe that there will be
more once we have finished fixing it.
> Build with Java 17
> --
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Epic
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> This ticket is intended to group all issues found to support Java 17 in the
> future.
> Upgrade steps:
> * [Dependencies
> |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to
> be updated (not all but at least those that require an update in order to
> work with Java 17)
> * More encapsulated JDK internal APIs. Some of the issues might be solved
> with the dependencies updates
> * Currently trunk compiles if we remove the Nashorn dependency (ant script
> tag, used for the test environment; UDFs) . The oracle recommendation to use
> Nashorn-core won't work for the project as it is under GPL 2.0. Most probably
> we will opt in for graal-sdk licensed under UPL
> * All tests to be cleaned
> * CI environment to be setup
> *NOTE:* GC tuning, performance testing were never agreed to be part of this
> ticket.
> Below is a snapshot of current CI failures with JDK17, it will be updated on
> a regular basis with a date of update
> *March 19th 2023*
> || ||Failing Test Classes||Ticket Numbers||
> | |_Python DTests_| |
> |1|test_sjk|CASSANDRA-18343|
> | |_Java Ditributed Tests_| |
> |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all
> tests,
> org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests,
> org.apache.cassandra.distributed.test.IPMembershipTest - both tests,
> org.apache.cassandra.distributed.test.MixedModeFuzzTest,
> org.apache.cassandra.distributed.test.ReprepareFuzzTest,
> org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304|
> |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> - all tests
> org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all
> tests|Could be related to CASSANDRA-18180, to be checked |
> |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest -
> 2 tests|CASSANDRA-18180|
> | |_Unit Tests_| |
> |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884|
> |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992|
> |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest,
> org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329|
> |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest,
> org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190|
> | | | |
> | | | |
>
--
This message was sent by Atlassian Jira
(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-18125) Improve memtable allocator accounting when updating AtomicBTreePartition
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697428#comment-17697428
]
Benjamin Lerer commented on CASSANDRA-18125:
The patches looks good to me. Thanks [~jonmeredith], [~benedict].
> Improve memtable allocator accounting when updating AtomicBTreePartition
>
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Nicolas Henneaux
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18125) Improve memtable allocator accounting when updating AtomicBTreePartition
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18125:
---
Status: Ready to Commit (was: Review In Progress)
> Improve memtable allocator accounting when updating AtomicBTreePartition
>
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Nicolas Henneaux
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18125) Improve memtable allocator accounting when updating AtomicBTreePartition
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18125:
---
Reviewers: Benjamin Lerer, Jon Meredith, Benjamin Lerer (was: Benjamin
Lerer, Jon Meredith)
Benjamin Lerer, Jon Meredith, Benjamin Lerer (was: Benjamin
Lerer, Jon Meredith)
Status: Review In Progress (was: Patch Available)
> Improve memtable allocator accounting when updating AtomicBTreePartition
>
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Nicolas Henneaux
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {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-18125) AssertionError on thread MemtableReclaimMemory in MemtablePool$SubPool.released(MemtablePool.java:193)
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17692025#comment-17692025
]
Benjamin Lerer commented on CASSANDRA-18125:
[~benedict] Do you have some tests that reproduce the problem that can be added
to the patch?
> AssertionError on thread MemtableReclaimMemory in
> MemtablePool$SubPool.released(MemtablePool.java:193)
> --
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Nicolas Henneaux
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {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-14227) Extend maximum expiration date
[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17691603#comment-17691603
]
Benjamin Lerer commented on CASSANDRA-14227:
I think, that I am misunderstanding what we call downgradability. What you
propose is some kind of feature flag that delay the problem, no? If a problem
occurs once we switch to the new sstable format then we cannot downgrade
anymore.
> Extend maximum expiration date
> --
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Paulo Motta (Deprecated)
>Assignee: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.x
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png, unnamed-1.png
>
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
This message was sent by Atlassian Jira
(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-14227) Extend maximum expiration date
[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17691217#comment-17691217
]
Benjamin Lerer commented on CASSANDRA-14227:
{quote} It looks like we have an option to CAP to 2038, and if we default to
this on upgrade I think a downgrade should be smooth.{quote}
[~benedict] Could you elaborate a bit what you mean? I am not sure that I am
understanding what you have in mind.
> Extend maximum expiration date
> --
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Paulo Motta (Deprecated)
>Assignee: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.x
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png, unnamed-1.png
>
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
This message was sent by Atlassian Jira
(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-18068) Allow to attach native masking functions to table columns
[
https://issues.apache.org/jira/browse/CASSANDRA-18068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17691102#comment-17691102
]
Benjamin Lerer commented on CASSANDRA-18068:
[~adelapena] I am not entirely convinced about the static change. `STATIC` is a
critical piece of information much more important than the masking one. Putting
it after the mask makes it much less visible.
> Allow to attach native masking functions to table columns
> -
>
> Key: CASSANDRA-18068
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18068
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 8h
> Remaining Estimate: 0h
>
> Allow to attach the native masking functions added by CASSANDRA-17941 to
> table columns, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> {{CREATE TABLE}} statements would look like:
> {code}
> > CREATE TABLE patients (
> id timeuuid PRIMARY KEY,
> name text MASKED WITH partial(2, 1),
> birth date MASKED WITH default()
> );
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21);
>
> > SELECT name, birth FROM patients;
>
> name| birth
> -+
> ale | 1900-01-01
> {code}
> {{ALTER TABLE}} statements would look like:
> {code}
> > ALTER TABLE patients ALTER name MASKED WITH partial(2, 1);
> > ALTER TABLE patients ALTER name WITHOUT MASK;
> {code}
> It won't be possible to use masked columns in the WHERE and IF clauses of
> SELECT and UPDATE statements.
--
This message was sent by Atlassian Jira
(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-18125) AssertionError on thread MemtableReclaimMemory in MemtablePool$SubPool.released(MemtablePool.java:193)
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17691099#comment-17691099
]
Benjamin Lerer commented on CASSANDRA-18125:
Thanks [~benedict], I will look at it today.
> AssertionError on thread MemtableReclaimMemory in
> MemtablePool$SubPool.released(MemtablePool.java:193)
> --
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Nicolas Henneaux
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {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-15254) Allow UPDATE on settings virtual table to change running configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685170#comment-17685170 ] Benjamin Lerer commented on CASSANDRA-15254: [~mmuzaf] Thanks for your explanation. The listener approach can effectively address the problem I had in mind in a nice way. I am confused by the ticket status is the PR ready or is it still some work in progress. Can I look at it at this point or should I wait? > Allow UPDATE on settings virtual table to change running configurations > --- > > Key: CASSANDRA-15254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15254 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Chris Lohfink >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: Configuration Registry Diagram.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Allow using UPDATE on the system_views.settings virtual table to update > configs at runtime for the equivalent of the dispersed JMX > attributes/operations. -- This message was sent by Atlassian Jira (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-15254) Allow UPDATE on settings virtual table to change running configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684536#comment-17684536 ] Benjamin Lerer commented on CASSANDRA-15254: Just to make sure that we have all the same understanding. The plan is only to allow setting the properties that can be set dynamically today (which is a small sub-set of the properties), right? I have not checked but it might be possible that some setter or getters are actually not used by JMX. [~mmuzaf] Your schema mention Auto-Generated classes which is a good idea. I am simply not sure that it is feasible in practice as setting the property is also often only a minor part of the logic involved in changing a configuration. Configuration are often use at start up to initialize some C* components and in case of configuration update that component somehow need to be modified in a non generic way. Up to now that logic was performed in the different JMX implementation classes. Each of them was usually setting the config parameter and then updating the impacted component that they were managing. > Allow UPDATE on settings virtual table to change running configurations > --- > > Key: CASSANDRA-15254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15254 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Chris Lohfink >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: Configuration Registry Diagram.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Allow using UPDATE on the system_views.settings virtual table to update > configs at runtime for the equivalent of the dispersed JMX > attributes/operations. -- This message was sent by Atlassian Jira (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-15254) Allow UPDATE on settings virtual table to change running configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15254: --- Reviewers: Benjamin Lerer, David Capwell (was: David Capwell) > Allow UPDATE on settings virtual table to change running configurations > --- > > Key: CASSANDRA-15254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15254 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Chris Lohfink >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: Configuration Registry Diagram.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Allow using UPDATE on the system_views.settings virtual table to update > configs at runtime for the equivalent of the dispersed JMX > attributes/operations. -- This message was sent by Atlassian Jira (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-18068) Allow to attach native masking functions to table columns
[
https://issues.apache.org/jira/browse/CASSANDRA-18068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-18068:
---
Reviewers: Benjamin Lerer
Status: Review In Progress (was: Patch Available)
> Allow to attach native masking functions to table columns
> -
>
> Key: CASSANDRA-18068
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18068
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Allow to attach the native masking functions added by CASSANDRA-17941 to
> table columns, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> {{CREATE TABLE}} statements would look like:
> {code}
> > CREATE TABLE patients (
> id timeuuid PRIMARY KEY,
> name text MASKED WITH partial(2, 1),
> birth date MASKED WITH default()
> );
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21);
>
> > SELECT name, birth FROM patients;
>
> name| birth
> -+
> ale | 1900-01-01
> {code}
> {{ALTER TABLE}} statements would look like:
> {code}
> > ALTER TABLE patients ALTER name MASKED WITH partial(2, 1);
> > ALTER TABLE patients ALTER name WITHOUT MASK;
> {code}
> It won't be possible to use masked columns in the WHERE and IF clauses of
> SELECT and UPDATE statements.
--
This message was sent by Atlassian Jira
(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-18219) Warning message on aggregation queries doesn't specify table name or aggregate type
[
https://issues.apache.org/jira/browse/CASSANDRA-18219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683334#comment-17683334
]
Benjamin Lerer commented on CASSANDRA-18219:
The idea behind the warn is to send the warning back to the client performing
the query. Of course they can choose to ignore it which is why we also log the
message to the logs.
Adding the table name make total sense from the log point of view.
[~bschoeni] I imagine that if you want to find the problematic query your
intention is to ask the user to stop running that query. Would it not make
sense at this point to had some Guardrails to block those queries rather than
introducing more logging?
> Warning message on aggregation queries doesn't specify table name or
> aggregate type
> ---
>
> Key: CASSANDRA-18219
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18219
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brad Schoening
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The existing aggregation query warning messages in cassandra.log from
> SelectStatement.java:
> _'[WARN] Aggregation query used without partition key'_
> {_}'{_}{_}[WARN]{_} _Aggregation query used on multiple partition keys
> (IN restriction)'_
> are missing the helpful details which would assist users in quickly
> identifying the offending query. The table name and type of aggregation would
> be useful additions in the WARN message.
> In addition, following the example of the slow query logger and printing out
> the query string at DEBUG level would be especially helpful.
--
This message was sent by Atlassian Jira
(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-17941) CQL data masking functions
[ https://issues.apache.org/jira/browse/CASSANDRA-17941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681252#comment-17681252 ] Benjamin Lerer commented on CASSANDRA-17941: The patch looks good to me. Thanks [~adelapena] > CQL data masking functions > -- > > Key: CASSANDRA-17941 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17941 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > Add native CQL functions to mask the contents of a column, as described in > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. -- This message was sent by Atlassian Jira (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-17941) CQL data masking functions
[ https://issues.apache.org/jira/browse/CASSANDRA-17941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-17941: --- Status: Ready to Commit (was: Review In Progress) > CQL data masking functions > -- > > Key: CASSANDRA-17941 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17941 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > Add native CQL functions to mask the contents of a column, as described in > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. -- This message was sent by Atlassian Jira (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-15254) Allow UPDATE on settings virtual table to change running configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654970#comment-17654970 ] Benjamin Lerer commented on CASSANDRA-15254: [~mmuzaf] Happy new year to you too. I have to focus on other stuff before I can come back to this ticket and I would probably not be able to touch it before several months. If you want to have a try at it, feel free to assign the ticket to you :-) > Allow UPDATE on settings virtual table to change running configurations > --- > > Key: CASSANDRA-15254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15254 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Chris Lohfink >Assignee: Benjamin Lerer >Priority: Normal > > Allow using UPDATE on the system_views.settings virtual table to update > configs at runtime for the equivalent of the dispersed JMX > attributes/operations. -- This message was sent by Atlassian Jira (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-17941) CQL data masking functions
[ https://issues.apache.org/jira/browse/CASSANDRA-17941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-17941: --- Status: Review In Progress (was: Patch Available) > CQL data masking functions > -- > > Key: CASSANDRA-17941 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17941 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.x > > > Add native CQL functions to mask the contents of a column, as described in > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. -- This message was sent by Atlassian Jira (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-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644253#comment-17644253
]
Benjamin Lerer commented on CASSANDRA-17918:
Thanks [~bernardo.botella]. The patch looks good to me.
[~yifanc] were the new tests checked for flakiness?
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> SchemaElement.toCqlString}}
--
This message was sent by Atlassian Jira
(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-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17221:
---
Source Control Link:
https://github.com/apache/cassandra/commit/88dc64d2086c9a91f00ee024b8ef13cb2c193ee6
(was: https://github.com/apache/cassandra/commits/trunk)
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.2
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(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-17884) Test failure: o.a.c.repair.RepairJobTest.testNoTreesRetainedAfterDifference
[
https://issues.apache.org/jira/browse/CASSANDRA-17884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17884:
---
Epic Link: CASSANDRA-16895
> Test failure: o.a.c.repair.RepairJobTest.testNoTreesRetainedAfterDifference
> ---
>
> Key: CASSANDRA-17884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17884
> Project: Cassandra
> Issue Type: Bug
> Components: Jamm, Test/unit
>Reporter: Andres de la Peña
>Assignee: shylaja kokoori
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> The unit test
> {{org.apache.cassandra.repair.RepairJobTest#testNoTreesRetainedAfterDifference}}
> seems to be slightly flaky at least in 4.0. We haven't seen it failing on
> Butler, but after [a failure on a patch
> branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/281/workflows/e6094c00-b611-4772-9772-205f4c76ecba/jobs/2126/tests],
> this repeated run shows a 0.28% flakiness:
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2076/workflows/8adbfe99-afb5-43af-84ad-43df2a2a86e2/jobs/20816/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2076/workflows/e550d8c2-7c35-4326-bd95-6909978d344b/jobs/20817/tests
> {code}
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> jdk.internal.platform.cgroupv1.SubSystem$MemorySubSystem
> jdk.internal.platform.cgroupv1.Metrics.memory accessible: module java.base
> does not "opens jdk.internal.platform.cgroupv1" to unnamed module @157853da
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> at
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:176)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:170)
> at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:330)
> at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:269)
> at
> org.apache.cassandra.utils.ObjectSizes.measureDeep(ObjectSizes.java:216)
> at
> org.apache.cassandra.repair.RepairJobTest.testNoTreesRetainedAfterDifference(RepairJobTest.java:271)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Flakiness is really low but the failure is clearly reproducible in j11.
--
This message was sent by Atlassian Jira
(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-17884) Test failure: o.a.c.repair.RepairJobTest.testNoTreesRetainedAfterDifference
[
https://issues.apache.org/jira/browse/CASSANDRA-17884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17884:
---
Component/s: Jamm
> Test failure: o.a.c.repair.RepairJobTest.testNoTreesRetainedAfterDifference
> ---
>
> Key: CASSANDRA-17884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17884
> Project: Cassandra
> Issue Type: Bug
> Components: Jamm, Test/unit
>Reporter: Andres de la Peña
>Assignee: shylaja kokoori
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> The unit test
> {{org.apache.cassandra.repair.RepairJobTest#testNoTreesRetainedAfterDifference}}
> seems to be slightly flaky at least in 4.0. We haven't seen it failing on
> Butler, but after [a failure on a patch
> branch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/281/workflows/e6094c00-b611-4772-9772-205f4c76ecba/jobs/2126/tests],
> this repeated run shows a 0.28% flakiness:
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2076/workflows/8adbfe99-afb5-43af-84ad-43df2a2a86e2/jobs/20816/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2076/workflows/e550d8c2-7c35-4326-bd95-6909978d344b/jobs/20817/tests
> {code}
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> jdk.internal.platform.cgroupv1.SubSystem$MemorySubSystem
> jdk.internal.platform.cgroupv1.Metrics.memory accessible: module java.base
> does not "opens jdk.internal.platform.cgroupv1" to unnamed module @157853da
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> at
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:176)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:170)
> at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:330)
> at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:269)
> at
> org.apache.cassandra.utils.ObjectSizes.measureDeep(ObjectSizes.java:216)
> at
> org.apache.cassandra.repair.RepairJobTest.testNoTreesRetainedAfterDifference(RepairJobTest.java:271)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Flakiness is really low but the failure is clearly reproducible in j11.
--
This message was sent by Atlassian Jira
(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-16501) CMS is deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-16501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16501:
---
Epic Link: CASSANDRA-16895
> CMS is deprecated
> -
>
> Key: CASSANDRA-16501
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16501
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> When running under Java 11, you will see:
> {quote}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> {quote}
> Per the JEP: http://openjdk.java.net/jeps/291 " The G1 garbage collector is
> intended, in the long term, to be a replacement for most uses of CMS."
> We don't need to act on this immediately at the time of writing this ticket,
> but it is something that will eventually happen so we should get ahead of it.
--
This message was sent by Atlassian Jira
(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-17992) Upgrade Netty on 4.x(current trunk)
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-17992: --- Epic Link: CASSANDRA-16895 > Upgrade Netty on 4.x(current trunk) > --- > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > Fix For: 4.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (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-17951) Update AssertJ
[ https://issues.apache.org/jira/browse/CASSANDRA-17951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-17951: --- Epic Link: CASSANDRA-16895 > Update AssertJ > -- > > Key: CASSANDRA-17951 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17951 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > From the changelog of AssertJ > [here|https://assertj.github.io/doc/#assertj-core-3-23-1-release-notes] it > seems JDK17 is tested and relevant issues fixed as per 3.23.1 and we are on > 3.15.0 > This ticket should accommodate upgrade to 3.23.1 for trunk > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
