[jira] [Updated] (CASSANDRA-18339) Cassandra 3.11.2 windows remote share as data files directory
[ https://issues.apache.org/jira/browse/CASSANDRA-18339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Navya Krishna Dubbala updated CASSANDRA-18339: -- Resolution: (was: Won't Fix) Status: Open (was: Resolved) Hi Team, We have blocker with this, Could you please provide more information to confirm it won't support. > Cassandra 3.11.2 windows remote share as data files directory > -- > > Key: CASSANDRA-18339 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18339 > Project: Cassandra > Issue Type: Bug >Reporter: Navya Krishna Dubbala >Priority: Urgent > > Hi Team, > > We are using windows 2018 server for running Cassandra 3.11.2 version with > remote windows server shared folder as data file directory path and we are > getting below error. > > ERROR [CompactionExecutor:1] 2023-03-10 09:18:44,511 > DefaultFSErrorHandler.java:92 - Exiting forcefully due to file system > exception on startup, disk failure policy "stop" > org.apache.cassandra.io.FSReadError: java.io.IOException: There are no more > files at > org.apache.cassandra.io.util.FileUtils.getCanonicalPath(FileUtils.java:303) > It is working inbetween. > -- This message was sent by Atlassian Jira (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-18339) Cassandra 3.11.2 windows remote share as data files directory
[ https://issues.apache.org/jira/browse/CASSANDRA-18339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Navya Krishna Dubbala updated CASSANDRA-18339: -- Severity: Critical > Cassandra 3.11.2 windows remote share as data files directory > -- > > Key: CASSANDRA-18339 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18339 > Project: Cassandra > Issue Type: Bug >Reporter: Navya Krishna Dubbala >Priority: Urgent > > Hi Team, > > We are using windows 2018 server for running Cassandra 3.11.2 version with > remote windows server shared folder as data file directory path and we are > getting below error. > > ERROR [CompactionExecutor:1] 2023-03-10 09:18:44,511 > DefaultFSErrorHandler.java:92 - Exiting forcefully due to file system > exception on startup, disk failure policy "stop" > org.apache.cassandra.io.FSReadError: java.io.IOException: There are no more > files at > org.apache.cassandra.io.util.FileUtils.getCanonicalPath(FileUtils.java:303) > It is working inbetween. > -- This message was sent by Atlassian Jira (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-18339) Cassandra 3.11.2 windows remote share as data files directory
[ https://issues.apache.org/jira/browse/CASSANDRA-18339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701473#comment-17701473 ] Navya Krishna Dubbala commented on CASSANDRA-18339: --- Sometimes we see below memtable flush error. ERROR [MemtablePostFlush:1] 2023-03-13 12:05:11,029 DefaultFSErrorHandler.java:92 - Exiting forcefully due to file system exception on startup, disk failure policy "stop" org.apache.cassandra.io.FSReadError: java.io.IOException: There are no more files > Cassandra 3.11.2 windows remote share as data files directory > -- > > Key: CASSANDRA-18339 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18339 > Project: Cassandra > Issue Type: Bug >Reporter: Navya Krishna Dubbala >Priority: Normal > > Hi Team, > > We are using windows 2018 server for running Cassandra 3.11.2 version with > remote windows server shared folder as data file directory path and we are > getting below error. > > ERROR [CompactionExecutor:1] 2023-03-10 09:18:44,511 > DefaultFSErrorHandler.java:92 - Exiting forcefully due to file system > exception on startup, disk failure policy "stop" > org.apache.cassandra.io.FSReadError: java.io.IOException: There are no more > files at > org.apache.cassandra.io.util.FileUtils.getCanonicalPath(FileUtils.java:303) > It is working inbetween. > -- This message was sent by Atlassian Jira (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-18339) Cassandra 3.11.2 windows remote share as data files directory
[ https://issues.apache.org/jira/browse/CASSANDRA-18339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701472#comment-17701472 ] Navya Krishna Dubbala commented on CASSANDRA-18339: --- Is windows shared folder as data file directory supported in any version of Cassandra or this not supported at all. It is working for sometimes. If we reinstall Cassandra on same machine or restarting service is giving below errors. ERROR [CompactionExecutor:1] 2023-03-10 09:18:44,511 DefaultFSErrorHandler.java:92 - Exiting forcefully due to file system exception on startup, disk failure policy "stop" org.apache.cassandra.io.FSReadError: java.io.IOException: There are no more files at org.apache.cassandra.io.util.FileUtils.getCanonicalPath(FileUtils.java:303) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.lifecycle.LogRecord.absolutePath(LogRecord.java:185) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.lifecycle.LogRecord.make(LogRecord.java:159) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.lifecycle.LogFile.makeRecord(LogFile.java:316) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.lifecycle.LogFile.contains(LogFile.java:340) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.lifecycle.LogTransaction.obsoleted(LogTransaction.java:152) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.lifecycle.Helpers.prepareForObsoletion(Helpers.java:134) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.lifecycle.LifecycleTransaction.doPrepare(LifecycleTransaction.java:200) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:392) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:112) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:122) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:220) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61) ~[apache-cassandra-3.11.2.jar:3.11.2] at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:275) ~[apache-cassandra-3.11.2.jar:3.11.2] at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[na:1.8.0_171] at java.util.concurrent.FutureTask.run(Unknown Source) ~[na:1.8.0_171] at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[na:1.8.0_171] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[na:1.8.0_171] at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81) ~[apache-cassandra-3.11.2.jar:3.11.2] at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_171] Caused by: java.io.IOException: There are no more files at java.io.WinNTFileSystem.canonicalizeWithPrefix0(Native Method) ~[na:1.8.0_171] at java.io.WinNTFileSystem.canonicalizeWithPrefix(Unknown Source) ~[na:1.8.0_171] at java.io.WinNTFileSystem.canonicalize(Unknown Source) ~[na:1.8.0_171] at java.io.File.getCanonicalPath(Unknown Source) ~[na:1.8.0_171] at org.apache.cassandra.io.util.FileUtils.getCanonicalPath(FileUtils.java:299) ~[apache-cassandra-3.11.2.jar:3.11.2] ... 25 common frames omitted > Cassandra 3.11.2 windows remote share as data files directory > -- > > Key: CASSANDRA-18339 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18339 > Project: Cassandra > Issue Type: Bug >Reporter: Navya Krishna Dubbala >Priority: Normal > > Hi Team, > > We are using windows 2018 server for running Cassandra 3.11.2 version with >
[jira] [Commented] (CASSANDRA-18336) Sstables were cleared when restarting
[
https://issues.apache.org/jira/browse/CASSANDRA-18336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701453#comment-17701453
]
NAIZHEN QUE commented on CASSANDRA-18336:
-
The version is 4.0.3 . All the data (sstables )on the node were deleted!
> Sstables were cleared when restarting
> -
>
> Key: CASSANDRA-18336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18336
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: NAIZHEN QUE
>Priority: Normal
> Attachments: system.log.2023-02-21.0
>
>
> 1.When this exception occurs in the system
> {code:java}
> //
> ERROR [CompactionExecutor:351627] 2023-02-21 17:59:20,721
> CassandraDaemon.java:581 - Exception in thread
> Thread[CompactionExecutor:351627,1,main]
> org.apache.cassandra.io.FSReadError: java.io.IOException: Map failed
> at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:167)
> at
> org.apache.cassandra.io.util.MmappedRegions$State.add(MmappedRegions.java:310)
> at
> org.apache.cassandra.io.util.MmappedRegions$State.access$400(MmappedRegions.java:246)
> at
> org.apache.cassandra.io.util.MmappedRegions.updateState(MmappedRegions.java:170)
> at
> org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:73)
> at
> org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:61)
> at
> org.apache.cassandra.io.util.MmappedRegions.map(MmappedRegions.java:104)
> at
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:365)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openEarly(BigTableWriter.java:337)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.maybeReopenEarly(SSTableRewriter.java:172)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:124)
> at
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:64)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:137)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:193)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:77)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:298)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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:834)
> Caused by: java.io.IOException: Map failed
> at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1016)
> at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:163)
> ... 23 common frames omitted
> Caused by: java.lang.OutOfMemoryError: Map failed
> at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method)
> at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1013)
> {code}
> 2.Restart the node, Verifying logfile transaction ,All sstables are deleted
> {code:java}
> // code placeholder
> INFO [main] 2023-02-21 18:00:23,350 LogTransaction.java:240 - Unfinished
> transaction log, deleting
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8819408-big-Index.db
>
> INFO [main] 2023-02-21 18:00:23,615 LogTransaction.java:240 - Unfinished
> transaction log, deleting
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8819408-big-Data.db
>
> INFO [main] 2023-02-21 18:00:46,504 LogTransaction.java:240 - Unfinished
> transaction log, deleting
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb_txn_compaction_c923b230-b077-11ed-a081-5d5a5c990823.log
>
> INFO [main] 2023-02-21 18:00:46,510 LogTransaction.java:536 - Verifying
> logfile transaction
> [nb_txn_compaction_461935b0-b1ce-11ed-a081-5d5a5c990823.log in
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b]
> INFO [main] 2023-02-21 18:00:46,517 LogTransaction.java:240 - Unfinished
> transaction log, deleting
>
[jira] [Commented] (CASSANDRA-17092) CEP-15: Accord Beta
[
https://issues.apache.org/jira/browse/CASSANDRA-17092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701426#comment-17701426
]
Caleb Rackliffe commented on CASSANDRA-17092:
-
Posted a dry-run of the {{cep-15-accord}} / {{cep-21-tcm}} rebase here:
https://github.com/apache/cassandra/pull/2227
> CEP-15: Accord Beta
> ---
>
> Key: CASSANDRA-17092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17092
> Project: Cassandra
> Issue Type: Epic
> Components: Accord
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>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] [Commented] (CASSANDRA-18049) Update Chronicle Queue
[
https://issues.apache.org/jira/browse/CASSANDRA-18049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701413#comment-17701413
]
Michael Semb Wever commented on CASSANDRA-18049:
https://github.com/apache/cassandra/pull/2226
> Update Chronicle Queue
> --
>
> Key: CASSANDRA-18049
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18049
> Project: Cassandra
> Issue Type: Task
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> According to [this|https://chronicle.software/chronicle-support-java-17]
> article:
> {code:java}
> Starting from chronicle-bom-2.22ea26, all new releases can be run under Java
> 17 when run on the class path (but not yet under the module path).{code}
> This BOM is newer than what we currently have in both 4.1 and trunk. 4.1
> points in comments to
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/1.16.23] which
> I believe was just forgotten to be updated/removed. The versions we see
> correspond to this BOM
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/2.20.226]
> It is still older than chronicle-bom-2.22ea26 so we need to upgrade. I
> suggest we also add a comment again which BOM is considered, this makes
> things easier.
> Further to running CI, review of the CHANGE logs needs to happen to ensure we
> do not miss anything that can impact us and it is not caught by our tests.
> For testing with JDK17, please, contact [~e.dimitrova] for latest branch and
> CI config (at this point feature branch in the cassandra repo does not exist)
>
--
This message was sent by Atlassian Jira
(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-18049) Update Chronicle Queue
[
https://issues.apache.org/jira/browse/CASSANDRA-18049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701303#comment-17701303
]
Michael Semb Wever edited comment on CASSANDRA-18049 at 3/16/23 10:28 PM:
--
Dependency changes (post dev@) are now:
Added (a few of these have been pinned so to specify a more recent version)
* affinity-3.23ea1.jar
* jffi-1.3.11-native.jar
* jffi-1.3.11.jar
* jna-platform-5.13.0.jar
* jnr-a64asm-1.0.0.jar
* jnr-constants-0.10.4.jar
* jnr-ffi-2.2.13.jar
* jnr-x86asm-1.0.2.jar
* posix-2.24ea4.jar
Upgraded
* chronicle-bytes-2.20.111.jar --> chronicle-bytes-2.23.33.jar
* chronicle-core-2.20.126.jar --> chronicle-core-2.23.36.jar
* chronicle-queue-5.20.123.jar --> chronicle-queue-5.23.37.jar
* chronicle-threads-2.20.111.jar --> chronicle-threads-2.23.25.jar
* chronicle-wire-2.20.117.jar --> chronicle-wire-2.23.39.jar
patches:
-
https://github.com/apache/cassandra/compare/trunk...michaelsembwever:cassandra:mck/18049/trunk
-
https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:cassandra-dtest:mck/18049
CI:
- j8+j11:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/130
- j11+j17:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/136 (using
CASSANDRA-18247)
(plenty of 17 failures there, but none seem related to this ticket)
was (Author: michaelsembwever):
Dependency changes (post dev@) are now:
Added (a few of these have been pinned so to specify a more recent version)
* affinity-3.23ea1.jar
* jffi-1.3.11-native.jar
* jffi-1.3.11.jar
* jna-platform-5.13.0.jar
* jnr-a64asm-1.0.0.jar
* jnr-constants-0.10.4.jar
* jnr-ffi-2.2.13.jar
* jnr-x86asm-1.0.2.jar
* posix-2.24ea4.jar
Upgraded
* chronicle-bytes-2.20.111.jar --> chronicle-bytes-2.23.33.jar
* chronicle-core-2.20.126.jar --> chronicle-core-2.23.36.jar
* chronicle-queue-5.20.123.jar --> chronicle-queue-5.23.37.jar
* chronicle-threads-2.20.111.jar --> chronicle-threads-2.23.25.jar
* chronicle-wire-2.20.117.jar --> chronicle-wire-2.23.39.jar
patches:
-
https://github.com/apache/cassandra/compare/trunk...michaelsembwever:cassandra:mck/18049/trunk
-
https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:cassandra-dtest:mck/18049
CI:
- j8+j11:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/130
- j11+j17:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/136 (using
CASSANDRA-18247)
(plenty of 17 failures there, but none seem related to this ticket)
> Update Chronicle Queue
> --
>
> Key: CASSANDRA-18049
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18049
> Project: Cassandra
> Issue Type: Task
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> According to [this|https://chronicle.software/chronicle-support-java-17]
> article:
> {code:java}
> Starting from chronicle-bom-2.22ea26, all new releases can be run under Java
> 17 when run on the class path (but not yet under the module path).{code}
> This BOM is newer than what we currently have in both 4.1 and trunk. 4.1
> points in comments to
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/1.16.23] which
> I believe was just forgotten to be updated/removed. The versions we see
> correspond to this BOM
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/2.20.226]
> It is still older than chronicle-bom-2.22ea26 so we need to upgrade. I
> suggest we also add a comment again which BOM is considered, this makes
> things easier.
> Further to running CI, review of the CHANGE logs needs to happen to ensure we
> do not miss anything that can impact us and it is not caught by our tests.
> For testing with JDK17, please, contact [~e.dimitrova] for latest branch and
> CI config (at this point feature branch in the cassandra repo does not exist)
>
--
This message was sent by Atlassian Jira
(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-18049) Update Chronicle Queue
[
https://issues.apache.org/jira/browse/CASSANDRA-18049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701412#comment-17701412
]
Ekaterina Dimitrova commented on CASSANDRA-18049:
-
Can you open a PR where I can leave comments which will not get lost on squash,
please?
> Update Chronicle Queue
> --
>
> Key: CASSANDRA-18049
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18049
> Project: Cassandra
> Issue Type: Task
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> According to [this|https://chronicle.software/chronicle-support-java-17]
> article:
> {code:java}
> Starting from chronicle-bom-2.22ea26, all new releases can be run under Java
> 17 when run on the class path (but not yet under the module path).{code}
> This BOM is newer than what we currently have in both 4.1 and trunk. 4.1
> points in comments to
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/1.16.23] which
> I believe was just forgotten to be updated/removed. The versions we see
> correspond to this BOM
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/2.20.226]
> It is still older than chronicle-bom-2.22ea26 so we need to upgrade. I
> suggest we also add a comment again which BOM is considered, this makes
> things easier.
> Further to running CI, review of the CHANGE logs needs to happen to ensure we
> do not miss anything that can impact us and it is not caught by our tests.
> For testing with JDK17, please, contact [~e.dimitrova] for latest branch and
> CI config (at this point feature branch in the cassandra repo does not exist)
>
--
This message was sent by Atlassian Jira
(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-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701411#comment-17701411
]
David Capwell commented on CASSANDRA-17199:
---
The new tests conflict with existing code, so fails to compile
{code}
_build-test:
[javac] Compiling 1520 source files to
/Users/dcapwell/src/github/apache/cassandra-oss-commit/build/test/classes
[javac] Note: Processing compiler hints annotations
[javac] Note: Processing compiler hints annotations
[javac]
/Users/dcapwell/src/github/apache/cassandra-oss-commit/test/distributed/org/apache/cassandra/distributed/test/streaming/StreamFailureTest.java:44:
error: cannot find symbol
[javac] import
org.apache.cassandra.io.sstable.format.RangeAwareSSTableWriter;
[javac] ^
[javac] symbol: class RangeAwareSSTableWriter
[javac] location: package org.apache.cassandra.io.sstable.format
[javac]
/Users/dcapwell/src/github/apache/cassandra-oss-commit/test/distributed/org/apache/cassandra/distributed/test/streaming/StreamFailureTest.java:45:
error: cannot find symbol
[javac] import
org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter;
[javac] ^
[javac] symbol: class BigTableZeroCopyWriter
[javac] location: package org.apache.cassandra.io.sstable.format.big
[javac] Note: Processing compiler hints annotations
[javac] Note: Writing compiler command file at META-INF/hotspot_compiler
[javac] Note: Done processing compiler hints annotations
[javac] 2 errors
BUILD FAILED
/Users/dcapwell/src/github/apache/cassandra-oss-commit/build.xml:999: The
following error occurred while executing this line:
/Users/dcapwell/src/github/apache/cassandra-oss-commit/build.xml:1012: Compile
failed; see the compiler error output for details.
{code}
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
This message was sent by Atlassian Jira
(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-18339) Cassandra 3.11.2 windows remote share as data files directory
[ https://issues.apache.org/jira/browse/CASSANDRA-18339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701407#comment-17701407 ] Josh McKenzie commented on CASSANDRA-18339: --- I'd take it a step further and say "you really shouldn't try and do this". NTFS is already pretty finicky when it comes to dealing with symlinks and hard links, and adding the complexity of a remote server folder share seems like a recipe for subtle failures. > Cassandra 3.11.2 windows remote share as data files directory > -- > > Key: CASSANDRA-18339 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18339 > Project: Cassandra > Issue Type: Bug >Reporter: Navya Krishna Dubbala >Priority: Normal > > Hi Team, > > We are using windows 2018 server for running Cassandra 3.11.2 version with > remote windows server shared folder as data file directory path and we are > getting below error. > > ERROR [CompactionExecutor:1] 2023-03-10 09:18:44,511 > DefaultFSErrorHandler.java:92 - Exiting forcefully due to file system > exception on startup, disk failure policy "stop" > org.apache.cassandra.io.FSReadError: java.io.IOException: There are no more > files at > org.apache.cassandra.io.util.FileUtils.getCanonicalPath(FileUtils.java:303) > It is working inbetween. > -- This message was sent by Atlassian Jira (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-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17199:
--
Reviewers: David Capwell, Dinesh Joshi, Jon Meredith (was: Jon Meredith)
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
This message was sent by Atlassian Jira
(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-18049) Update Chronicle Queue
[
https://issues.apache.org/jira/browse/CASSANDRA-18049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18049:
Status: Review In Progress (was: Patch Available)
> Update Chronicle Queue
> --
>
> Key: CASSANDRA-18049
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18049
> Project: Cassandra
> Issue Type: Task
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> According to [this|https://chronicle.software/chronicle-support-java-17]
> article:
> {code:java}
> Starting from chronicle-bom-2.22ea26, all new releases can be run under Java
> 17 when run on the class path (but not yet under the module path).{code}
> This BOM is newer than what we currently have in both 4.1 and trunk. 4.1
> points in comments to
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/1.16.23] which
> I believe was just forgotten to be updated/removed. The versions we see
> correspond to this BOM
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/2.20.226]
> It is still older than chronicle-bom-2.22ea26 so we need to upgrade. I
> suggest we also add a comment again which BOM is considered, this makes
> things easier.
> Further to running CI, review of the CHANGE logs needs to happen to ensure we
> do not miss anything that can impact us and it is not caught by our tests.
> For testing with JDK17, please, contact [~e.dimitrova] for latest branch and
> CI config (at this point feature branch in the cassandra repo does not exist)
>
--
This message was sent by Atlassian Jira
(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-18247) Add CircleCI config files for J11+J17
[
https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701400#comment-17701400
]
Ekaterina Dimitrova commented on CASSANDRA-18247:
-
{quote}Indeed, it says it is setting them, but does not actually do so.
{quote}
It does, but in config.yml instead of config_11_and_17.yml, I missed to update
the file name at one place.
That is fixed now plus the following changes were done according to the
feedback provided:
- generate_11_and_17.sh -e, -p, -f flags are applying respective changes to
config.yml and config_11_and_17.yml. config_11_and_17.yml update is made in
order to have a diff where we can verify only CircleCI resource changes. The
other file diff also contains the switch from 8 & 11 to 11 & 17 which makes it
too noisy to be able to verify only resources changes.
- generate_11_and_17.sh -a will change only the *_11_and_17.yml files
I also updated the readme.md file accordingly.
Pushed a new commit to the [PR|https://github.com/apache/cassandra/pull/2223]
I will push again CI when we confirm that this is the final UI
> Add CircleCI config files for J11+J17
> -
>
> Key: CASSANDRA-18247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18247
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Based on the direction of [this
> discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy],
> I would like to propose CircleCI config files which can be used to test
> current trunk with JDK 17 (after I blindly remove the scripted UDFs in
> another ticket, to be opened soon)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (cc9fdd1c4 -> e9f2508eb)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard cc9fdd1c4 generate docs for c4206294 new e9f2508eb generate docs for c4206294 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (cc9fdd1c4) \ N -- N -- N refs/heads/asf-staging (e9f2508eb) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/doc/4.2/cassandra/cql/changes.html | 12 content/doc/4.2/cassandra/cql/cql_singlefile.html | 11 --- content/doc/4.2/cassandra/cql/functions.html | 10 -- content/doc/4.2/cassandra/new/virtualtables.html | 4 ++-- .../doc/4.2/cassandra/operating/virtualtables.html | 4 ++-- content/doc/trunk/cassandra/cql/changes.html | 12 .../doc/trunk/cassandra/cql/cql_singlefile.html| 11 --- content/doc/trunk/cassandra/cql/functions.html | 10 -- content/doc/trunk/cassandra/new/virtualtables.html | 4 ++-- .../trunk/cassandra/operating/virtualtables.html | 4 ++-- content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4796442 -> 4796442 bytes 12 files changed, 33 insertions(+), 51 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17199:
--
Status: Ready to Commit (was: Review In Progress)
3 +1s (me, Dinesh, Jon)
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.0.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
This message was sent by Atlassian Jira
(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-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17199:
--
Fix Version/s: 5.x
(was: 4.0.x)
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
This message was sent by Atlassian Jira
(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-18341) Accord simulator fails with "available partitions are empty!"
[
https://issues.apache.org/jira/browse/CASSANDRA-18341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18341:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 5.x
Severity: Normal
Status: Open (was: Triage Needed)
I think this is LHF but you first need to understand Simulator and Actions, so
made it "normal"
> Accord simulator fails with "available partitions are empty!"
> -
>
> Key: CASSANDRA-18341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18341
> Project: Cassandra
> Issue Type: Bug
> Components: Accord, Test/fuzz
>Reporter: David Capwell
>Priority: Normal
> Fix For: 5.x
>
>
> With the change to allow accord to run with multiple partitions in simulator
> we can hit an edge case where all partitions are used in queries, so the
> current query isn’t able to find a partition to use, causing this error
> {code}
> junit.framework.AssertionFailedError: available partitions are empty!
> at
> org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation.consume(AbstractPairOfSequencesPaxosSimulation.java:252)
> at
> org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation.access$000(AbstractPairOfSequencesPaxosSimulation.java:72)
> at
> org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation$2.get(AbstractPairOfSequencesPaxosSimulation.java:211)
> at
> org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation$2.get(AbstractPairOfSequencesPaxosSimulation.java:207)
> at org.apache.cassandra.simulator.Actions.next(Actions.java:145)
> at
> org.apache.cassandra.simulator.Actions.lambda$streamNextSupplier$3(Actions.java:154)
> at
> org.apache.cassandra.simulator.Actions$LambdaAction.performSimple(Actions.java:63)
> at
> org.apache.cassandra.simulator.Action.performAndRegister(Action.java:468)
> at org.apache.cassandra.simulator.Action.perform(Action.java:486)
> at
> org.apache.cassandra.simulator.ActionSchedule.next(ActionSchedule.java:378)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulation$2.next(PaxosSimulation.java:255)
> at
> org.apache.cassandra.simulator.paxos.PaxosSimulation.run(PaxosSimulation.java:227)
> at
> org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation.run(AbstractPairOfSequencesPaxosSimulation.java:295)
> at
> org.apache.cassandra.simulator.paxos.PairOfSequencesAccordSimulation.run(PairOfSequencesAccordSimulation.java:62)
> at
> org.apache.cassandra.simulator.SimulationRunner$Run.run(SimulationRunner.java:374)
> at
> org.apache.cassandra.simulator.paxos.AccordSimulationRunner$Run.run(AccordSimulationRunner.java:39)
> at
> org.apache.cassandra.simulator.paxos.AccordSimulationRunner$Run.run(AccordSimulationRunner.java:30)
> at
> org.apache.cassandra.simulator.SimulationRunner$BasicCommand.run(SimulationRunner.java:355)
> at
> org.apache.cassandra.simulator.paxos.AccordSimulationRunner.main(AccordSimulationRunner.java:76)
> at
> org.apache.cassandra.simulator.test.ShortAccordSimulationTest.simulationTest(ShortAccordSimulationTest.java:32)
> {code}
> See
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1947/workflows/05ee1183-36a0-41de-a798-e49b4e1ec413/jobs/19052
--
This message was sent by Atlassian Jira
(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-18341) Accord simulator fails with "available partitions are empty!"
David Capwell created CASSANDRA-18341:
-
Summary: Accord simulator fails with "available partitions are
empty!"
Key: CASSANDRA-18341
URL: https://issues.apache.org/jira/browse/CASSANDRA-18341
Project: Cassandra
Issue Type: Bug
Components: Accord, Test/fuzz
Reporter: David Capwell
With the change to allow accord to run with multiple partitions in simulator we
can hit an edge case where all partitions are used in queries, so the current
query isn’t able to find a partition to use, causing this error
{code}
junit.framework.AssertionFailedError: available partitions are empty!
at
org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation.consume(AbstractPairOfSequencesPaxosSimulation.java:252)
at
org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation.access$000(AbstractPairOfSequencesPaxosSimulation.java:72)
at
org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation$2.get(AbstractPairOfSequencesPaxosSimulation.java:211)
at
org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation$2.get(AbstractPairOfSequencesPaxosSimulation.java:207)
at org.apache.cassandra.simulator.Actions.next(Actions.java:145)
at
org.apache.cassandra.simulator.Actions.lambda$streamNextSupplier$3(Actions.java:154)
at
org.apache.cassandra.simulator.Actions$LambdaAction.performSimple(Actions.java:63)
at
org.apache.cassandra.simulator.Action.performAndRegister(Action.java:468)
at org.apache.cassandra.simulator.Action.perform(Action.java:486)
at
org.apache.cassandra.simulator.ActionSchedule.next(ActionSchedule.java:378)
at
org.apache.cassandra.simulator.paxos.PaxosSimulation$2.next(PaxosSimulation.java:255)
at
org.apache.cassandra.simulator.paxos.PaxosSimulation.run(PaxosSimulation.java:227)
at
org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation.run(AbstractPairOfSequencesPaxosSimulation.java:295)
at
org.apache.cassandra.simulator.paxos.PairOfSequencesAccordSimulation.run(PairOfSequencesAccordSimulation.java:62)
at
org.apache.cassandra.simulator.SimulationRunner$Run.run(SimulationRunner.java:374)
at
org.apache.cassandra.simulator.paxos.AccordSimulationRunner$Run.run(AccordSimulationRunner.java:39)
at
org.apache.cassandra.simulator.paxos.AccordSimulationRunner$Run.run(AccordSimulationRunner.java:30)
at
org.apache.cassandra.simulator.SimulationRunner$BasicCommand.run(SimulationRunner.java:355)
at
org.apache.cassandra.simulator.paxos.AccordSimulationRunner.main(AccordSimulationRunner.java:76)
at
org.apache.cassandra.simulator.test.ShortAccordSimulationTest.simulationTest(ShortAccordSimulationTest.java:32)
{code}
See
https://app.circleci.com/pipelines/github/dcapwell/cassandra/1947/workflows/05ee1183-36a0-41de-a798-e49b4e1ec413/jobs/19052
--
This message was sent by Atlassian Jira
(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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18247: Reviewers: Brandon Williams, Michael Semb Wever (was: Brandon Williams) > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- This message was sent by Atlassian Jira (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-17940) CEP-20: Dynamic Data Masking
[
https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701389#comment-17701389
]
Andres de la Peña edited comment on CASSANDRA-17940 at 3/16/23 9:10 PM:
[~blerer] [~bereng] Here is the rebased PR for merging the feature branch, once
we have finished all the sub-tasks:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2193]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2717/workflows/6d367dde-786c-40b6-a625-f0345c4f76d0]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2717/workflows/234fab74-4413-428f-abb6-ea554f8b7e5a]|
|[dtests|https://github.com/apache/cassandra-dtest/pull/213]|
It combines CASSANDRA-18068, CASSANDRA-18069, CASSANDRA-18070, CASSANDRA-18071
and CASSANDRA-18316.
I took the liberty of adding the entries in
[{{changes.adoc}}|https://github.com/adelapena/cassandra/blob/17940-trunk/doc/modules/cassandra/pages/cql/changes.adoc#347]
that we missed during the separate tickets.
I don't know if we want to keep it as separate commits (once per sub-ticket),
or just squash it into a single commit. If we were going to squash it, what
should be the entry on
[{{CHANGES.txt}}|https://github.com/adelapena/cassandra/blob/17940-trunk/CHANGES.txt#L2-L6]
and
[{{changes.adoc}}|https://github.com/adelapena/cassandra/blob/17940-trunk/doc/modules/cassandra/pages/cql/changes.adoc#347]?
was (Author: adelapena):
Here is the rebased PR for merging the feature branch, once we have finished
all the sub-tasks:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2193]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2717/workflows/6d367dde-786c-40b6-a625-f0345c4f76d0]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2717/workflows/234fab74-4413-428f-abb6-ea554f8b7e5a]|
|[dtests|https://github.com/apache/cassandra-dtest/pull/213]|
It combines CASSANDRA-18068, CASSANDRA-18069, CASSANDRA-18070, CASSANDRA-18071
and CASSANDRA-18316.
I took the liberty of adding the entries in
[{{changes.adoc}}|https://github.com/adelapena/cassandra/blob/17940-trunk/doc/modules/cassandra/pages/cql/changes.adoc#347]
that we missed during the separate tickets.
I don't know if we want to keep it as separate commits (once per sub-ticket),
or just squash it into a single commit. If we were going to squash it, what
should be the entry on
[{{CHANGES.txt}}|https://github.com/adelapena/cassandra/blob/17940-trunk/CHANGES.txt#L2-L6]
and
[{{changes.adoc}}|https://github.com/adelapena/cassandra/blob/17940-trunk/doc/modules/cassandra/pages/cql/changes.adoc#347]?
> CEP-20: Dynamic Data Masking
>
>
> Key: CASSANDRA-17940
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17940
> Project: Cassandra
> Issue Type: Epic
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implementation of dynamic data masking as described in
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
> Dynamic data masking (DDM) allows to obscure sensitive information while
> still allowing access to the masked columns, and without changing the stored
> data. The CEP aims to provide DDM for Apache Cassandra using both native and
> user-defined CQL functions. These functions can be either be used on their
> own or be attached to specific columns in the table definition.
--
This message was sent by Atlassian Jira
(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-17940) CEP-20: Dynamic Data Masking
[ https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17940: -- Test and Documentation Plan: ||PR||CI|| |[trunk|https://github.com/apache/cassandra/pull/2193]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2717/workflows/6d367dde-786c-40b6-a625-f0345c4f76d0] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2717/workflows/234fab74-4413-428f-abb6-ea554f8b7e5a]| |[dtests|https://github.com/apache/cassandra-dtest/pull/213]| Status: Patch Available (was: In Progress) > CEP-20: Dynamic Data Masking > > > Key: CASSANDRA-17940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17940 > Project: Cassandra > Issue Type: Epic > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Implementation of dynamic data masking as described in > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > Dynamic data masking (DDM) allows to obscure sensitive information while > still allowing access to the masked columns, and without changing the stored > data. The CEP aims to provide DDM for Apache Cassandra using both native and > user-defined CQL functions. These functions can be either be used on their > own or be attached to specific columns in the table definition. -- This message was sent by Atlassian Jira (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-17940) CEP-20: Dynamic Data Masking
[
https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701389#comment-17701389
]
Andres de la Peña commented on CASSANDRA-17940:
---
Here is the rebased PR for merging the feature branch, once we have finished
all the sub-tasks:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2193]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2717/workflows/6d367dde-786c-40b6-a625-f0345c4f76d0]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2717/workflows/234fab74-4413-428f-abb6-ea554f8b7e5a]|
|[dtests|https://github.com/apache/cassandra-dtest/pull/213]|
It combines CASSANDRA-18068, CASSANDRA-18069, CASSANDRA-18070, CASSANDRA-18071
and CASSANDRA-18316.
I took the liberty of adding the entries in
[{{changes.adoc}}|https://github.com/adelapena/cassandra/blob/17940-trunk/doc/modules/cassandra/pages/cql/changes.adoc#347]
that we missed during the separate tickets.
I don't know if we want to keep it as separate commits (once per sub-ticket),
or just squash it into a single commit. If we were going to squash it, what
should be the entry on
[{{CHANGES.txt}}|https://github.com/adelapena/cassandra/blob/17940-trunk/CHANGES.txt#L2-L6]
and
[{{changes.adoc}}|https://github.com/adelapena/cassandra/blob/17940-trunk/doc/modules/cassandra/pages/cql/changes.adoc#347]?
> CEP-20: Dynamic Data Masking
>
>
> Key: CASSANDRA-17940
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17940
> Project: Cassandra
> Issue Type: Epic
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implementation of dynamic data masking as described in
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
> Dynamic data masking (DDM) allows to obscure sensitive information while
> still allowing access to the masked columns, and without changing the stored
> data. The CEP aims to provide DDM for Apache Cassandra using both native and
> user-defined CQL functions. These functions can be either be used on their
> own or be attached to specific columns in the table definition.
--
This message was sent by Atlassian Jira
(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-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699885#comment-17699885 ] Maulin Vasavada edited comment on CASSANDRA-18124 at 3/16/23 9:01 PM: -- [~smiklosovic] Here you go https://github.com/apache/cassandra/pull/2225 was (Author: maulin.vasavada): [~smiklosovic] Here you go with [a PR|https://github.com/instaclustr/cassandra/pull/49] on the instaclustr/cassandra. Let us review that and I can start porting those changes to 4.1/trunk on apache/cassandra. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (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-18337) Operations.migrateReadRequiredOperations fails due to concurrent access when TransactionStatement is prepared
[
https://issues.apache.org/jira/browse/CASSANDRA-18337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701386#comment-17701386
]
Caleb Rackliffe commented on CASSANDRA-18337:
-
+1 (assuming an uneventful rebase and test run)
> Operations.migrateReadRequiredOperations fails due to concurrent access when
> TransactionStatement is prepared
> -
>
> Key: CASSANDRA-18337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18337
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code}
> java.util.NoSuchElementException
> at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1000)
> at
> org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:71)
> at
> org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:63)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getTxnWriteFragment(ModificationStatement.java:828)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createWriteFragments(TransactionStatement.java:290)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createUpdate(TransactionStatement.java:309)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createTxn(TransactionStatement.java:334)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.execute(TransactionStatement.java:375)
> {code}
> this was caused by having shared mutable state! when we start creating the
> txn objects we would also mutate the mutations that had operations that need
> to be run in the txn, this has an issue when the txn is run from prepared
> statements as the object is shared by multiple threads, causing the array to
> be mutated while iterating.
--
This message was sent by Atlassian Jira
(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-18071) Allow to use user-defined functions (UDF) as masking functions
[ https://issues.apache.org/jira/browse/CASSANDRA-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18071: -- Source Control Link: https://github.com/apache/cassandra/pull/2193/commits/34d2e8bf492324354c1041d1a5d40a2e7694076a Resolution: Fixed Status: Resolved (was: Ready to Commit) > Allow to use user-defined functions (UDF) as masking functions > -- > > Key: CASSANDRA-18071 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18071 > 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: 5.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Allow to attach user-defined functions (UDF) to tables so they can be used as > masking functions, as defined by > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > This will be similar to the native data masking functions introduced by > CASSANDRA-17941 and attached to tables by CASSANDRA-18068. -- This message was sent by Atlassian Jira (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-18316) Add feature flag for dynamic data masking
[
https://issues.apache.org/jira/browse/CASSANDRA-18316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18316:
--
Source Control Link:
https://github.com/apache/cassandra/pull/2193/commits/5968af4d9051a68bb9e4f1748cd4654610231f1e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Add feature flag for dynamic data masking
> -
>
> Key: CASSANDRA-18316
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18316
> 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: 5.x
>
>
> Dynamic data masking
> ([CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking])
> is a new feature, so it will need a feature flag in {{cassandra.yaml}}.
> Something like:
> {code}
> # If enabled, dynamic data masking allows to attach CQL masking functions to
> the columns of a table.
> # Users without the UNMASK permission will see an obscured version of the
> values of the columns with an attached mask.
> # If dynamic data masking is disabled it won't be allowed to create new
> column masks, although it will still be possible
> # to drop any previously existing masks. Also, any existing mask will be
> ignored at query time, so all users will see
> # the clear values of the masked columns.
> dynamic_data_masking_enabled: false
> {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-18070) Add a new SELECT_MASKED permission
[
https://issues.apache.org/jira/browse/CASSANDRA-18070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18070:
--
Source Control Link:
https://github.com/apache/cassandra/pull/2193/commits/e8d02baf5b5f219e47859637cec151dc6ea36a24
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Add a new SELECT_MASKED permission
> --
>
> Key: CASSANDRA-18070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18070
> 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: 5.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Add a table-level SELECT_MASKED permission allowing certain users to query
> but not see the unmasked columns introduced by CASSANDRA-18068, assuming that
> they also have the SELECT permission on the table, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> It would look like:
> {code}
> > CREATE USER unprivileged_user WITH PASSWORD 'xyz';
> > CREATE USER privileged_user WITH PASSWORD 'zyx';
>
> > GRANT SELECT ON ALL TABLE patients TO unprivileged_user;
> > GRANT SELECT ON ALL TABLE patients TO privileged_user;
> > GRANT SELECT_MASKED ON ALL TABLE patients TO privileged_user;
>
> > LOGIN unprivileged_user
> > SELECT name, birth FROM patients WHERE name='alice' ALLOW FILTERING;
>
> Unauthorized: Error from server: code=2100 [Unauthorized] message="User has
> no UNMASK nor SELECT_UNMASK permission on "
>
> > LOGIN privileged_user
> > SELECT name, birth FROM patients WHERE name='alice' ALLOW FILTERING;
>
> name| birth
> -+
> ale | 1900-01-01
> {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-18316) Add feature flag for dynamic data masking
[
https://issues.apache.org/jira/browse/CASSANDRA-18316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701384#comment-17701384
]
Andres de la Peña commented on CASSANDRA-18316:
---
Committed to [the feature branch|https://github.com/apache/cassandra/pull/2193]
for CASSANDRA-17940 as
[5968af4d9051a68bb9e4f1748cd4654610231f1e|https://github.com/apache/cassandra/pull/2193/commits/5968af4d9051a68bb9e4f1748cd4654610231f1e].
Thanks for the review.
> Add feature flag for dynamic data masking
> -
>
> Key: CASSANDRA-18316
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18316
> 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: 5.x
>
>
> Dynamic data masking
> ([CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking])
> is a new feature, so it will need a feature flag in {{cassandra.yaml}}.
> Something like:
> {code}
> # If enabled, dynamic data masking allows to attach CQL masking functions to
> the columns of a table.
> # Users without the UNMASK permission will see an obscured version of the
> values of the columns with an attached mask.
> # If dynamic data masking is disabled it won't be allowed to create new
> column masks, although it will still be possible
> # to drop any previously existing masks. Also, any existing mask will be
> ignored at query time, so all users will see
> # the clear values of the masked columns.
> dynamic_data_masking_enabled: false
> {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-18071) Allow to use user-defined functions (UDF) as masking functions
[ https://issues.apache.org/jira/browse/CASSANDRA-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701383#comment-17701383 ] Andres de la Peña commented on CASSANDRA-18071: --- Committed to [the feature branch|https://github.com/apache/cassandra/pull/2193] for CASSANDRA-17940 as [34d2e8bf492324354c1041d1a5d40a2e7694076a|https://github.com/apache/cassandra/pull/2193/commits/34d2e8bf492324354c1041d1a5d40a2e7694076a]. Thanks for the reviews. > Allow to use user-defined functions (UDF) as masking functions > -- > > Key: CASSANDRA-18071 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18071 > 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: 5.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Allow to attach user-defined functions (UDF) to tables so they can be used as > masking functions, as defined by > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > This will be similar to the native data masking functions introduced by > CASSANDRA-17941 and attached to tables by CASSANDRA-18068. -- This message was sent by Atlassian Jira (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-18070) Add a new SELECT_MASKED permission
[
https://issues.apache.org/jira/browse/CASSANDRA-18070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701382#comment-17701382
]
Andres de la Peña commented on CASSANDRA-18070:
---
Committed to [the feature branch|https://github.com/apache/cassandra/pull/2193]
for CASSANDRA-17940 as
[e8d02baf5b5f219e47859637cec151dc6ea36a24|https://github.com/apache/cassandra/pull/2193/commits/e8d02baf5b5f219e47859637cec151dc6ea36a24].
Dtests committed to [the feature branch for
dtests|https://github.com/apache/cassandra-dtest/pull/213] as
[5bac7addccda73e1b514896737818d38262a69ff|https://github.com/apache/cassandra-dtest/pull/213/commits/5bac7addccda73e1b514896737818d38262a69ff].
Thanks for the reviews.
> Add a new SELECT_MASKED permission
> --
>
> Key: CASSANDRA-18070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18070
> 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: 5.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Add a table-level SELECT_MASKED permission allowing certain users to query
> but not see the unmasked columns introduced by CASSANDRA-18068, assuming that
> they also have the SELECT permission on the table, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> It would look like:
> {code}
> > CREATE USER unprivileged_user WITH PASSWORD 'xyz';
> > CREATE USER privileged_user WITH PASSWORD 'zyx';
>
> > GRANT SELECT ON ALL TABLE patients TO unprivileged_user;
> > GRANT SELECT ON ALL TABLE patients TO privileged_user;
> > GRANT SELECT_MASKED ON ALL TABLE patients TO privileged_user;
>
> > LOGIN unprivileged_user
> > SELECT name, birth FROM patients WHERE name='alice' ALLOW FILTERING;
>
> Unauthorized: Error from server: code=2100 [Unauthorized] message="User has
> no UNMASK nor SELECT_UNMASK permission on "
>
> > LOGIN privileged_user
> > SELECT name, birth FROM patients WHERE name='alice' ALLOW FILTERING;
>
> name| birth
> -+
> ale | 1900-01-01
> {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-18337) Operations.migrateReadRequiredOperations fails due to concurrent access when TransactionStatement is prepared
[
https://issues.apache.org/jira/browse/CASSANDRA-18337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18337:
--
Reviewers: Ariel Weisberg, Caleb Rackliffe (was: Caleb Rackliffe)
> Operations.migrateReadRequiredOperations fails due to concurrent access when
> TransactionStatement is prepared
> -
>
> Key: CASSANDRA-18337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18337
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code}
> java.util.NoSuchElementException
> at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1000)
> at
> org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:71)
> at
> org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:63)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getTxnWriteFragment(ModificationStatement.java:828)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createWriteFragments(TransactionStatement.java:290)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createUpdate(TransactionStatement.java:309)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createTxn(TransactionStatement.java:334)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.execute(TransactionStatement.java:375)
> {code}
> this was caused by having shared mutable state! when we start creating the
> txn objects we would also mutate the mutations that had operations that need
> to be run in the txn, this has an issue when the txn is run from prepared
> statements as the object is shared by multiple threads, causing the array to
> be mutated while iterating.
--
This message was sent by Atlassian Jira
(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-18340) Bump snakeyaml from 1.26 to 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18340: - Resolution: Duplicate Status: Resolved (was: Triage Needed) > Bump snakeyaml from 1.26 to 2.0 > --- > > Key: CASSANDRA-18340 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18340 > Project: Cassandra > Issue Type: New Feature >Reporter: Bipin Prasad >Assignee: Bipin Prasad >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > snakeyaml 1.26 has CVEs. Bump version for snakeyaml from 1.26 to 2.0 > To see the CVEs, goto > [https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.1.0] > and seach for [org.yaml|https://mvnrepository.com/artifact/org.yaml] » > [snakeyaml|https://mvnrepository.com/artifact/org.yaml/snakeyaml] under > compile dependencies.Vulnerabilites are listed thusly: > > Direct vulnerabilities: > [CVE-2022-41854|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41854] > [CVE-2022-38752|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38752] > [CVE-2022-38751|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38751] > [View 4 more ...|https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.26#] > Vulnerabilities from dependencies: > [CVE-2022-22971|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22971] > [CVE-2022-22970|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22970] > [CVE-2022-22968|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22968] > . -- This message was sent by Atlassian Jira (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-18340) Bump snakeyaml from 1.26 to 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701357#comment-17701357 ] Brandon Williams commented on CASSANDRA-18340: -- You can find all of the CVE suppressions [here|https://github.com/apache/cassandra/blob/trunk/.build/dependency-check-suppressions.xml#L34] and check against OWASP for more by running 'ant dependency-check.' You can blame the suppression file to find the tickets with reasoning behind the suppressions. > Bump snakeyaml from 1.26 to 2.0 > --- > > Key: CASSANDRA-18340 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18340 > Project: Cassandra > Issue Type: New Feature >Reporter: Bipin Prasad >Assignee: Bipin Prasad >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > snakeyaml 1.26 has CVEs. Bump version for snakeyaml from 1.26 to 2.0 > To see the CVEs, goto > [https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.1.0] > and seach for [org.yaml|https://mvnrepository.com/artifact/org.yaml] » > [snakeyaml|https://mvnrepository.com/artifact/org.yaml/snakeyaml] under > compile dependencies.Vulnerabilites are listed thusly: > > Direct vulnerabilities: > [CVE-2022-41854|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41854] > [CVE-2022-38752|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38752] > [CVE-2022-38751|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38751] > [View 4 more ...|https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.26#] > Vulnerabilities from dependencies: > [CVE-2022-22971|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22971] > [CVE-2022-22970|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22970] > [CVE-2022-22968|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22968] > . -- This message was sent by Atlassian Jira (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-18319) Cassandra in Kubernetes: IP switch decommission issue
[
https://issues.apache.org/jira/browse/CASSANDRA-18319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701356#comment-17701356
]
Brandon Williams commented on CASSANDRA-18319:
--
bq. I will add that the rolling restart is necessary to get the cluster into
this state. Since the restarts are staggered, the FatClient timeout each node
has for the old IP will trigger at different times, and their subsequent gossip
quarantines for the old IP will also end at different times.
Yes, if a rolling restart occurs before a fat client is fully removed, this
will happen.
bq. Presumably there is some value for QUARANTINE_DELAY that is large enough,
but it would probably need to scale with the number of nodes in the cluster.
One way to solve this is the same way we did for removed nodes in
CASSANDRA-2961 and use a timestamp to coordinate the removal without any
previous state, except fat clients don't have a concrete expiration time since
they are simply non-members - a boostrapping node that hasn't completed
joining, for instance.
The good news is that this is a cosmetic problem - this is only log noise. You
can also make it cease by assassinating the fat client IP, which will give it a
dead state with an expiration time in addition to removing it. In the future,
[transaction cluster
metadata|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata]
should be able to handle this in a more graceful manner.
> Cassandra in Kubernetes: IP switch decommission issue
> -
>
> Key: CASSANDRA-18319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18319
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ines Potier
>Priority: Normal
> Attachments: 3.11_gossipinfo.zip, node1_gossipinfo.txt,
> test_decommission_after_ip_change_logs.zip,
> v4.0_1678853171792_test_decommission_after_ip_change.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have recently encountered a recurring old IP reappearance issue while
> testing decommissions on some of our Kubernetes Cassandra staging clusters.
> *Issue Description*
> In Kubernetes, a Cassandra node can change IP at each pod bounce. We have
> noticed that this behavior, associated with a decommission operation, can get
> the cluster into an erroneous state.
> Consider the following situation: a Cassandra node {{node1}} , with
> {{{}hostId1{}}}, owning 20.5% of the token ring, bounces and switches IP
> ({{{}old_IP{}}} → {{{}new_IP{}}}). After a couple gossip iterations, all
> other nodes’ nodetool status output includes a {{new_IP}} UN entry owning
> 20.5% of the token ring and no {{old_IP}} entry.
> Shortly after the bounce, {{node1}} gets decommissioned. Our cluster does not
> have a lot of data, and the decommission operation completes pretty quickly.
> Logs on other nodes start showing acknowledgment that {{node1}} has left and
> soon, nodetool status’ {{new_IP}} UL entry disappears. {{node1}} ‘s pod is
> deleted.
> After a minute delay, the cluster enters the erroneous state. An {{old_IP}}
> DN entry reappears in nodetool status, owning 20.5% of the token ring. No
> node owns this IP anymore and according to logs, {{old_IP}} is still
> associated with {{{}hostId1{}}}.
> *Issue Root Cause*
> By digging through Cassandra logs, and re-testing this scenario over and over
> again, we have reached the following conclusion:
> * Other nodes will continue exchanging gossip about {{old_IP}} , even after
> it becomes a fatClient.
> * The fatClient timeout and subsequent quarantine does not stop {{old_IP}}
> from reappearing in a node’s Gossip state, once its quarantine is over. We
> believe that this is due to a misalignment on all nodes’ {{old_IP}}
> expiration time.
> * Once {{new_IP}} has left the cluster, and {{old_IP}} next gossip state
> message is received by a node, StorageService will no longer face collisions
> (or will, but with an even older IP) for {{hostId1}} and its corresponding
> tokens. As a result, {{old_IP}} will regain ownership of 20.5% of the token
> ring.
> *Proposed fix*
> Following the above investigation, we were thinking about implementing the
> following fix:
> When a node receives a gossip status change with {{STATE_LEFT}} for a leaving
> endpoint {{{}new_IP{}}}, before evicting {{{}new_IP from the token ring,
> purge from Gossip (ie evictFromMembership{}}}) all endpoints that meet the
> following criteria:
> * {{endpointStateMap}} contains this endpoint
> * The endpoint is not currently a token owner
> ({{{}!tokenMetadata.isMember(endpoint){}}})
> * The endpoint’s {{hostId}} matches the {{hostId}} of {{new_IP}}
> * The endpoint is older than {{leaving_IP}}
> ({{{}Gossiper.instance.compareEndpointStartup{}}})
> * The endpoint’s token
[jira] [Commented] (CASSANDRA-18340) Bump snakeyaml from 1.26 to 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701352#comment-17701352 ] Bipin Prasad commented on CASSANDRA-18340: -- PR: https://github.com/apache/cassandra/pull/2224 > Bump snakeyaml from 1.26 to 2.0 > --- > > Key: CASSANDRA-18340 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18340 > Project: Cassandra > Issue Type: New Feature >Reporter: Bipin Prasad >Assignee: Bipin Prasad >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > snakeyaml 1.26 has CVEs. Bump version for snakeyaml from 1.26 to 2.0 > To see the CVEs, goto > [https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.1.0] > and seach for [org.yaml|https://mvnrepository.com/artifact/org.yaml] » > [snakeyaml|https://mvnrepository.com/artifact/org.yaml/snakeyaml] under > compile dependencies.Vulnerabilites are listed thusly: > > Direct vulnerabilities: > [CVE-2022-41854|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41854] > [CVE-2022-38752|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38752] > [CVE-2022-38751|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38751] > [View 4 more ...|https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.26#] > Vulnerabilities from dependencies: > [CVE-2022-22971|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22971] > [CVE-2022-22970|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22970] > [CVE-2022-22968|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22968] > . -- This message was sent by Atlassian Jira (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-18340) Bump snakeyaml from 1.26 to 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bipin Prasad updated CASSANDRA-18340: - Description: snakeyaml 1.26 has CVEs. Bump version for snakeyaml from 1.26 to 2.0 To see the CVEs, goto [https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.1.0] and seach for [org.yaml|https://mvnrepository.com/artifact/org.yaml] » [snakeyaml|https://mvnrepository.com/artifact/org.yaml/snakeyaml] under compile dependencies.Vulnerabilites are listed thusly: Direct vulnerabilities: [CVE-2022-41854|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41854] [CVE-2022-38752|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38752] [CVE-2022-38751|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38751] [View 4 more ...|https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.26#] Vulnerabilities from dependencies: [CVE-2022-22971|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22971] [CVE-2022-22970|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22970] [CVE-2022-22968|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22968] . was:snakeyaml 1.26 has CVEs. Bump version for snakeyaml from 1.26 to 2.0 > Bump snakeyaml from 1.26 to 2.0 > --- > > Key: CASSANDRA-18340 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18340 > Project: Cassandra > Issue Type: New Feature >Reporter: Bipin Prasad >Assignee: Bipin Prasad >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > snakeyaml 1.26 has CVEs. Bump version for snakeyaml from 1.26 to 2.0 > To see the CVEs, goto > [https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.1.0] > and seach for [org.yaml|https://mvnrepository.com/artifact/org.yaml] » > [snakeyaml|https://mvnrepository.com/artifact/org.yaml/snakeyaml] under > compile dependencies.Vulnerabilites are listed thusly: > > Direct vulnerabilities: > [CVE-2022-41854|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41854] > [CVE-2022-38752|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38752] > [CVE-2022-38751|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38751] > [View 4 more ...|https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.26#] > Vulnerabilities from dependencies: > [CVE-2022-22971|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22971] > [CVE-2022-22970|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22970] > [CVE-2022-22968|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22968] > . -- This message was sent by Atlassian Jira (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-18071) Allow to use user-defined functions (UDF) as masking functions
[ https://issues.apache.org/jira/browse/CASSANDRA-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18071: -- Status: Ready to Commit (was: Review In Progress) > Allow to use user-defined functions (UDF) as masking functions > -- > > Key: CASSANDRA-18071 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18071 > 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: 5.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Allow to attach user-defined functions (UDF) to tables so they can be used as > masking functions, as defined by > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > This will be similar to the native data masking functions introduced by > CASSANDRA-17941 and attached to tables by CASSANDRA-18068. -- This message was sent by Atlassian Jira (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-18070) Add a new SELECT_MASKED permission
[
https://issues.apache.org/jira/browse/CASSANDRA-18070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18070:
--
Status: Ready to Commit (was: Review In Progress)
> Add a new SELECT_MASKED permission
> --
>
> Key: CASSANDRA-18070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18070
> 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: 5.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Add a table-level SELECT_MASKED permission allowing certain users to query
> but not see the unmasked columns introduced by CASSANDRA-18068, assuming that
> they also have the SELECT permission on the table, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> It would look like:
> {code}
> > CREATE USER unprivileged_user WITH PASSWORD 'xyz';
> > CREATE USER privileged_user WITH PASSWORD 'zyx';
>
> > GRANT SELECT ON ALL TABLE patients TO unprivileged_user;
> > GRANT SELECT ON ALL TABLE patients TO privileged_user;
> > GRANT SELECT_MASKED ON ALL TABLE patients TO privileged_user;
>
> > LOGIN unprivileged_user
> > SELECT name, birth FROM patients WHERE name='alice' ALLOW FILTERING;
>
> Unauthorized: Error from server: code=2100 [Unauthorized] message="User has
> no UNMASK nor SELECT_UNMASK permission on "
>
> > LOGIN privileged_user
> > SELECT name, birth FROM patients WHERE name='alice' ALLOW FILTERING;
>
> name| birth
> -+
> ale | 1900-01-01
> {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-18340) Bump snakeyaml from 1.26 to 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701342#comment-17701342 ] Brandon Williams commented on CASSANDRA-18340: -- Can you provide more detail? > Bump snakeyaml from 1.26 to 2.0 > --- > > Key: CASSANDRA-18340 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18340 > Project: Cassandra > Issue Type: New Feature >Reporter: Bipin Prasad >Assignee: Bipin Prasad >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > snakeyaml 1.26 has CVEs. Bump version for snakeyaml from 1.26 to 2.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18340) Bump snakeyaml from 1.26 to 2.0
Bipin Prasad created CASSANDRA-18340: Summary: Bump snakeyaml from 1.26 to 2.0 Key: CASSANDRA-18340 URL: https://issues.apache.org/jira/browse/CASSANDRA-18340 Project: Cassandra Issue Type: New Feature Reporter: Bipin Prasad snakeyaml 1.26 has CVEs. Bump version for snakeyaml from 1.26 to 2.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18340) Bump snakeyaml from 1.26 to 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bipin Prasad reassigned CASSANDRA-18340: Assignee: Bipin Prasad > Bump snakeyaml from 1.26 to 2.0 > --- > > Key: CASSANDRA-18340 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18340 > Project: Cassandra > Issue Type: New Feature >Reporter: Bipin Prasad >Assignee: Bipin Prasad >Priority: Normal > > snakeyaml 1.26 has CVEs. Bump version for snakeyaml from 1.26 to 2.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18339) Cassandra 3.11.2 windows remote share as data files directory
[ https://issues.apache.org/jira/browse/CASSANDRA-18339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18339: - Resolution: Won't Fix Status: Resolved (was: Triage Needed) > Cassandra 3.11.2 windows remote share as data files directory > -- > > Key: CASSANDRA-18339 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18339 > Project: Cassandra > Issue Type: Bug >Reporter: Navya Krishna Dubbala >Priority: Normal > > Hi Team, > > We are using windows 2018 server for running Cassandra 3.11.2 version with > remote windows server shared folder as data file directory path and we are > getting below error. > > ERROR [CompactionExecutor:1] 2023-03-10 09:18:44,511 > DefaultFSErrorHandler.java:92 - Exiting forcefully due to file system > exception on startup, disk failure policy "stop" > org.apache.cassandra.io.FSReadError: java.io.IOException: There are no more > files at > org.apache.cassandra.io.util.FileUtils.getCanonicalPath(FileUtils.java:303) > It is working inbetween. > -- This message was sent by Atlassian Jira (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-18339) Cassandra 3.11.2 windows remote share as data files directory
[ https://issues.apache.org/jira/browse/CASSANDRA-18339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701333#comment-17701333 ] Brandon Williams commented on CASSANDRA-18339: -- I don't know that this should work, I don't think it was tested, likely because having a remote filesystem of any kind is generally not recommended for performance reasons. Also note that Windows support is no more in 4.0 and later: CASSANDRA-16171 > Cassandra 3.11.2 windows remote share as data files directory > -- > > Key: CASSANDRA-18339 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18339 > Project: Cassandra > Issue Type: Bug >Reporter: Navya Krishna Dubbala >Priority: Normal > > Hi Team, > > We are using windows 2018 server for running Cassandra 3.11.2 version with > remote windows server shared folder as data file directory path and we are > getting below error. > > ERROR [CompactionExecutor:1] 2023-03-10 09:18:44,511 > DefaultFSErrorHandler.java:92 - Exiting forcefully due to file system > exception on startup, disk failure policy "stop" > org.apache.cassandra.io.FSReadError: java.io.IOException: There are no more > files at > org.apache.cassandra.io.util.FileUtils.getCanonicalPath(FileUtils.java:303) > It is working inbetween. > -- This message was sent by Atlassian Jira (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-18339) Cassandra 3.11.2 windows remote share as data files directory
Navya Krishna Dubbala created CASSANDRA-18339: - Summary: Cassandra 3.11.2 windows remote share as data files directory Key: CASSANDRA-18339 URL: https://issues.apache.org/jira/browse/CASSANDRA-18339 Project: Cassandra Issue Type: Bug Reporter: Navya Krishna Dubbala Hi Team, We are using windows 2018 server for running Cassandra 3.11.2 version with remote windows server shared folder as data file directory path and we are getting below error. ERROR [CompactionExecutor:1] 2023-03-10 09:18:44,511 DefaultFSErrorHandler.java:92 - Exiting forcefully due to file system exception on startup, disk failure policy "stop" org.apache.cassandra.io.FSReadError: java.io.IOException: There are no more files at org.apache.cassandra.io.util.FileUtils.getCanonicalPath(FileUtils.java:303) It is working inbetween. -- This message was sent by Atlassian Jira (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-17161) Remove commitlog_sync_batch_window_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701324#comment-17701324 ] Ekaterina Dimitrova edited comment on CASSANDRA-17161 at 3/16/23 6:11 PM: -- bq. Could you elaborate more on these few parameters? Which are they? All other parameters marked with @Deprecated in Config class. But I believe that since I opened this ticket there were discussions in time about removal of yaml configuration parameters(whether we can fully remove them even in major version or they should stay dead code, marked @Deprecated in Config to support easier upgrades). I haven't seen myself final decision made. Recommendation for whoever assigns the ticket: Please bring a list of planned cassandra.yaml configuration parameters for removal to the @dev ML for approval before submitting a patch. was (Author: e.dimitrova): bq. Could you elaborate more on these few parameters? Which are they? All other parameters marked with @Deprecated in Config class. But I believe that since I opened this ticket there were discussions in time about removal of yaml configuration parameters(whether we can fully remove them even in major version or they should stay dead code, marked @Deprecated in Config to support easier upgrades). I haven't seen myself final decision made. Recommendation for whoever assigns the ticket: Please bring a list of planned cassandra.yaml configuration parameters for removal to the ML for approval before submitting a patch. > Remove commitlog_sync_batch_window_in_ms > > > Key: CASSANDRA-17161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17161 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > commitlog_sync_batch_window_in_ms is deprecated in 4.0 and has to be removed > in 5.0 > This will require also some work around the in-jvm upgrade tests. > Currently they do not work if we remove a parameter in a later version. > Side note: They also don't work if we change the type of the parameter in > Config class in a newer Cassandra version. If you plan to set it in the tests > themselves, it won't work. If you change the type but your don't set the > parameter, no issue so there might be some workaround solution instead of > working on the dtest framework itself TBD -- This message was sent by Atlassian Jira (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-17161) Remove commitlog_sync_batch_window_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701324#comment-17701324 ] Ekaterina Dimitrova edited comment on CASSANDRA-17161 at 3/16/23 6:10 PM: -- bq. Could you elaborate more on these few parameters? Which are they? All other parameters marked with @Deprecated in Config class. But I believe that since I opened this ticket there were discussions in time about removal of yaml configuration parameters(whether we can fully remove them even in major version or they should stay dead code, marked @Deprecated in Config to support easier upgrades). I haven't seen myself final decision made. Recommendation for whoever assigns the ticket: Please bring a list of planned configuration parameters for removal to the ML for approval before submitting a patch. was (Author: e.dimitrova): bq. Could you elaborate more on these few parameters? Which are they? All other parameters marked with @Deprecated in Config class. But I believe that since I opened this ticket there were discussions in time about removal of yaml configuration parameters(whether we can fully remove them even in major version or they should stay dead code, marked @Deprecated in Config to support easier upgrades). Recommendation for whoever assigns the ticket: Please bring a list of planned configuration parameters for removal to the ML for approval before submitting a patch. > Remove commitlog_sync_batch_window_in_ms > > > Key: CASSANDRA-17161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17161 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > commitlog_sync_batch_window_in_ms is deprecated in 4.0 and has to be removed > in 5.0 > This will require also some work around the in-jvm upgrade tests. > Currently they do not work if we remove a parameter in a later version. > Side note: They also don't work if we change the type of the parameter in > Config class in a newer Cassandra version. If you plan to set it in the tests > themselves, it won't work. If you change the type but your don't set the > parameter, no issue so there might be some workaround solution instead of > working on the dtest framework itself TBD -- This message was sent by Atlassian Jira (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-17161) Remove commitlog_sync_batch_window_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701324#comment-17701324 ] Ekaterina Dimitrova edited comment on CASSANDRA-17161 at 3/16/23 6:10 PM: -- bq. Could you elaborate more on these few parameters? Which are they? All other parameters marked with @Deprecated in Config class. But I believe that since I opened this ticket there were discussions in time about removal of yaml configuration parameters(whether we can fully remove them even in major version or they should stay dead code, marked @Deprecated in Config to support easier upgrades). I haven't seen myself final decision made. Recommendation for whoever assigns the ticket: Please bring a list of planned cassandra.yaml configuration parameters for removal to the ML for approval before submitting a patch. was (Author: e.dimitrova): bq. Could you elaborate more on these few parameters? Which are they? All other parameters marked with @Deprecated in Config class. But I believe that since I opened this ticket there were discussions in time about removal of yaml configuration parameters(whether we can fully remove them even in major version or they should stay dead code, marked @Deprecated in Config to support easier upgrades). I haven't seen myself final decision made. Recommendation for whoever assigns the ticket: Please bring a list of planned configuration parameters for removal to the ML for approval before submitting a patch. > Remove commitlog_sync_batch_window_in_ms > > > Key: CASSANDRA-17161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17161 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > commitlog_sync_batch_window_in_ms is deprecated in 4.0 and has to be removed > in 5.0 > This will require also some work around the in-jvm upgrade tests. > Currently they do not work if we remove a parameter in a later version. > Side note: They also don't work if we change the type of the parameter in > Config class in a newer Cassandra version. If you plan to set it in the tests > themselves, it won't work. If you change the type but your don't set the > parameter, no issue so there might be some workaround solution instead of > working on the dtest framework itself TBD -- This message was sent by Atlassian Jira (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-17161) Remove commitlog_sync_batch_window_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701324#comment-17701324 ] Ekaterina Dimitrova commented on CASSANDRA-17161: - bq. Could you elaborate more on these few parameters? Which are they? All other parameters marked with @Deprecated in Config class. But I believe that since I opened this ticket there were discussions in time about removal of yaml configuration parameters(whether we can fully remove them even in major version or they should stay dead code, marked @Deprecated in Config to support easier upgrades). Recommendation for whoever assigns the ticket: Please bring a list of planned configuration parameters for removal to the ML for approval before submitting a patch. > Remove commitlog_sync_batch_window_in_ms > > > Key: CASSANDRA-17161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17161 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > commitlog_sync_batch_window_in_ms is deprecated in 4.0 and has to be removed > in 5.0 > This will require also some work around the in-jvm upgrade tests. > Currently they do not work if we remove a parameter in a later version. > Side note: They also don't work if we change the type of the parameter in > Config class in a newer Cassandra version. If you plan to set it in the tests > themselves, it won't work. If you change the type but your don't set the > parameter, no issue so there might be some workaround solution instead of > working on the dtest framework itself TBD -- This message was sent by Atlassian Jira (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-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18302: -- Source Control Link: https://github.com/apache/cassandra/commit/ef87a5ae224b12350a248e469bc3b42471490540 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cep-15-accord updated: Improve transaction statement validation
This is an automated email from the ASF dual-hosted git repository.
jlewandowski pushed a commit to branch cep-15-accord
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cep-15-accord by this push:
new ef87a5ae22 Improve transaction statement validation
ef87a5ae22 is described below
commit ef87a5ae224b12350a248e469bc3b42471490540
Author: Jacek Lewandowski
AuthorDate: Thu Mar 16 18:43:20 2023 +0100
Improve transaction statement validation
patch by Jacek Lewandowski; reviewed by David Capwell and Caleb Rackliffe
for CASSANDRA-18302
---
CHANGES.txt| 1 +
src/antlr/Parser.g | 38 +--
.../org/apache/cassandra/cql3/StatementSource.java | 76 ++
.../cassandra/cql3/statements/BatchStatement.java | 50 +++---
.../cassandra/cql3/statements/DeleteStatement.java | 28 --
.../cql3/statements/ModificationStatement.java | 55 ---
.../cassandra/cql3/statements/SelectStatement.java | 109 -
.../cql3/statements/TransactionStatement.java | 65 ++--
.../cassandra/cql3/statements/UpdateStatement.java | 47 ++---
src/java/org/apache/cassandra/db/view/View.java| 22 +++--
.../apache/cassandra/cql3/StatementSourceTest.java | 61
.../cql3/statements/TransactionStatementTest.java | 28 +++---
12 files changed, 451 insertions(+), 129 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 2937ec238a..9ff6764a47 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
accord
+ * Improve transaction statement validation (CASSANDRA-18302)
* Add support for prepared statements for accord transactions
(CASSANDRA-18299)
* Fix statement validation against partition range queries (CASSANDRA-18240)
* Fix null value handling for static columns (CASSANDRA-18241)
diff --git a/src/antlr/Parser.g b/src/antlr/Parser.g
index d69c7c7fd5..a076b204ff 100644
--- a/src/antlr/Parser.g
+++ b/src/antlr/Parser.g
@@ -34,6 +34,8 @@ options {
protected List references;
+private Token statementBeginMarker;
+
public static final Set reservedTypeNames = new HashSet()
{{
add("byte");
@@ -230,6 +232,19 @@ options {
{
// Do nothing.
}
+
+public Token stmtBegins()
+{
+statementBeginMarker = input.LT(1);
+return statementBeginMarker;
+}
+
+public StatementSource stmtSrc()
+{
+StatementSource stmtSrc = StatementSource.create(statementBeginMarker);
+statementBeginMarker = null;
+return stmtSrc;
+}
}
/** STATEMENTS **/
@@ -302,6 +317,7 @@ selectStatement returns [SelectStatement.RawStatement expr]
List groups = new ArrayList<>();
boolean allowFiltering = false;
boolean isJson = false;
+stmtBegins();
}
: K_SELECT
// json is a valid column name. By consequence, we need to resolve the
ambiguity for "json - json"
@@ -321,7 +337,7 @@ selectStatement returns [SelectStatement.RawStatement expr]
isJson,
null);
WhereClause where = wclause == null ? WhereClause.empty() :
wclause.build();
- $expr = new SelectStatement.RawStatement(cf, params,
$sclause.selectors, where, limit, perPartitionLimit);
+ $expr = new SelectStatement.RawStatement(cf, params,
$sclause.selectors, where, limit, perPartitionLimit, stmtSrc());
}
;
@@ -334,11 +350,12 @@ letStatement returns [SelectStatement.RawStatement expr]
Term.Raw limit = null;
}
: K_LET txnVar=IDENT '='
- '(' K_SELECT assignments=letSelectors K_FROM cf=columnFamilyName K_WHERE
wclause=whereClause ( K_LIMIT rows=intValue { limit = rows; } )? ')'
+ '(' { stmtBegins(); } K_SELECT assignments=letSelectors K_FROM
cf=columnFamilyName K_WHERE wclause=whereClause ( K_LIMIT rows=intValue { limit
= rows; } )? ')'
{
SelectStatement.Parameters params = new
SelectStatement.Parameters(Collections.emptyMap(), Collections.emptyList(),
false, false, false, $txnVar.text);
WhereClause where = wclause == null ? WhereClause.empty() :
wclause.build();
- $expr = new SelectStatement.RawStatement(cf, params, assignments,
where, limit, null);
+
+ $expr = new SelectStatement.RawStatement(cf, params, assignments,
where, limit, null, stmtSrc());
}
;
@@ -535,6 +552,9 @@ groupByClause[List groups]
*
*/
insertStatement returns [ModificationStatement.Parsed expr]
+@init {
+stmtBegins();
+}
: K_INSERT K_INTO cf=columnFamilyName
( st1=normalInsertStatement[cf] { $expr = st1; }
| K_JSON st2=jsonInsertStatement[cf] { $expr = st2; })
@@ -553,7 +573,7 @@ normalInsertStatement
[jira] [Updated] (CASSANDRA-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18302: -- Status: Ready to Commit (was: Review In Progress) > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- This message was sent by Atlassian Jira (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-17161) Remove commitlog_sync_batch_window_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701309#comment-17701309 ] Stefan Miklosovic commented on CASSANDRA-17161: --- Could you elaborate more on these few parameters? Which are they? Thanks. > Remove commitlog_sync_batch_window_in_ms > > > Key: CASSANDRA-17161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17161 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > commitlog_sync_batch_window_in_ms is deprecated in 4.0 and has to be removed > in 5.0 > This will require also some work around the in-jvm upgrade tests. > Currently they do not work if we remove a parameter in a later version. > Side note: They also don't work if we change the type of the parameter in > Config class in a newer Cassandra version. If you plan to set it in the tests > themselves, it won't work. If you change the type but your don't set the > parameter, no issue so there might be some workaround solution instead of > working on the dtest framework itself TBD -- This message was sent by Atlassian Jira (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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701308#comment-17701308 ] Brandon Williams commented on CASSANDRA-18247: -- bq. Also the `-e DTEST_BRANCH=… -e DTEST_REPO=…` options did not work for me Indeed, it _says_ it is setting them, but does not actually do so. > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- This message was sent by Atlassian Jira (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-18247) Add CircleCI config files for J11+J17
[
https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701307#comment-17701307
]
Michael Semb Wever edited comment on CASSANDRA-18247 at 3/16/23 5:03 PM:
-
bq. I think if I'm running the script to generate that config it's probably
what I'm going to use most of the time, and if I need to go back I can just run
generate.sh over it.
+1 , this caught me by surprise, was expecting the config.yml to have been
updated. (if someone accidentally commits config.yml they have buggered it
regardless which generate*.sh script they used.)
Also the {{`-e DTEST_BRANCH=… -e DTEST_REPO=…`}} options did not work for me.
(Was used on CASSANDRA-18049).
was (Author: michaelsembwever):
bq. I think if I'm running the script to generate that config it's probably
what I'm going to use most of the time, and if I need to go back I can just run
generate.sh over it.
+1 , this caught me by surprise, was expecting the config.yml to have been
updated. (if someone accidentally commits config.yml they have buggered it
regardless which generate*.sh script they used.)
Also the {{-e DTEST_BRANCH=… -e DTEST_REPO=…}} options did not work for me.
(Was used on CASSANDRA-18049).
> Add CircleCI config files for J11+J17
> -
>
> Key: CASSANDRA-18247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18247
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Based on the direction of [this
> discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy],
> I would like to propose CircleCI config files which can be used to test
> current trunk with JDK 17 (after I blindly remove the scripted UDFs in
> another ticket, to be opened soon)
--
This message was sent by Atlassian Jira
(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-18247) Add CircleCI config files for J11+J17
[
https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701307#comment-17701307
]
Michael Semb Wever commented on CASSANDRA-18247:
bq. I think if I'm running the script to generate that config it's probably
what I'm going to use most of the time, and if I need to go back I can just run
generate.sh over it.
+1 , this caught me by surprise, was expecting the config.yml to have been
updated. (if someone accidentally commits config.yml they have buggered it
regardless which generate*.sh script they used.)
Also the {{-e DTEST_BRANCH=… -e DTEST_REPO=…}} options did not work for me.
(Was used on CASSANDRA-18049).
> Add CircleCI config files for J11+J17
> -
>
> Key: CASSANDRA-18247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18247
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Based on the direction of [this
> discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy],
> I would like to propose CircleCI config files which can be used to test
> current trunk with JDK 17 (after I blindly remove the scripted UDFs in
> another ticket, to be opened soon)
--
This message was sent by Atlassian Jira
(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-18049) Update Chronicle Queue
[
https://issues.apache.org/jira/browse/CASSANDRA-18049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701303#comment-17701303
]
Michael Semb Wever edited comment on CASSANDRA-18049 at 3/16/23 4:58 PM:
-
Dependency changes (post dev@) are now:
Added (a few of these have been pinned so to specify a more recent version)
* affinity-3.23ea1.jar
* jffi-1.3.11-native.jar
* jffi-1.3.11.jar
* jna-platform-5.13.0.jar
* jnr-a64asm-1.0.0.jar
* jnr-constants-0.10.4.jar
* jnr-ffi-2.2.13.jar
* jnr-x86asm-1.0.2.jar
* posix-2.24ea4.jar
Upgraded
* chronicle-bytes-2.20.111.jar --> chronicle-bytes-2.23.33.jar
* chronicle-core-2.20.126.jar --> chronicle-core-2.23.36.jar
* chronicle-queue-5.20.123.jar --> chronicle-queue-5.23.37.jar
* chronicle-threads-2.20.111.jar --> chronicle-threads-2.23.25.jar
* chronicle-wire-2.20.117.jar --> chronicle-wire-2.23.39.jar
patches:
-
https://github.com/apache/cassandra/compare/trunk...michaelsembwever:cassandra:mck/18049/trunk
-
https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:cassandra-dtest:mck/18049
CI:
- j8+j11:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/130
- j11+j17:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/136 (using
CASSANDRA-18247)
(plenty of 17 failures there, but none seem related to this ticket)
was (Author: michaelsembwever):
Dependency changes (post dev@) are now:
Added (a few of these have been pinned so to specify a more recent version)
* affinity-3.23ea1.jar
* jffi-1.3.11-native.jar
* jffi-1.3.11.jar
* jna-platform-5.13.0.jar
* jnr-a64asm-1.0.0.jar
* jnr-constants-0.10.4.jar
* jnr-ffi-2.2.13.jar
* jnr-x86asm-1.0.2.jar
* posix-2.24ea4.jar
Upgraded
* chronicle-bytes-2.20.111.jar --> chronicle-bytes-2.23.33.jar
* chronicle-core-2.20.126.jar --> chronicle-core-2.23.36.jar
* chronicle-queue-5.20.123.jar --> chronicle-queue-5.23.37.jar
* chronicle-threads-2.20.111.jar --> chronicle-threads-2.23.25.jar
* chronicle-wire-2.20.117.jar --> chronicle-wire-2.23.39.jar
patches:
-
https://github.com/apache/cassandra/compare/trunk...michaelsembwever:cassandra:mck/18049/trunk
-
https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:cassandra-dtest:mck/18049
CI:
- j8+j11:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/130
- j11+j17:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/136 (using
CASSANDRA-18247)
(plenty of 17 failures there, but none seem related to this ticket)
> Update Chronicle Queue
> --
>
> Key: CASSANDRA-18049
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18049
> Project: Cassandra
> Issue Type: Task
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> According to [this|https://chronicle.software/chronicle-support-java-17]
> article:
> {code:java}
> Starting from chronicle-bom-2.22ea26, all new releases can be run under Java
> 17 when run on the class path (but not yet under the module path).{code}
> This BOM is newer than what we currently have in both 4.1 and trunk. 4.1
> points in comments to
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/1.16.23] which
> I believe was just forgotten to be updated/removed. The versions we see
> correspond to this BOM
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/2.20.226]
> It is still older than chronicle-bom-2.22ea26 so we need to upgrade. I
> suggest we also add a comment again which BOM is considered, this makes
> things easier.
> Further to running CI, review of the CHANGE logs needs to happen to ensure we
> do not miss anything that can impact us and it is not caught by our tests.
> For testing with JDK17, please, contact [~e.dimitrova] for latest branch and
> CI config (at this point feature branch in the cassandra repo does not exist)
>
--
This message was sent by Atlassian Jira
(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-18049) Update Chronicle Queue
[
https://issues.apache.org/jira/browse/CASSANDRA-18049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701303#comment-17701303
]
Michael Semb Wever commented on CASSANDRA-18049:
Dependency changes (post dev@) are now:
Added (a few of these have been pinned so to specify a more recent version)
* affinity-3.23ea1.jar
* jffi-1.3.11-native.jar
* jffi-1.3.11.jar
* jna-platform-5.13.0.jar
* jnr-a64asm-1.0.0.jar
* jnr-constants-0.10.4.jar
* jnr-ffi-2.2.13.jar
* jnr-x86asm-1.0.2.jar
* posix-2.24ea4.jar
Upgraded
* chronicle-bytes-2.20.111.jar --> chronicle-bytes-2.23.33.jar
* chronicle-core-2.20.126.jar --> chronicle-core-2.23.36.jar
* chronicle-queue-5.20.123.jar --> chronicle-queue-5.23.37.jar
* chronicle-threads-2.20.111.jar --> chronicle-threads-2.23.25.jar
* chronicle-wire-2.20.117.jar --> chronicle-wire-2.23.39.jar
patches:
-
https://github.com/apache/cassandra/compare/trunk...michaelsembwever:cassandra:mck/18049/trunk
-
https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:cassandra-dtest:mck/18049
CI:
- j8+j11:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/130
- j11+j17:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/136 (using
CASSANDRA-18247)
(plenty of 17 failures there, but none seem related to this ticket)
> Update Chronicle Queue
> --
>
> Key: CASSANDRA-18049
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18049
> Project: Cassandra
> Issue Type: Task
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> According to [this|https://chronicle.software/chronicle-support-java-17]
> article:
> {code:java}
> Starting from chronicle-bom-2.22ea26, all new releases can be run under Java
> 17 when run on the class path (but not yet under the module path).{code}
> This BOM is newer than what we currently have in both 4.1 and trunk. 4.1
> points in comments to
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/1.16.23] which
> I believe was just forgotten to be updated/removed. The versions we see
> correspond to this BOM
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/2.20.226]
> It is still older than chronicle-bom-2.22ea26 so we need to upgrade. I
> suggest we also add a comment again which BOM is considered, this makes
> things easier.
> Further to running CI, review of the CHANGE logs needs to happen to ensure we
> do not miss anything that can impact us and it is not caught by our tests.
> For testing with JDK17, please, contact [~e.dimitrova] for latest branch and
> CI config (at this point feature branch in the cassandra repo does not exist)
>
--
This message was sent by Atlassian Jira
(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-18337) Operations.migrateReadRequiredOperations fails due to concurrent access when TransactionStatement is prepared
[
https://issues.apache.org/jira/browse/CASSANDRA-18337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18337:
Reviewers: Caleb Rackliffe, Caleb Rackliffe
Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe)
Status: Review In Progress (was: Patch Available)
> Operations.migrateReadRequiredOperations fails due to concurrent access when
> TransactionStatement is prepared
> -
>
> Key: CASSANDRA-18337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18337
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> java.util.NoSuchElementException
> at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1000)
> at
> org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:71)
> at
> org.apache.cassandra.cql3.Operations.migrateReadRequiredOperations(Operations.java:63)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.getTxnWriteFragment(ModificationStatement.java:828)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createWriteFragments(TransactionStatement.java:290)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createUpdate(TransactionStatement.java:309)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.createTxn(TransactionStatement.java:334)
> at
> org.apache.cassandra.cql3.statements.TransactionStatement.execute(TransactionStatement.java:375)
> {code}
> this was caused by having shared mutable state! when we start creating the
> txn objects we would also mutate the mutations that had operations that need
> to be run in the txn, this has an issue when the txn is run from prepared
> statements as the object is shared by multiple threads, causing the array to
> be mutated while iterating.
--
This message was sent by Atlassian Jira
(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-18323) Remove org.apache.cassandra.hadoop code
[ https://issues.apache.org/jira/browse/CASSANDRA-18323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701299#comment-17701299 ] Stefan Miklosovic commented on CASSANDRA-18323: --- [https://app.circleci.com/pipelines/github/instaclustr/cassandra/2003/workflows/5945b655-5ec3-4665-8156-68e695642d94] [https://app.circleci.com/pipelines/github/instaclustr/cassandra/2003/workflows/36815e7c-61f9-436d-882a-e3a9d3c371c3] > Remove org.apache.cassandra.hadoop code > --- > > Key: CASSANDRA-18323 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18323 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (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-18247) Add CircleCI config files for J11+J17
[
https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701298#comment-17701298
]
Ekaterina Dimitrova commented on CASSANDRA-18247:
-
Thank you for the quick review!
{quote}handling config.yml in the script?
{quote}
I thought it might be more confusing when updating the new set of configuration
files - we all of a sudden to update also config.yml directly from
generate_11_and_17.sh. That is why I also added
[this|https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc#diff-6fcd5ddc6b9f5c68d75973fc034bd038f6ed5d6a064ae834d4b490b4a211f7deR139]
and
[this|https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc#diff-6fcd5ddc6b9f5c68d75973fc034bd038f6ed5d6a064ae834d4b490b4a211f7deR147]
message to the output when using the -f and -p flags.
{quote}I think if I'm running the script to generate that config it's probably
what I'm going to use most of the time, and if I need to go back I can just run
generate.sh over it.
{quote}
Indeed, this is second option but I got worried people will forget to do it and
it can easily become a mess in the cassandra repo. Someone will commit the
switch to 11+17 by mistake earlier than we want it. :) Otherwise it would have
followed the flow of the other flags usage - do not go and update config.yml
directly when using them.
> Add CircleCI config files for J11+J17
> -
>
> Key: CASSANDRA-18247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18247
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Based on the direction of [this
> discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy],
> I would like to propose CircleCI config files which can be used to test
> current trunk with JDK 17 (after I blindly remove the scripted UDFs in
> another ticket, to be opened soon)
--
This message was sent by Atlassian Jira
(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-18302) Fix AIOOBE and improve validation messages for transaction statements
[
https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701289#comment-17701289
]
Caleb Rackliffe commented on CASSANDRA-18302:
-
The Python dtests are all failing, but that's just because I need rebase
{{cep-15-accord}} to the TrM branch. I think we're looking okay otherwise.
Thanks!
> Fix AIOOBE and improve validation messages for transaction statements
> -
>
> Key: CASSANDRA-18302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18302
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown
> from asCql method when validation transaction statement. In addition, asCql
> does not return precisely the query user entered so the whole error message
> can be misleading.
--
This message was sent by Atlassian Jira
(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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18247: Reviewers: Brandon Williams Status: Review In Progress (was: Patch Available) > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- This message was sent by Atlassian Jira (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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701283#comment-17701283 ] Brandon Williams commented on CASSANDRA-18247: -- bq. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. Seeing this in the review, my gut was to get rid of the repetition but it does make sense and I agree with your choice. It will be much easier to rename generate_11_and_17.sh to generate.sh when we are ready for the switch. The readme made sense and I was able to follow it just fine, but I have a little bit of previous experience here. One thing though, why make us copy config_11_and_17.yml over config.yml instead of doing it like generate.sh does and handling config.yml in the script? I think if I'm running the script to generate that config it's probably what I'm going to use most of the time, and if I need to go back I can just run generate.sh over it. Everything else here looks good and I am generally +1. > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- This message was sent by Atlassian Jira (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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701171#comment-17701171 ] Ekaterina Dimitrova edited comment on CASSANDRA-18247 at 3/16/23 4:18 PM: -- Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] PR - [https://github.com/apache/cassandra/pull/2223] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2]: Started new run of j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run; the new one completed all good Other JDK11 tests completed successfully JDK17 seems good that it ran all tests we wanted with the resources we wanted and the right JDK. I will make a write up of the failures as per my earlier suggestion. (table on CASSANDRA-16895) [~brandon.williams], [~mck] - this is ready for review was (Author: e.dimitrova): Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] PR - [https://github.com/apache/cassandra/pull/2223] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2]: Started new run of j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run; the new one completed all good Other JDK11 tests completed successfully JDK17 seems good that it ran all tests we wanted with the resources we wanted and the right JDK. I will make a write up of the failures as per my earlier suggestion. [~brandon.williams], [~mck] - this is ready for review > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- This message was sent by Atlassian Jira (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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18247: Test and Documentation Plan: *Summary:* * Added separate CircleCI configuration files for JDK11+17 plus created a respective generate_11_and_17.sh script. The differentiator for all new files is they all end up with "_11_and_17" suffix as part of their names. The new script operates the new config files in the way generate.sh operates on the old JDK8+11 configuration files. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. * Updated the readme. I would appreciate constructive feedback from reviewers if it reads well or it is unclear and confusing. * Currently we miss upgrade tests because we do not have JDK11 upgrade tests yet * The simulator still does not support JDK17 so I added only JDK11 simulator tests * Current table of all test failures with respective ticket numbers will be posted on CASSANDRA-16895 after this one gets committed. * I also plan to send email update to @dev when this gets committed. It will inform people that the new configuration is available. Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2]: started new run of j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run; this one completed all good Other JDK11 tests completed successfully JDK17 seems good that it ran all tests we wanted with the resources we wanted and the right JDK. I will make a write up of the failures as per my earlier suggestion. was: *Summary:* * Added separate CircleCI configuration files for JDK11+17 plus created a respective generate_11_and_17.sh script. The differentiator for all new files is they all end up with "_11_and_17" suffix as part of their names. The new script operates the new config files in the way generate.sh operates on the old JDK8+11 configuration files. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. * Updated the readme. I would appreciate constructive feedback from reviewers if it reads well or it is unclear and confusing. * Currently we miss upgrade tests because we do not have JDK11 upgrade tests yet * The simulator still does not support JDK17 so I added only JDK11 simulator tests * Current table of all test failures with respective ticket numbers will be opened on CASSANDRA-16895 after this one gets committed. * I also plan to send email update to @dev when this gets committed. It will inform people that the new configuration is available. Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2]: started new run of j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run; this one completed all good Other JDK11 tests completed successfully JDK17 seems good that it ran all tests we wanted with the resources we wanted and the right JDK. I will make a write up of the failures as per my earlier suggestion. > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- This message was sent by Atlassian Jira (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-18328) Remove deprecated CQL functions dateof and unixtimestampof
[
https://issues.apache.org/jira/browse/CASSANDRA-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18328:
--
Fix Version/s: 5.0
(was: 5.x)
Source Control Link:
https://github.com/apache/cassandra/commit/3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Remove deprecated CQL functions dateof and unixtimestampof
> --
>
> Key: CASSANDRA-18328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18328
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.0
>
>
> The CQL functions {{dateof}} and {{unixtimestampof}} were [deprecated on
> Cassandra
> 2.2.0|https://github.com/apache/cassandra/commit/c08aaabd95d4872593c29807de6ec1485cefa7fa],
> almost eight years ago. They were deprecated in favour of the then new
> {{totimestamp}} and {{tounixtimestamp}} functions.
> A note about their deprecation was added to
> [{{NEWS.txt}}|https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L1421-L1423],
> and they were marked as deprecated on
> [{{CQL.textile}}|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#time-conversion-functions].
> They are also listed as deprecated on [the new
> doc|https://github.com/apache/cassandra/blob/trunk/doc/modules/cassandra/pages/cql/functions.adoc#time-conversion-functions].
> We can finally remove those functions in 5.0, since they have been deprecated
> for so long.
> Discussion thread
> [here|https://lists.apache.org/thread/0gs824fpsngn5dr0yq2x1h8qsflj5sr0].
--
This message was sent by Atlassian Jira
(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-18328) Remove deprecated CQL functions dateof and unixtimestampof
[
https://issues.apache.org/jira/browse/CASSANDRA-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701260#comment-17701260
]
Andres de la Peña commented on CASSANDRA-18328:
---
Committed to trunk as
[3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de|https://github.com/apache/cassandra/commit/3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de].
Dtests changes committed as
[5fd2c34171be16480e9a2181dd81df6ae37b9429|https://github.com/apache/cassandra-dtest/commit/5fd2c34171be16480e9a2181dd81df6ae37b9429].
Thanks for the reviews.
> Remove deprecated CQL functions dateof and unixtimestampof
> --
>
> Key: CASSANDRA-18328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18328
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
>
> The CQL functions {{dateof}} and {{unixtimestampof}} were [deprecated on
> Cassandra
> 2.2.0|https://github.com/apache/cassandra/commit/c08aaabd95d4872593c29807de6ec1485cefa7fa],
> almost eight years ago. They were deprecated in favour of the then new
> {{totimestamp}} and {{tounixtimestamp}} functions.
> A note about their deprecation was added to
> [{{NEWS.txt}}|https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L1421-L1423],
> and they were marked as deprecated on
> [{{CQL.textile}}|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#time-conversion-functions].
> They are also listed as deprecated on [the new
> doc|https://github.com/apache/cassandra/blob/trunk/doc/modules/cassandra/pages/cql/functions.adoc#time-conversion-functions].
> We can finally remove those functions in 5.0, since they have been deprecated
> for so long.
> Discussion thread
> [here|https://lists.apache.org/thread/0gs824fpsngn5dr0yq2x1h8qsflj5sr0].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch trunk updated: Remove deprecated CQL functions dateOf and unixTimestampOf
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 5fd2c341 Remove deprecated CQL functions dateOf and unixTimestampOf
5fd2c341 is described below
commit 5fd2c34171be16480e9a2181dd81df6ae37b9429
Author: Andrés de la Peña
AuthorDate: Tue Mar 14 13:20:59 2023 +
Remove deprecated CQL functions dateOf and unixTimestampOf
patch by Andrés de la Peña; reviewed by Berenguer Blasi and Stefan
Miklosovic for CASSANDRA-18328
---
upgrade_tests/cql_tests.py | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/upgrade_tests/cql_tests.py b/upgrade_tests/cql_tests.py
index e29042f8..8d3666c3 100644
--- a/upgrade_tests/cql_tests.py
+++ b/upgrade_tests/cql_tests.py
@@ -2652,9 +2652,13 @@ class TestCQL(UpgradeTester):
assert_row_count(cursor, 'test', 1, where="k = 0 AND t =
{}".format(dates[0]))
-assert_invalid(cursor, "SELECT dateOf(k) FROM test WHERE k = 0 AND
t = %s" % dates[0])
+assert_invalid(cursor, "SELECT minTimeuuid(k) FROM test WHERE k =
0 AND t = %s" % dates[0])
+
+cursor.execute("SELECT toTimestamp(t), toUnixTimestamp(t) FROM
test WHERE k = 0 AND t = %s" % dates[0])
+
+if self.get_node_version(is_upgraded) < LooseVersion('5.0'):
+cursor.execute("SELECT dateOf(t), unixTimestampOf(t) FROM test
WHERE k = 0 AND t = %s" % dates[0])
-cursor.execute("SELECT dateOf(t), unixTimestampOf(t) FROM test
WHERE k = 0 AND t = %s" % dates[0])
cursor.execute("SELECT t FROM test WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')")
# not sure what to check exactly so just checking the query returns
@@ -3029,7 +3033,10 @@ class TestCQL(UpgradeTester):
for i in range(0, 5):
cursor.execute("INSERT INTO test (k, t) VALUES (%d, now())" %
i)
-cursor.execute("SELECT dateOf(t) FROM test")
+cursor.execute("SELECT totimestamp(t) FROM test")
+
+if self.get_node_version(is_upgraded) < LooseVersion('5.0'):
+cursor.execute("SELECT dateOf(t) FROM test")
def test_conditional_update(self):
cursor = self.prepare()
@@ -3424,7 +3431,10 @@ class TestCQL(UpgradeTester):
cursor.execute("TRUNCATE test")
cursor.execute("INSERT INTO test(k) VALUES (0)")
-assert_one(cursor, "SELECT dateOf(t) FROM test WHERE k=0", [None])
+assert_one(cursor, "SELECT toTimestamp(t) FROM test WHERE k=0",
[None])
+
+if self.get_node_version(is_upgraded) < LooseVersion('5.0'):
+assert_one(cursor, "SELECT dateOf(t) FROM test WHERE k=0",
[None])
def test_cas_simple(self):
# cursor = self.prepare(nodes=3, rf=3)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Remove deprecated CQL functions dateOf and unixTimestampOf
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 3eb605b4db Remove deprecated CQL functions dateOf and unixTimestampOf 3eb605b4db is described below commit 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de Author: Andrés de la Peña AuthorDate: Tue Mar 14 13:20:26 2023 + Remove deprecated CQL functions dateOf and unixTimestampOf patch by Andrés de la Peña; reviewed by Berenguer Blasi and Stefan Miklosovic for CASSANDRA-18328 --- CHANGES.txt| 1 + NEWS.txt | 2 + README.asc | 2 +- doc/cql3/CQL.textile | 8 ++-- doc/modules/cassandra/pages/cql/changes.adoc | 4 ++ .../cassandra/pages/cql/cql_singlefile.adoc| 5 -- doc/modules/cassandra/pages/cql/functions.adoc | 4 -- doc/modules/cassandra/pages/new/virtualtables.adoc | 4 +- .../cassandra/pages/operating/virtualtables.adoc | 4 +- .../org/apache/cassandra/cql3/QueryProcessor.java | 2 +- .../apache/cassandra/cql3/functions/TimeFcts.java | 55 -- .../cassandra/cql3/functions/TimeFctsTest.java | 19 .../cql3/validation/entities/TimeuuidTest.java | 5 +- .../cql3/validation/entities/TypeTest.java | 4 -- .../validation/miscellaneous/OverflowTest.java | 2 +- .../cql3/validation/operations/SelectTest.java | 2 +- 16 files changed, 23 insertions(+), 100 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 344d60b2ed..cc277dbcc6 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 5.0 + * Remove deprecated CQL functions dateOf and unixTimestampOf (CASSANDRA-18328) * Remove DateTieredCompactionStrategy (CASSANDRA-18043) * Add system_views.max_sstable_size and system_views.max_sstable_duration tables (CASSANDRA-18333) * Extend implicit allow-filtering for virtual tables to clustering columns (CASSANDRA-18331) diff --git a/NEWS.txt b/NEWS.txt index f23a518d3d..e414d66500 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -148,6 +148,8 @@ Upgrading - Added API for alternative sstable implementations. For details, see src/java/org/apache/cassandra/io/sstable/SSTable_API.md - DateTieredCompactionStrategy was removed. Please change the compaction strategy for the tables using this strategy to TimeWindowCompactionStrategy before upgrading to this version. + - The deprecated functions `dateOf` and `unixTimestampOf` have been removed. They were deprecated and replaced by + `toTimestamp` and `toUnixTimestamp` in Cassandra 2.2. Deprecation --- diff --git a/README.asc b/README.asc index 8810f579f2..a2101a6e3a 100644 --- a/README.asc +++ b/README.asc @@ -41,7 +41,7 @@ be sitting in front of a prompt: Connected to Test Cluster at localhost:9160. -[cqlsh 6.2.0 | Cassandra 5.0-SNAPSHOT | CQL spec 3.4.6 | Native protocol v5] +[cqlsh 6.2.0 | Cassandra 5.0-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5] Use HELP for help. cqlsh> diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile index bd16a43ed4..0147caa322 100644 --- a/doc/cql3/CQL.textile +++ b/doc/cql3/CQL.textile @@ -18,7 +18,7 @@ # --> -h1. Cassandra Query Language (CQL) v3.4.6 +h1. Cassandra Query Language (CQL) v3.4.7 @@ -2149,8 +2149,6 @@ A number of functions are provided to "convert" a @timeuuid@, a @timestamp@ or a |@toUnixTimestamp@ |@timeuuid@ |Converts the @timeuuid@ argument into a @bigInt@ raw value| |@toUnixTimestamp@ |@timestamp@ |Converts the @timestamp@ argument into a @bigInt@ raw value| |@toUnixTimestamp@ |@date@ |Converts the @date@ argument into a @bigInt@ raw value| -|@dateOf@|@timeuuid@ |Similar to @toTimestamp(timeuuid)@ (DEPRECATED)| -|@unixTimestampOf@ |@timeuuid@ |Similar to @toUnixTimestamp(timeuuid)@ (DEPRECATED)| h4(#floorFun). Floor function @@ -2569,6 +2567,10 @@ h2(#changes). Changes The following describes the changes in each version of CQL. +h3. 3.4.7 + +* Remove deprecated functions @dateOf@ and @unixTimestampOf@, replaced by @toTimestamp@ and @toUnixTimestamp@. + h3. 3.4.6 * Add support for @IF EXISTS@ and @IF NOT EXISTS@ in @ALTER@ statements (see "CASSANDRA-16916":https://issues.apache.org/jira/browse/CASSANDRA-16916). diff --git a/doc/modules/cassandra/pages/cql/changes.adoc b/doc/modules/cassandra/pages/cql/changes.adoc index df99a39ef6..814da772f9 100644 --- a/doc/modules/cassandra/pages/cql/changes.adoc +++ b/doc/modules/cassandra/pages/cql/changes.adoc @@ -2,6 +2,10 @@ The following describes the changes in each version of CQL. +== 3.4.7 + +* Remove deprecated functions `dateOf` and `unixTimestampOf`, replaced by `toTimestamp` and `toUnixTimestamp` (`18328`) + == 3.4.6 * Add
[jira] [Commented] (CASSANDRA-18336) Sstables were cleared when restarting
[
https://issues.apache.org/jira/browse/CASSANDRA-18336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701229#comment-17701229
]
Brandon Williams commented on CASSANDRA-18336:
--
What version of C* is this against? Was any actual data lost? I tried this
against 4.0 and the behavior matched but all the data was still there so
nothing seems amiss.
> Sstables were cleared when restarting
> -
>
> Key: CASSANDRA-18336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18336
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: NAIZHEN QUE
>Priority: Normal
> Attachments: system.log.2023-02-21.0
>
>
> 1.When this exception occurs in the system
> {code:java}
> //
> ERROR [CompactionExecutor:351627] 2023-02-21 17:59:20,721
> CassandraDaemon.java:581 - Exception in thread
> Thread[CompactionExecutor:351627,1,main]
> org.apache.cassandra.io.FSReadError: java.io.IOException: Map failed
> at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:167)
> at
> org.apache.cassandra.io.util.MmappedRegions$State.add(MmappedRegions.java:310)
> at
> org.apache.cassandra.io.util.MmappedRegions$State.access$400(MmappedRegions.java:246)
> at
> org.apache.cassandra.io.util.MmappedRegions.updateState(MmappedRegions.java:170)
> at
> org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:73)
> at
> org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:61)
> at
> org.apache.cassandra.io.util.MmappedRegions.map(MmappedRegions.java:104)
> at
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:365)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openEarly(BigTableWriter.java:337)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.maybeReopenEarly(SSTableRewriter.java:172)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:124)
> at
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:64)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:137)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:193)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:77)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:298)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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:834)
> Caused by: java.io.IOException: Map failed
> at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1016)
> at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:163)
> ... 23 common frames omitted
> Caused by: java.lang.OutOfMemoryError: Map failed
> at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method)
> at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1013)
> {code}
> 2.Restart the node, Verifying logfile transaction ,All sstables are deleted
> {code:java}
> // code placeholder
> INFO [main] 2023-02-21 18:00:23,350 LogTransaction.java:240 - Unfinished
> transaction log, deleting
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8819408-big-Index.db
>
> INFO [main] 2023-02-21 18:00:23,615 LogTransaction.java:240 - Unfinished
> transaction log, deleting
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb-8819408-big-Data.db
>
> INFO [main] 2023-02-21 18:00:46,504 LogTransaction.java:240 - Unfinished
> transaction log, deleting
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b/nb_txn_compaction_c923b230-b077-11ed-a081-5d5a5c990823.log
>
> INFO [main] 2023-02-21 18:00:46,510 LogTransaction.java:536 - Verifying
> logfile transaction
> [nb_txn_compaction_461935b0-b1ce-11ed-a081-5d5a5c990823.log in
> /historyData/cassandra/data/kairosdb/data_points-870fab7087ba11eb8b50d3c6960df21b]
> INFO [main] 2023-02-21 18:00:46,517 LogTransaction.java:240 - Unfinished
>
[jira] [Updated] (CASSANDRA-18328) Remove deprecated CQL functions dateof and unixtimestampof
[
https://issues.apache.org/jira/browse/CASSANDRA-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18328:
--
Status: Ready to Commit (was: Review In Progress)
> Remove deprecated CQL functions dateof and unixtimestampof
> --
>
> Key: CASSANDRA-18328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18328
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
>
> The CQL functions {{dateof}} and {{unixtimestampof}} were [deprecated on
> Cassandra
> 2.2.0|https://github.com/apache/cassandra/commit/c08aaabd95d4872593c29807de6ec1485cefa7fa],
> almost eight years ago. They were deprecated in favour of the then new
> {{totimestamp}} and {{tounixtimestamp}} functions.
> A note about their deprecation was added to
> [{{NEWS.txt}}|https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L1421-L1423],
> and they were marked as deprecated on
> [{{CQL.textile}}|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#time-conversion-functions].
> They are also listed as deprecated on [the new
> doc|https://github.com/apache/cassandra/blob/trunk/doc/modules/cassandra/pages/cql/functions.adoc#time-conversion-functions].
> We can finally remove those functions in 5.0, since they have been deprecated
> for so long.
> Discussion thread
> [here|https://lists.apache.org/thread/0gs824fpsngn5dr0yq2x1h8qsflj5sr0].
--
This message was sent by Atlassian Jira
(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-18328) Remove deprecated CQL functions dateof and unixtimestampof
[
https://issues.apache.org/jira/browse/CASSANDRA-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18328:
--
Reviewers: Berenguer Blasi, Stefan Miklosovic (was: Berenguer Blasi)
> Remove deprecated CQL functions dateof and unixtimestampof
> --
>
> Key: CASSANDRA-18328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18328
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
>
> The CQL functions {{dateof}} and {{unixtimestampof}} were [deprecated on
> Cassandra
> 2.2.0|https://github.com/apache/cassandra/commit/c08aaabd95d4872593c29807de6ec1485cefa7fa],
> almost eight years ago. They were deprecated in favour of the then new
> {{totimestamp}} and {{tounixtimestamp}} functions.
> A note about their deprecation was added to
> [{{NEWS.txt}}|https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L1421-L1423],
> and they were marked as deprecated on
> [{{CQL.textile}}|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#time-conversion-functions].
> They are also listed as deprecated on [the new
> doc|https://github.com/apache/cassandra/blob/trunk/doc/modules/cassandra/pages/cql/functions.adoc#time-conversion-functions].
> We can finally remove those functions in 5.0, since they have been deprecated
> for so long.
> Discussion thread
> [here|https://lists.apache.org/thread/0gs824fpsngn5dr0yq2x1h8qsflj5sr0].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (c74e7b7e3 -> cc9fdd1c4)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard c74e7b7e3 generate docs for c4206294 new cc9fdd1c4 generate docs for c4206294 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (c74e7b7e3) \ N -- N -- N refs/heads/asf-staging (cc9fdd1c4) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18328) Remove deprecated CQL functions dateof and unixtimestampof
[
https://issues.apache.org/jira/browse/CASSANDRA-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701201#comment-17701201
]
Berenguer Blasi commented on CASSANDRA-18328:
-
+1
> Remove deprecated CQL functions dateof and unixtimestampof
> --
>
> Key: CASSANDRA-18328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18328
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
>
> The CQL functions {{dateof}} and {{unixtimestampof}} were [deprecated on
> Cassandra
> 2.2.0|https://github.com/apache/cassandra/commit/c08aaabd95d4872593c29807de6ec1485cefa7fa],
> almost eight years ago. They were deprecated in favour of the then new
> {{totimestamp}} and {{tounixtimestamp}} functions.
> A note about their deprecation was added to
> [{{NEWS.txt}}|https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L1421-L1423],
> and they were marked as deprecated on
> [{{CQL.textile}}|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#time-conversion-functions].
> They are also listed as deprecated on [the new
> doc|https://github.com/apache/cassandra/blob/trunk/doc/modules/cassandra/pages/cql/functions.adoc#time-conversion-functions].
> We can finally remove those functions in 5.0, since they have been deprecated
> for so long.
> Discussion thread
> [here|https://lists.apache.org/thread/0gs824fpsngn5dr0yq2x1h8qsflj5sr0].
--
This message was sent by Atlassian Jira
(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-18043) remove deprecated DateTieredCompactionStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701199#comment-17701199 ] Stefan Miklosovic commented on CASSANDRA-18043: --- Yes. testIndexedReaderRT is in Butler already, without a ticket, though. testIndexedReaderTombstone is not there testPagingWithClustering from SASICQLTest neither this is multiplexer which run CompactionCQLTest https://app.circleci.com/pipelines/github/instaclustr/cassandra/2002/workflows/2ce2b445-69e3-4fd9-ba77-9c968cf34d29/jobs/13677 > remove deprecated DateTieredCompactionStrategy > -- > > Key: CASSANDRA-18043 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18043 > Project: Cassandra > Issue Type: Task > Components: Local/Compaction/DTCS >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > DTCS was marked as deprecated in CASSANDRA-9666 which was released in 3.0.8 > and 3.8. If I get our deprecation policies right, we wait one major release > (4.0) and we can remove it in the next one (5.0). Having 4.1 about to be > released soon and 4.2 will be 5.0, I think nothing blocks us from removing > this strategy in trunk. > This also makes CASSANDRA-18042 easier as it would most probably have to > cover this strategy as well. -- This message was sent by Atlassian Jira (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-18043) remove deprecated DateTieredCompactionStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701196#comment-17701196 ] Brandon Williams commented on CASSANDRA-18043: -- Are you saying CompactionCQLTest is already flaky and only being discovered here? > remove deprecated DateTieredCompactionStrategy > -- > > Key: CASSANDRA-18043 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18043 > Project: Cassandra > Issue Type: Task > Components: Local/Compaction/DTCS >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > DTCS was marked as deprecated in CASSANDRA-9666 which was released in 3.0.8 > and 3.8. If I get our deprecation policies right, we wait one major release > (4.0) and we can remove it in the next one (5.0). Having 4.1 about to be > released soon and 4.2 will be 5.0, I think nothing blocks us from removing > this strategy in trunk. > This also makes CASSANDRA-18042 easier as it would most probably have to > cover this strategy as well. -- This message was sent by Atlassian Jira (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-18338) Fix flaky test: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest
[ https://issues.apache.org/jira/browse/CASSANDRA-18338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18338: - Summary: Fix flaky test: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest (was: Test failure: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest) > Fix flaky test: > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest > - > > Key: CASSANDRA-18338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18338 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: maxwellguo >Priority: Normal > Fix For: 4.1.x, 5.x > > > jdk8 and jdk11 all faild at some time, jdk8 failed once, and jdk11 failed > twice. > for jdk 11: > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest-.jdk11 > (from org.apache.cassandra.distributed.test.ByteBuddyExamplesTest-.jdk11) > Error Message > expected:<1> but was:<2> > Stacktrace > junit.framework.AssertionFailedError: expected:<1> but was:<2> > at > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) > at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) > at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) > at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.base/java.lang.Thread.run(Thread.java:829) > for jdk 8: > Error Message > expected:<1> but was:<4> > Stacktrace > junit.framework.AssertionFailedError: expected:<1> but was:<4> > at > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) > at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) > at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) > at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:750) > https://ci-cassandra.apache.org/job/Cassandra-4.1/286/testReport/org.apache.cassandra.distributed.test/ByteBuddyExamplesTest/countTest_2/ > https://ci-cassandra.apache.org/job/Cassandra-trunk/1489/testReport/org.apache.cassandra.distributed.test/ByteBuddyExamplesTest/countTest__jdk11/ -- This message was sent by Atlassian Jira (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-18338) Test failure: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest
[ https://issues.apache.org/jira/browse/CASSANDRA-18338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18338: - Complexity: Normal Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > Test failure: > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest > --- > > Key: CASSANDRA-18338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18338 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: maxwellguo >Priority: Normal > Fix For: 4.1.x, 5.x > > > jdk8 and jdk11 all faild at some time, jdk8 failed once, and jdk11 failed > twice. > for jdk 11: > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest-.jdk11 > (from org.apache.cassandra.distributed.test.ByteBuddyExamplesTest-.jdk11) > Error Message > expected:<1> but was:<2> > Stacktrace > junit.framework.AssertionFailedError: expected:<1> but was:<2> > at > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) > at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) > at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) > at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.base/java.lang.Thread.run(Thread.java:829) > for jdk 8: > Error Message > expected:<1> but was:<4> > Stacktrace > junit.framework.AssertionFailedError: expected:<1> but was:<4> > at > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) > at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) > at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) > at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:750) > https://ci-cassandra.apache.org/job/Cassandra-4.1/286/testReport/org.apache.cassandra.distributed.test/ByteBuddyExamplesTest/countTest_2/ > https://ci-cassandra.apache.org/job/Cassandra-trunk/1489/testReport/org.apache.cassandra.distributed.test/ByteBuddyExamplesTest/countTest__jdk11/ -- This message was sent by Atlassian Jira (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-18338) Test failure: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest
[ https://issues.apache.org/jira/browse/CASSANDRA-18338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18338: - Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Description: jdk8 and jdk11 all faild at some time, jdk8 failed once, and jdk11 failed twice. for jdk 11: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest-.jdk11 (from org.apache.cassandra.distributed.test.ByteBuddyExamplesTest-.jdk11) Error Message expected:<1> but was:<2> Stacktrace junit.framework.AssertionFailedError: expected:<1> but was:<2> at org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:829) for jdk 8: Error Message expected:<1> but was:<4> Stacktrace junit.framework.AssertionFailedError: expected:<1> but was:<4> at org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:750) https://ci-cassandra.apache.org/job/Cassandra-4.1/286/testReport/org.apache.cassandra.distributed.test/ByteBuddyExamplesTest/countTest_2/ https://ci-cassandra.apache.org/job/Cassandra-trunk/1489/testReport/org.apache.cassandra.distributed.test/ByteBuddyExamplesTest/countTest__jdk11/ was: jdk8 and jdk11 all faild at some time, jdk8 failed once, and jdk11 failed twice. for jdk 11: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest-.jdk11 (from org.apache.cassandra.distributed.test.ByteBuddyExamplesTest-.jdk11) Error Message expected:<1> but was:<2> Stacktrace junit.framework.AssertionFailedError: expected:<1> but was:<2> at org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:829) for jdk 8: Error Message expected:<1> but was:<4> Stacktrace junit.framework.AssertionFailedError: expected:<1> but was:<4> at org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:750) > Test failure: > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest > --- > > Key: CASSANDRA-18338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18338 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: maxwellguo >Priority: Normal > Fix For: 4.1.x, 5.x > > > jdk8 and jdk11 all faild at some time, jdk8 failed
[jira] [Updated] (CASSANDRA-18338) org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest
[ https://issues.apache.org/jira/browse/CASSANDRA-18338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18338: - Fix Version/s: 4.1.x 5.x > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest > - > > Key: CASSANDRA-18338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18338 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: maxwellguo >Priority: Normal > Fix For: 4.1.x, 5.x > > > jdk8 and jdk11 all faild at some time, jdk8 failed once, and jdk11 failed > twice. > for jdk 11: > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest-.jdk11 > (from org.apache.cassandra.distributed.test.ByteBuddyExamplesTest-.jdk11) > Error Message > expected:<1> but was:<2> > Stacktrace > junit.framework.AssertionFailedError: expected:<1> but was:<2> > at > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) > at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) > at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) > at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.base/java.lang.Thread.run(Thread.java:829) > for jdk 8: > Error Message > expected:<1> but was:<4> > Stacktrace > junit.framework.AssertionFailedError: expected:<1> but was:<4> > at > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) > at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) > at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) > at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:750) -- This message was sent by Atlassian Jira (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-18338) Test failure: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest
[ https://issues.apache.org/jira/browse/CASSANDRA-18338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18338: - Summary: Test failure: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest (was: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest) > Test failure: > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest > --- > > Key: CASSANDRA-18338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18338 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: maxwellguo >Priority: Normal > Fix For: 4.1.x, 5.x > > > jdk8 and jdk11 all faild at some time, jdk8 failed once, and jdk11 failed > twice. > for jdk 11: > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest-.jdk11 > (from org.apache.cassandra.distributed.test.ByteBuddyExamplesTest-.jdk11) > Error Message > expected:<1> but was:<2> > Stacktrace > junit.framework.AssertionFailedError: expected:<1> but was:<2> > at > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) > at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) > at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) > at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.base/java.lang.Thread.run(Thread.java:829) > for jdk 8: > Error Message > expected:<1> but was:<4> > Stacktrace > junit.framework.AssertionFailedError: expected:<1> but was:<4> > at > org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) > at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) > at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) > at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:750) -- This message was sent by Atlassian Jira (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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701171#comment-17701171 ] Ekaterina Dimitrova commented on CASSANDRA-18247: - Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] PR - [https://github.com/apache/cassandra/pull/2223] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2]: Started new run of j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run; the new one completed all good Other JDK11 tests completed successfully JDK17 seems good that it ran all tests we wanted with the resources we wanted and the right JDK. I will make a write up of the failures as per my earlier suggestion. [~brandon.williams], [~mck] - this is ready for review > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- This message was sent by Atlassian Jira (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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18247: Test and Documentation Plan: *Summary:* * Added separate CircleCI configuration files for JDK11+17 plus created a respective generate_11_and_17.sh script. The differentiator for all new files is they all end up with "_11_and_17" suffix as part of their names. The new script operates the new config files in the way generate.sh operates on the old JDK8+11 configuration files. Why I chose to do it that way? - I believe this will make it easy when the time to switch to 11+17 come. * Updated the readme. I would appreciate constructive feedback from reviewers if it reads well or it is unclear and confusing. * Currently we miss upgrade tests because we do not have JDK11 upgrade tests yet * The simulator still does not support JDK17 so I added only JDK11 simulator tests * Current table of all test failures with respective ticket numbers will be opened on CASSANDRA-16895 after this one gets committed. * I also plan to send email update to @dev when this gets committed. It will inform people that the new configuration is available. Patch - [https://github.com/apache/cassandra/commit/88dc2a6c7690472d78b428384793e383f37499dc] CI run [#2318|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18247-trunk-v2]: started new run of j11_cqlsh_dtests_py311 [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2318/workflows/7eb1fe27-71d0-46d9-9feb-4cdb65e0153e/jobs/19642] - there was a git clone issue in the previous run; this one completed all good Other JDK11 tests completed successfully JDK17 seems good that it ran all tests we wanted with the resources we wanted and the right JDK. I will make a write up of the failures as per my earlier suggestion. was: https://github.com/ekaterinadimitrova2/cassandra/commit/0b55262df66b6d1c32111a9932689b4cfafcac6f This config was successfully used for testing in CASSANDRA-18258: https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-trunk-3 Only in-jvm and unit tests as CCM is currently in maintenance Status: Patch Available (was: In Progress) > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- This message was sent by Atlassian Jira (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-18328) Remove deprecated CQL functions dateof and unixtimestampof
[
https://issues.apache.org/jira/browse/CASSANDRA-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701165#comment-17701165
]
Stefan Miklosovic commented on CASSANDRA-18328:
---
+1
> Remove deprecated CQL functions dateof and unixtimestampof
> --
>
> Key: CASSANDRA-18328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18328
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
>
> The CQL functions {{dateof}} and {{unixtimestampof}} were [deprecated on
> Cassandra
> 2.2.0|https://github.com/apache/cassandra/commit/c08aaabd95d4872593c29807de6ec1485cefa7fa],
> almost eight years ago. They were deprecated in favour of the then new
> {{totimestamp}} and {{tounixtimestamp}} functions.
> A note about their deprecation was added to
> [{{NEWS.txt}}|https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L1421-L1423],
> and they were marked as deprecated on
> [{{CQL.textile}}|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#time-conversion-functions].
> They are also listed as deprecated on [the new
> doc|https://github.com/apache/cassandra/blob/trunk/doc/modules/cassandra/pages/cql/functions.adoc#time-conversion-functions].
> We can finally remove those functions in 5.0, since they have been deprecated
> for so long.
> Discussion thread
> [here|https://lists.apache.org/thread/0gs824fpsngn5dr0yq2x1h8qsflj5sr0].
--
This message was sent by Atlassian Jira
(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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701129#comment-17701129
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
Nevermind, I rebased it on my own here:
[https://github.com/apache/cassandra/pull/]
I ll run CI soon.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12937:
--
Status: In Progress (was: Changes Suggested)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(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-18328) Remove deprecated CQL functions dateof and unixtimestampof
[
https://issues.apache.org/jira/browse/CASSANDRA-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701114#comment-17701114
]
Andres de la Peña commented on CASSANDRA-18328:
---
It seems this time CI is fully green :)
> Remove deprecated CQL functions dateof and unixtimestampof
> --
>
> Key: CASSANDRA-18328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18328
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
>
> The CQL functions {{dateof}} and {{unixtimestampof}} were [deprecated on
> Cassandra
> 2.2.0|https://github.com/apache/cassandra/commit/c08aaabd95d4872593c29807de6ec1485cefa7fa],
> almost eight years ago. They were deprecated in favour of the then new
> {{totimestamp}} and {{tounixtimestamp}} functions.
> A note about their deprecation was added to
> [{{NEWS.txt}}|https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L1421-L1423],
> and they were marked as deprecated on
> [{{CQL.textile}}|https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#time-conversion-functions].
> They are also listed as deprecated on [the new
> doc|https://github.com/apache/cassandra/blob/trunk/doc/modules/cassandra/pages/cql/functions.adoc#time-conversion-functions].
> We can finally remove those functions in 5.0, since they have been deprecated
> for so long.
> Discussion thread
> [here|https://lists.apache.org/thread/0gs824fpsngn5dr0yq2x1h8qsflj5sr0].
--
This message was sent by Atlassian Jira
(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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701098#comment-17701098
]
Stefan Miklosovic edited comment on CASSANDRA-12937 at 3/16/23 11:26 AM:
-
[~claude] would you mind to rework that PR against current trunk? I am getting
a lot of conflicts.
was (Author: smiklosovic):
[~claude] would you mind to rework that PR against trunk? I am getting a lot of
conflicts. This is a new feature and should be delivered in 5.0 first.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(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-18193) Provide design and API documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-18193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18193:
--
Change Category: Code Clarity
Complexity: Challenging
Component/s: Documentation/Javadoc
Status: Open (was: Triage Needed)
> Provide design and API documentation
>
>
> Key: CASSANDRA-18193
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18193
> Project: Cassandra
> Issue Type: Task
> Components: Accord, Documentation/Javadoc
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> Would be great if we have at minimum:
> - white paper in a form of an AsciiDoc or Markdown somewhere in the project
> tree
> - all interfaces and all methods in {{acccord.api}} have API docs explaining
> the requirements for the implementations
> - enums and their values across the project are documented
> - interfaces, abstract classes, or classes that do not inherit from anything
> in the project have at least some class level explanation
> Eventually, it would really awesome if concepts from the whitepaper are
> somehow referenced in the code (or vice-versa). It would make it much easier
> to understand the implementation and I believe it would improve reuse of this
> project for external applications
--
This message was sent by Atlassian Jira
(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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12937:
--
Status: Changes Suggested (was: Review In Progress)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701098#comment-17701098
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
[~claude] would you mind to rework that PR against trunk? I am getting a lot of
conflicts. This is a new feature and should be delivered in 5.0 first.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(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-18193) Provide design and API documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-18193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski reassigned CASSANDRA-18193:
-
Assignee: Jacek Lewandowski
> Provide design and API documentation
>
>
> Key: CASSANDRA-18193
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18193
> Project: Cassandra
> Issue Type: Task
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> Would be great if we have at minimum:
> - white paper in a form of an AsciiDoc or Markdown somewhere in the project
> tree
> - all interfaces and all methods in {{acccord.api}} have API docs explaining
> the requirements for the implementations
> - enums and their values across the project are documented
> - interfaces, abstract classes, or classes that do not inherit from anything
> in the project have at least some class level explanation
> Eventually, it would really awesome if concepts from the whitepaper are
> somehow referenced in the code (or vice-versa). It would make it much easier
> to understand the implementation and I believe it would improve reuse of this
> project for external applications
--
This message was sent by Atlassian Jira
(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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12937:
--
Fix Version/s: 5.x
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(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-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701089#comment-17701089
]
Sam Tunnicliffe commented on CASSANDRA-18153:
-
I think it would be generally useful to add a dtest that verifies the sstable
metadata once the node is fully started in the 2 cases:
* a new node joins
* an existing node restarts & replays log segments?
This would also help a lot when we come to address this in the CEP-21 branch,
so we can check whatever we do there is equivalent.
Also, it's an issue from CASSANDRA-16619 really, but I was surprised that the
originating host id isn't shown in {{sstablemetadata}} output, so the only way
to check this is by using the debugger (or by triggering the bug). We should
add it there, if not for older branches then at least in trunk as the output is
already changed by CASSANDRA-18134.
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
This message was sent by Atlassian Jira
(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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701090#comment-17701090
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
I think we are at the end of the review. I will run a CI to see how it behaves.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(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-18323) Remove org.apache.cassandra.hadoop code
[ https://issues.apache.org/jira/browse/CASSANDRA-18323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701075#comment-17701075 ] Stefan Miklosovic commented on CASSANDRA-18323: --- [~dcapwell] as you commented on the possible replacement of hsqldb dependency on ML and replacing it with Argona stuff, would you mind to take a look on my draft here (1) where it is done? I tried to follow your instructions on ML but I am not sure I got it right. (1) [https://github.com/apache/cassandra/pull/2212] > Remove org.apache.cassandra.hadoop code > --- > > Key: CASSANDRA-18323 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18323 > Project: Cassandra > Issue Type: Task > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (f711e8fb -> c74e7b7e)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard f711e8fb generate docs for c4206294 new c74e7b7e generate docs for c4206294 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (f711e8fb) \ N -- N -- N refs/heads/asf-staging (c74e7b7e) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/doc/4.2/cassandra/cql/cql_singlefile.html | 26 + content/doc/4.2/cassandra/cql/ddl.html | 4 +--- .../4.2/cassandra/operating/compaction/index.html | 12 -- .../doc/trunk/cassandra/cql/cql_singlefile.html| 26 + content/doc/trunk/cassandra/cql/ddl.html | 4 +--- .../cassandra/operating/compaction/index.html | 12 -- content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4796442 -> 4796442 bytes 8 files changed, 15 insertions(+), 71 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17701052#comment-17701052
]
maxwellguo commented on CASSANDRA-17698:
Sorry for the late reply, I didn't notice that the file format version didn't
change yet. I do aggree we should accept the path when the file format come to
the next version, as this patch only made a smll change to file content.
[~adelapena]
As for CASSANDRA-18254 I later think may be CASSANDRA-17698 is enough，So I
closed it.
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {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] [Created] (CASSANDRA-18338) org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest
maxwellguo created CASSANDRA-18338: -- Summary: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest Key: CASSANDRA-18338 URL: https://issues.apache.org/jira/browse/CASSANDRA-18338 Project: Cassandra Issue Type: Bug Components: CI, Test/unit Reporter: maxwellguo jdk8 and jdk11 all faild at some time, jdk8 failed once, and jdk11 failed twice. for jdk 11: org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.countTest-.jdk11 (from org.apache.cassandra.distributed.test.ByteBuddyExamplesTest-.jdk11) Error Message expected:<1> but was:<2> Stacktrace junit.framework.AssertionFailedError: expected:<1> but was:<2> at org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:829) for jdk 8: Error Message expected:<1> but was:<4> Stacktrace junit.framework.AssertionFailedError: expected:<1> but was:<4> at org.apache.cassandra.distributed.test.ByteBuddyExamplesTest.lambda$countTest$81c80a4a$1(ByteBuddyExamplesTest.java:93) at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:750) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
