[jira] [Created] (CASSANDRA-17208) Improve backup / restore documentation
Jacek Lewandowski created CASSANDRA-17208: - Summary: Improve backup / restore documentation Key: CASSANDRA-17208 URL: https://issues.apache.org/jira/browse/CASSANDRA-17208 Project: Cassandra Issue Type: Task Components: Documentation/Website Reporter: Jacek Lewandowski The page about backup and restore lacks description about how to restore data after snapshot or backup Few statements at https://cassandra.apache.org/doc/latest/cassandra/operating/backups.html#restoring-from-incremental-backups-and-snapshots is far too little and does not actually show how to do that. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17207) The process cannot access the file because it is being used by another process.
[ https://issues.apache.org/jira/browse/CASSANDRA-17207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shravansingh updated CASSANDRA-17207: - Description: ERROR [COMMIT-LOG-ALLOCATOR] 2021-12-11 17:02:00,989 JVMStabilityInspector.java:140 - JVM state determined to be unstable. Exiting forcefully due to: org.apache.cassandra.io.FSWriteError: java.nio.file.FileSystemException: \commitlog\CommitLog-6-1636406548826.log: The process cannot access the file because it is being used by another process. at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:138) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:155) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:342) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.db.commitlog.CommitLogSegmentManager$2.run(CommitLogSegmentManager.java:379) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.db.commitlog.CommitLogSegmentManager$1.runMayThrow(CommitLogSegmentManager.java:156) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) [apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79) [apache-cassandra-3.0.14.jar:3.0.14] at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_301] Caused by: java.nio.file.FileSystemException: \commitlog\CommitLog-6-1636406548826.log: The process cannot access the file because it is being used by another process. at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) ~[na:1.8.0_301] at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) ~[na:1.8.0_301] at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) ~[na:1.8.0_301] at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) ~[na:1.8.0_301] at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) ~[na:1.8.0_301] at java.nio.file.Files.delete(Unknown Source) ~[na:1.8.0_301] at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:132) ~[apache-cassandra-3.0.14.jar:3.0.14] ... 7 common frames omitted It seems similar to https://issues.apache.org/jira/browse/CASSANDRA-8390, but it was resolved in 2.2 beta, though I am facing this in version 3.0.14 I am running this on windows server OS and in cassandra.yaml, disk_access_mode is set to standard was: ERROR [COMMIT-LOG-ALLOCATOR] 2021-12-11 17:02:00,989 JVMStabilityInspector.java:140 - JVM state determined to be unstable. Exiting forcefully due to: org.apache.cassandra.io.FSWriteError: java.nio.file.FileSystemException: \commitlog\CommitLog-6-1636406548826.log: The process cannot access the file because it is being used by another process. at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:138) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:155) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:342) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.db.commitlog.CommitLogSegmentManager$2.run(CommitLogSegmentManager.java:379) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.db.commitlog.CommitLogSegmentManager$1.runMayThrow(CommitLogSegmentManager.java:156) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) [apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79) [apache-cassandra-3.0.14.jar:3.0.14] at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_301] Caused by: java.nio.file.FileSystemException: \commitlog\CommitLog-6-1636406548826.log: The process cannot access the file because it is being used by another process. at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) ~[na:1.8.0_301] at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) ~[na:1.8.0_301] at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) ~[na:1.8.0_301] at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) ~[na:1.8.0_301] at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) ~[na:1.8.0_301] at java.nio.file.Files.delete(Unknown Source) ~[na:1.8.0_301] at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:132) ~[apache-cassandra-3.0.14.jar:3.0.14] ... 7 common frames omitted It seems similar to https://issues.apache.org/jira/browse/CASSANDRA-8390, but it was resolved in 2.2
[jira] [Updated] (CASSANDRA-17207) The process cannot access the file because it is being used by another process.
[ https://issues.apache.org/jira/browse/CASSANDRA-17207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shravansingh updated CASSANDRA-17207: - Platform: All,Azure (was: All) > The process cannot access the file because it is being used by another > process. > --- > > Key: CASSANDRA-17207 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17207 > Project: Cassandra > Issue Type: Bug >Reporter: shravansingh >Priority: Normal > > > ERROR [COMMIT-LOG-ALLOCATOR] 2021-12-11 17:02:00,989 > JVMStabilityInspector.java:140 - JVM state determined to be unstable. > Exiting forcefully due to: > org.apache.cassandra.io.FSWriteError: java.nio.file.FileSystemException: > \commitlog\CommitLog-6-1636406548826.log: The process cannot access > the file because it is being used by another process. > > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:138) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:155) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:342) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManager$2.run(CommitLogSegmentManager.java:379) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManager$1.runMayThrow(CommitLogSegmentManager.java:156) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > [apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79) > [apache-cassandra-3.0.14.jar:3.0.14] > at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_301] > Caused by: java.nio.file.FileSystemException: > \commitlog\CommitLog-6-1636406548826.log: The process cannot access > the file because it is being used by another process. > > at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) > ~[na:1.8.0_301] > at java.nio.file.Files.delete(Unknown Source) ~[na:1.8.0_301] > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:132) > ~[apache-cassandra-3.0.14.jar:3.0.14] > ... 7 common frames omitted > It seems similar to https://issues.apache.org/jira/browse/CASSANDRA-8390, but > it was resolved in 2.2 beta, though I am facing this in version 3.0.14 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17207) The process cannot access the file because it is being used by another process.
[ https://issues.apache.org/jira/browse/CASSANDRA-17207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shravansingh updated CASSANDRA-17207: - Impacts: Clients (was: None) > The process cannot access the file because it is being used by another > process. > --- > > Key: CASSANDRA-17207 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17207 > Project: Cassandra > Issue Type: Bug >Reporter: shravansingh >Priority: Normal > > > ERROR [COMMIT-LOG-ALLOCATOR] 2021-12-11 17:02:00,989 > JVMStabilityInspector.java:140 - JVM state determined to be unstable. > Exiting forcefully due to: > org.apache.cassandra.io.FSWriteError: java.nio.file.FileSystemException: > \commitlog\CommitLog-6-1636406548826.log: The process cannot access > the file because it is being used by another process. > > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:138) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:155) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:342) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManager$2.run(CommitLogSegmentManager.java:379) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManager$1.runMayThrow(CommitLogSegmentManager.java:156) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > [apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79) > [apache-cassandra-3.0.14.jar:3.0.14] > at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_301] > Caused by: java.nio.file.FileSystemException: > \commitlog\CommitLog-6-1636406548826.log: The process cannot access > the file because it is being used by another process. > > at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) > ~[na:1.8.0_301] > at java.nio.file.Files.delete(Unknown Source) ~[na:1.8.0_301] > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:132) > ~[apache-cassandra-3.0.14.jar:3.0.14] > ... 7 common frames omitted > It seems similar to https://issues.apache.org/jira/browse/CASSANDRA-8390, but > it was resolved in 2.2 beta, though I am facing this in version 3.0.14 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17207) The process cannot access the file because it is being used by another process.
shravansingh created CASSANDRA-17207: Summary: The process cannot access the file because it is being used by another process. Key: CASSANDRA-17207 URL: https://issues.apache.org/jira/browse/CASSANDRA-17207 Project: Cassandra Issue Type: Bug Reporter: shravansingh ERROR [COMMIT-LOG-ALLOCATOR] 2021-12-11 17:02:00,989 JVMStabilityInspector.java:140 - JVM state determined to be unstable. Exiting forcefully due to: org.apache.cassandra.io.FSWriteError: java.nio.file.FileSystemException: \commitlog\CommitLog-6-1636406548826.log: The process cannot access the file because it is being used by another process. at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:138) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:155) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:342) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.db.commitlog.CommitLogSegmentManager$2.run(CommitLogSegmentManager.java:379) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.db.commitlog.CommitLogSegmentManager$1.runMayThrow(CommitLogSegmentManager.java:156) ~[apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) [apache-cassandra-3.0.14.jar:3.0.14] at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79) [apache-cassandra-3.0.14.jar:3.0.14] at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_301] Caused by: java.nio.file.FileSystemException: \commitlog\CommitLog-6-1636406548826.log: The process cannot access the file because it is being used by another process. at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) ~[na:1.8.0_301] at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) ~[na:1.8.0_301] at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) ~[na:1.8.0_301] at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) ~[na:1.8.0_301] at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) ~[na:1.8.0_301] at java.nio.file.Files.delete(Unknown Source) ~[na:1.8.0_301] at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:132) ~[apache-cassandra-3.0.14.jar:3.0.14] ... 7 common frames omitted It seems similar to https://issues.apache.org/jira/browse/CASSANDRA-8390, but it was resolved in 2.2 beta, though I am facing this in version 3.0.14 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17204) Upgrade to Logback 1.2.8 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17204:
-
Fix Version/s: 3.0.x
3.11.x
4.0.x
> Upgrade to Logback 1.2.8 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Jochen Schalanda
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17204) Upgrade to Logback 1.2.8 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459528#comment-17459528
]
Brandon Williams commented on CASSANDRA-17204:
--
It's probably worth considering upgrading all the branches.
||Branch||CI||
|[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17204]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17204],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1322/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1322/pipeline]|
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-17204-3.11]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17204-3.11],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1323/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1323/pipeline]|
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17204-4.0]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17204-4.0],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1324/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1324/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17204-trunk]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17204-trunk],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1325/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1325/pipeline]|
> Upgrade to Logback 1.2.8 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Jochen Schalanda
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17142) Limit the maximum hints size per host
[ https://issues.apache.org/jira/browse/CASSANDRA-17142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRA-17142: --- Reviewers: Francisco Guerrero Status: Review In Progress (was: Patch Available) Reviewing PR in GitHub > Limit the maximum hints size per host > - > > Key: CASSANDRA-17142 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17142 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Hints >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Time Spent: 1h 10m > Remaining Estimate: 0h > > The hints system defines a time window, i.e. max_hint_window_in_ms, to store > the hints. > It defines no limit on how much data can be kept during the time window. The > hints can grow excessively and make the node running out of disk. In such > scenario, the operators have to truncate the hints manually. > I'd propose that in addition to the conventional hints window, operators > should be able to define the maximum hints size per host, i.e. > max_hints_size_per_host_in_mb, to provide an another layer of protection. A > node stops to store hints for the down node whenever it reaches to the time > cap or the size cap. In order to not surprise the users, the config should be > disabled by default. It should also be configurable via JMX. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17142) Limit the maximum hints size per host
[ https://issues.apache.org/jira/browse/CASSANDRA-17142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459517#comment-17459517 ] Yifan Cai commented on CASSANDRA-17142: --- [~frankgh], thanks for reviewing. I just pushed a commit to address. > Limit the maximum hints size per host > - > > Key: CASSANDRA-17142 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17142 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Hints >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Time Spent: 1h 10m > Remaining Estimate: 0h > > The hints system defines a time window, i.e. max_hint_window_in_ms, to store > the hints. > It defines no limit on how much data can be kept during the time window. The > hints can grow excessively and make the node running out of disk. In such > scenario, the operators have to truncate the hints manually. > I'd propose that in addition to the conventional hints window, operators > should be able to define the maximum hints size per host, i.e. > max_hints_size_per_host_in_mb, to provide an another layer of protection. A > node stops to store hints for the down node whenever it reaches to the time > cap or the size cap. In order to not surprise the users, the config should be > disabled by default. It should also be configurable via JMX. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17204) Upgrade to Logback 1.2.8 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17204:
Assignee: Brandon Williams
> Upgrade to Logback 1.2.8 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Jochen Schalanda
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459504#comment-17459504 ] Stefan Miklosovic commented on CASSANDRA-10023: --- should be fixed here: https://github.com/smiklosovic/cassandra-dtest/commit/0226bb8c6f4b75422c7f8dfd766679907cd20ca2 running this: [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1321/] i ll take care of that tomorrow > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Sankalp Kohli >Assignee: Stefan Miklosovic >Priority: Low > Labels: 4.0-feature-freeze-review-requested, lhf > Fix For: 4.1 > > Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, > CASSANDRA-10023.patch > > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17189) Guardrail for page size
[
https://issues.apache.org/jira/browse/CASSANDRA-17189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459501#comment-17459501
]
Bartlomiej edited comment on CASSANDRA-17189 at 12/14/21, 9:32 PM:
---
Thanks a lot [~adelapena] for help with tests (especially with those
executeWithPaging method - it would take me ages to make it working like this).
I also applied your changes (sorry for not applying code-formatting before - I
just realized that Intellij config has it out-of-the-box). Here is the PR
[https://github.com/apache/cassandra/pull/1361] (so it will be easier to
comment :) )
once again thanks for all your help ;)
was (Author: bkowalczyyk):
Thanks a lot [~adelapena] for help with tests (especially with those
executeWithPaging method - it would take me ages to make it working like this).
I also applied your changes (sorry for not applying code-formatting - I just
realized that Intellij config has it out-of-the-box). Here is the PR
[https://github.com/apache/cassandra/pull/1361] (so it will be easier to
comment :) )
once again thanks for all your help ;)
> Guardrail for page size
> ---
>
> Key: CASSANDRA-17189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17189
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Attachments: CASSANDRA-17189-trunk.diff
>
>
> Add guardrail limiting the query page size, for example:
> {code}
> # Guardrail to warn about or reject page sizes greater than threshold.
> # The two thresholds default to -1 to disable.
> page_size:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> Initially this can be based on the specified number of rows used as page
> size, although it would be ideal to also limit the actual size in bytes of
> the returned pages.
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on page size in the guardrails
> section of cassandra.yaml.
> # Add a getPageSize method in GuardrailsConfig returning a Threshold.Config
> object
> # Implement that method in GuardrailsOptions, which is the default yaml-based
> implementation of GuardrailsConfig
> # Add a Threshold guardrail named pageSize in Guardrails, using the
> previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails.pageSize#guard method with the page size
> that each query is going to use. The DataLimits#forPaging methods look like
> good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17189) Guardrail for page size
[
https://issues.apache.org/jira/browse/CASSANDRA-17189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459501#comment-17459501
]
Bartlomiej edited comment on CASSANDRA-17189 at 12/14/21, 9:32 PM:
---
Thanks a lot [~adelapena] for help with tests (especially with those
executeWithPaging method - it would take me ages to make it working like this).
I also applied your changes (sorry for not applying code-formatting - I just
realized that Intellij config has it out-of-the-box). Here is the PR
[https://github.com/apache/cassandra/pull/1361] (so it will be easier to
comment :) )
once again thanks for all your help ;)
was (Author: bkowalczyyk):
Thanks a lot [~adelapena] for help with tests (especially with those
executeWithPaging method - it would take me ages to make it working like this).
I also applied your changes (sorry for not applying code-formatting - I just
realized that Intellij config has it out-of-the-box). Here is the PR
[https://github.com/apache/cassandra/pull/1361] (so it will be easier to
comment :) )
once again thanks for all your help ;)
> Guardrail for page size
> ---
>
> Key: CASSANDRA-17189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17189
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Attachments: CASSANDRA-17189-trunk.diff
>
>
> Add guardrail limiting the query page size, for example:
> {code}
> # Guardrail to warn about or reject page sizes greater than threshold.
> # The two thresholds default to -1 to disable.
> page_size:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> Initially this can be based on the specified number of rows used as page
> size, although it would be ideal to also limit the actual size in bytes of
> the returned pages.
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on page size in the guardrails
> section of cassandra.yaml.
> # Add a getPageSize method in GuardrailsConfig returning a Threshold.Config
> object
> # Implement that method in GuardrailsOptions, which is the default yaml-based
> implementation of GuardrailsConfig
> # Add a Threshold guardrail named pageSize in Guardrails, using the
> previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails.pageSize#guard method with the page size
> that each query is going to use. The DataLimits#forPaging methods look like
> good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17189) Guardrail for page size
[
https://issues.apache.org/jira/browse/CASSANDRA-17189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459501#comment-17459501
]
Bartlomiej commented on CASSANDRA-17189:
Thanks a lot [~adelapena] for help with tests (especially with those
executeWithPaging method - it would take me ages to make it working like this).
I also applied your changes (sorry for not applying code-formatting - I just
realized that Intellij config has it out-of-the-box). Here is the PR
[https://github.com/apache/cassandra/pull/1361] (so it will be easier to
comment :) )
once again thanks for all your help ;)
> Guardrail for page size
> ---
>
> Key: CASSANDRA-17189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17189
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Attachments: CASSANDRA-17189-trunk.diff
>
>
> Add guardrail limiting the query page size, for example:
> {code}
> # Guardrail to warn about or reject page sizes greater than threshold.
> # The two thresholds default to -1 to disable.
> page_size:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> Initially this can be based on the specified number of rows used as page
> size, although it would be ideal to also limit the actual size in bytes of
> the returned pages.
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on page size in the guardrails
> section of cassandra.yaml.
> # Add a getPageSize method in GuardrailsConfig returning a Threshold.Config
> object
> # Implement that method in GuardrailsOptions, which is the default yaml-based
> implementation of GuardrailsConfig
> # Add a Threshold guardrail named pageSize in Guardrails, using the
> previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails.pageSize#guard method with the page size
> that each query is going to use. The DataLimits#forPaging methods look like
> good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459500#comment-17459500 ] Brandon Williams commented on CASSANDRA-10023: -- Also failed at https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/151/workflows/ed12dd8c-a3d9-4b87-a895-903132502221/jobs/1069 > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Sankalp Kohli >Assignee: Stefan Miklosovic >Priority: Low > Labels: 4.0-feature-freeze-review-requested, lhf > Fix For: 4.1 > > Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, > CASSANDRA-10023.patch > > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459496#comment-17459496 ] Stefan Miklosovic commented on CASSANDRA-10023: --- Interesting, it was just passing locally fine. I guess it is just flaky. > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Sankalp Kohli >Assignee: Stefan Miklosovic >Priority: Low > Labels: 4.0-feature-freeze-review-requested, lhf > Fix For: 4.1 > > Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, > CASSANDRA-10023.patch > > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459496#comment-17459496 ] Stefan Miklosovic edited comment on CASSANDRA-10023 at 12/14/21, 9:24 PM: -- Interesting, it was just passing locally fine. I guess it is just flaky. I ll take a look. was (Author: smiklosovic): Interesting, it was just passing locally fine. I guess it is just flaky. > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Sankalp Kohli >Assignee: Stefan Miklosovic >Priority: Low > Labels: 4.0-feature-freeze-review-requested, lhf > Fix For: 4.1 > > Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, > CASSANDRA-10023.patch > > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17206) Is Cassandra vulnerable to CVE-2021-44228?
[ https://issues.apache.org/jira/browse/CASSANDRA-17206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459477#comment-17459477 ] Honza M commented on CASSANDRA-17206: - Thank you. I see it was even already asked ... [https://lists.apache.org/thread/2rngylxw8bjos6xbo1krp29m9wn2hhdr] ... sorry. Will look better next time. > Is Cassandra vulnerable to CVE-2021-44228? > -- > > Key: CASSANDRA-17206 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17206 > Project: Cassandra > Issue Type: Bug >Reporter: Honza M >Priority: Normal > > Hello, > I'm not sure how/where to ask so this would be stupid if the answer is "no", > but considering the popularity of CVE-2021-44228 bug I would like to ask if > cassandra could be affected and if yes, what version do I need to update to > or what else to do. > Honza -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17206) Is Cassandra vulnerable to CVE-2021-44228?
[ https://issues.apache.org/jira/browse/CASSANDRA-17206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17206: - Resolution: Invalid Status: Resolved (was: Triage Needed) The mailing list (https://cassandra.apache.org/_/community.html) would be a better place to ask in the future, but the good news is that in CASSANDRA-5883 Cassandra switched to logback so this doesn't apply. > Is Cassandra vulnerable to CVE-2021-44228? > -- > > Key: CASSANDRA-17206 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17206 > Project: Cassandra > Issue Type: Bug >Reporter: Honza M >Priority: Normal > > Hello, > I'm not sure how/where to ask so this would be stupid if the answer is "no", > but considering the popularity of CVE-2021-44228 bug I would like to ask if > cassandra could be affected and if yes, what version do I need to update to > or what else to do. > Honza -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17206) Is Cassandra vulnerable to CVE-2021-44228?
Honza M created CASSANDRA-17206: --- Summary: Is Cassandra vulnerable to CVE-2021-44228? Key: CASSANDRA-17206 URL: https://issues.apache.org/jira/browse/CASSANDRA-17206 Project: Cassandra Issue Type: Bug Reporter: Honza M Hello, I'm not sure how/where to ask so this would be stupid if the answer is "no", but considering the popularity of CVE-2021-44228 bug I would like to ask if cassandra could be affected and if yes, what version do I need to update to or what else to do. Honza -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459440#comment-17459440
]
Tibor Repasi commented on CASSANDRA-16378:
--
The additional information has lowered the threshold to attack my first
contribution to Cassandra.
I've added most of the necessary things as described without breaking any unit
tests so far. Linked the PR.
Got stuck with the unit test, which I'd appreciate some hints how I can inject
driver attributes into the session to assert the contents of the virtual table.
Still a question if nodetool would need change to expose the data on the
command line.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (a41cdd6 -> 1dd9f55)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from a41cdd6 Allow column_index_size_in_kb to be configurable through nodetool add aa82e3e Don't clean when enabling FQL via JMX new 1dd9f55 Merge branch 'cassandra-4.0' into trunk 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: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 1dd9f55a60e25822e947f04bc0b1906cb3ec922d Merge: a41cdd6 aa82e3e Author: Brandon Williams AuthorDate: Tue Dec 14 13:36:35 2021 -0600 Merge branch 'cassandra-4.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17121) Allow column_index_size_in_kb to be configurable through nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-17121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17121: -- Fix Version/s: 4.1 Source Control Link: https://github.com/apache/cassandra/commit/a41cdd64b217c451b5576abe2f455eaa7ec1f322 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed into trunk as [a41cdd6|https://github.com/apache/cassandra/commit/a41cdd64b217c451b5576abe2f455eaa7ec1f322] > Allow column_index_size_in_kb to be configurable through nodetool > - > > Key: CASSANDRA-17121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17121 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Fix For: 4.1 > > > Configuring the column_index_size_in_kb setting requires a cassandra.yaml > change and bouncing the instance. > Allowing column_index_size_in_kb to be configurable through nodetool can help > in the operational landscape. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Allow column_index_size_in_kb to be configurable through nodetool
This is an automated email from the ASF dual-hosted git repository.
ycai 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 a41cdd6 Allow column_index_size_in_kb to be configurable through
nodetool
a41cdd6 is described below
commit a41cdd64b217c451b5576abe2f455eaa7ec1f322
Author: Francisco Guerrero
AuthorDate: Tue Dec 14 10:13:59 2021 -0800
Allow column_index_size_in_kb to be configurable through nodetool
patch by Francisco Guerrero; reviewed by Dinesh Joshi, Yifan Cai for
CASSANDRA-17121
---
CHANGES.txt| 1 +
src/java/org/apache/cassandra/config/Config.java | 2 +-
.../cassandra/config/DatabaseDescriptor.java | 1 -
.../apache/cassandra/service/StorageService.java | 12 +++
.../cassandra/service/StorageServiceMBean.java | 5 +
src/java/org/apache/cassandra/tools/NodeProbe.java | 10 ++
src/java/org/apache/cassandra/tools/NodeTool.java | 2 +
.../tools/nodetool/GetColumnIndexSize.java | 33 +++
.../tools/nodetool/SetColumnIndexSize.java | 38 +++
.../tools/nodetool/SetGetColumnIndexSizeTest.java | 110 +
10 files changed, 212 insertions(+), 2 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 1d11bbc..59a9ea4 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Allow column_index_size_in_kb to be configurable through nodetool
(CASSANDRA-17121)
* Emit a metric for number of local read and write calls
* Add non-blocking mode for CDC writes (CASSANDRA-17001)
* Add guardrails framework (CASSANDRA-17147)
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index f08da7a..61aaf3c 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -223,7 +223,7 @@ public class Config
public volatile long snapshot_links_per_second = 0;
/* if the size of columns or super-columns are more than this, indexing
will kick in */
-public int column_index_size_in_kb = 64;
+public volatile int column_index_size_in_kb = 64;
public volatile int column_index_cache_size_in_kb = 2;
public volatile int batch_size_warn_threshold_in_kb = 5;
public volatile int batch_size_fail_threshold_in_kb = 50;
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index fa6276e..fe820cd 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -1513,7 +1513,6 @@ public class DatabaseDescriptor
return conf.column_index_size_in_kb;
}
-@VisibleForTesting
public static void setColumnIndexSize(int val)
{
checkValidForByteConversion(val, "column_index_size_in_kb",
ByteUnit.KIBI_BYTES);
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 8fde79b..8d07784 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -5860,6 +5860,18 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
logger.info("updated
replica_filtering_protection.cached_rows_fail_threshold to {}", threshold);
}
+public int getColumnIndexSizeInKB()
+{
+return DatabaseDescriptor.getColumnIndexSizeInKB();
+}
+
+public void setColumnIndexSize(int columnIndexSizeInKB)
+{
+int oldValueInKB = DatabaseDescriptor.getColumnIndexSizeInKB();
+DatabaseDescriptor.setColumnIndexSize(columnIndexSizeInKB);
+logger.info("Updated column_index_size_in_kb to {} KiB (was {} KiB)",
columnIndexSizeInKB, oldValueInKB);
+}
+
public int getColumnIndexCacheSize()
{
return DatabaseDescriptor.getColumnIndexCacheSizeInKB();
diff --git a/src/java/org/apache/cassandra/service/StorageServiceMBean.java
b/src/java/org/apache/cassandra/service/StorageServiceMBean.java
index ed31e3c..dcc1b1e 100644
--- a/src/java/org/apache/cassandra/service/StorageServiceMBean.java
+++ b/src/java/org/apache/cassandra/service/StorageServiceMBean.java
@@ -767,6 +767,11 @@ public interface StorageServiceMBean extends
NotificationEmitter
/** Sets the number of rows cached at the coordinator before
filtering/index queries fail outright. */
public void setCachedReplicaRowsFailThreshold(int threshold);
+/** Returns the granularity of the collation index of rows within a
partition **/
+public int getColumnIndexSizeInKB();
+/** Sets the granularity of the collation index of rows within a partition
**/
+public void setColumnIndexSize(int columnIndexSizeInKB);
+
/** Returns the threshold
[jira] [Comment Edited] (CASSANDRA-17121) Allow column_index_size_in_kb to be configurable through nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-17121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459417#comment-17459417 ] Yifan Cai edited comment on CASSANDRA-17121 at 12/14/21, 7:27 PM: -- Starting commit CI Results: ||Branch||Source||Circle CI|| |trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17121-trunk-6B730B3E-E12E-4585-A81B-13D4C55EFD62]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17121-trunk-6B730B3E-E12E-4585-A81B-13D4C55EFD62]| CI ran mostly green. Some test failures already have the tracking ticket, e.g. CASSANDRA-17144, CASSANDRA-17133, CASSANDRA-17140 was (Author: yifanc): Starting commit CI Results (pending): ||Branch||Source||Circle CI| |trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17121-trunk-6B730B3E-E12E-4585-A81B-13D4C55EFD62]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17121-trunk-6B730B3E-E12E-4585-A81B-13D4C55EFD62]| > Allow column_index_size_in_kb to be configurable through nodetool > - > > Key: CASSANDRA-17121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17121 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > > Configuring the column_index_size_in_kb setting requires a cassandra.yaml > change and bouncing the instance. > Allowing column_index_size_in_kb to be configurable through nodetool can help > in the operational landscape. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17121) Allow column_index_size_in_kb to be configurable through nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-17121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459417#comment-17459417 ] Yifan Cai commented on CASSANDRA-17121: --- Starting commit CI Results (pending): ||Branch||Source||Circle CI| |trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17121-trunk-6B730B3E-E12E-4585-A81B-13D4C55EFD62]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17121-trunk-6B730B3E-E12E-4585-A81B-13D4C55EFD62]| > Allow column_index_size_in_kb to be configurable through nodetool > - > > Key: CASSANDRA-17121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17121 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > > Configuring the column_index_size_in_kb setting requires a cassandra.yaml > change and bouncing the instance. > Allowing column_index_size_in_kb to be configurable through nodetool can help > in the operational landscape. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459415#comment-17459415 ] Brandon Williams commented on CASSANDRA-11418: -- The current state here is I'm now sure of two things: my patch never worked properly, and our tests around replacing aren't good enough to catch it. > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Assignee: Brandon Williams >Priority: Low > Fix For: 4.x > > Attachments: cassandra-11418-trunk > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459411#comment-17459411 ] Brandon Williams edited comment on CASSANDRA-10023 at 12/14/21, 6:51 PM: - I missed that the circle config for the CI run didn't include a dtest repo, so the added dtests weren't run, and now are failing: https://ci-cassandra.apache.org/job/Cassandra-trunk/880/testReport/dtest.client_request_metrics_local_remote_test/ was (Author: brandon.williams): I missed that the circle config for the CI run didn't include a dtest repo, so the added dtests weren't run, and now failing: https://ci-cassandra.apache.org/job/Cassandra-trunk/880/testReport/dtest.client_request_metrics_local_remote_test/ > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Sankalp Kohli >Assignee: Stefan Miklosovic >Priority: Low > Labels: 4.0-feature-freeze-review-requested, lhf > Fix For: 4.1 > > Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, > CASSANDRA-10023.patch > > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459411#comment-17459411 ] Brandon Williams commented on CASSANDRA-10023: -- I missed that the circle config for the CI run didn't include a dtest repo, so the added dtests weren't run, and now failing: https://ci-cassandra.apache.org/job/Cassandra-trunk/880/testReport/dtest.client_request_metrics_local_remote_test/ > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Sankalp Kohli >Assignee: Stefan Miklosovic >Priority: Low > Labels: 4.0-feature-freeze-review-requested, lhf > Fix For: 4.1 > > Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, > CASSANDRA-10023.patch > > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17205) File leaks will not be be detected and released due to strong self-references in the tidier
[
https://issues.apache.org/jira/browse/CASSANDRA-17205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459409#comment-17459409
]
Josh McKenzie commented on CASSANDRA-17205:
---
One other detail here to call out: this changes from runtime evaluation of
whether there's a Memtable associated with a ColumnFamilyStore to SSTableTidier
time creation. Currently in the codebase we don't create a Tracker w/out a
Memtable in it and then later add it; this functionality straddle is there to
enable both Online and Offline usage of the same infrastructure, so we should
be fine here.
But it's a change.
> File leaks will not be be detected and released due to strong self-references
> in the tidier
> ---
>
> Key: CASSANDRA-17205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17205
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> LogTransaction.SSTableTidier holds a reference to a {{Tracker}} which holds
> references to both a {{ColumnFamilyStore}} and a {{View}}, both of which hold
> refs to SSTableReaders. As per the comment at the top of the SSTableTidier:
> {quote}// must not retain a reference to the SSTableReader, else leak
> detection cannot kick in
> {quote}
> We shouldn't hold a reference to the Tracker here; long running unit tests
> w/-Dcassandra.debugrefcount=true had this pop up.
> {code}ERROR [Strong-Reference-Leak-Detector:1] 2020-10-27T01:10:12,421
> NoSpamLogger.java:97 - Strong self-ref loop detected{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10023) Emit a metric for number of local read and write calls
[ https://issues.apache.org/jira/browse/CASSANDRA-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-10023: - Resolution: (was: Fixed) Status: Open (was: Resolved) > Emit a metric for number of local read and write calls > -- > > Key: CASSANDRA-10023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10023 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Sankalp Kohli >Assignee: Stefan Miklosovic >Priority: Low > Labels: 4.0-feature-freeze-review-requested, lhf > Fix For: 4.1 > > Attachments: 10023-trunk-dtests.txt, 10023-trunk.txt, > CASSANDRA-10023.patch > > > Many C* drivers have feature to be replica aware and chose the co-ordinator > which is a replica. We should add a metric which tells us whether all calls > to the co-ordinator are replica aware. > We have seen issues where client thinks they are replica aware when they > forget to add routing key at various places in the code. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17205) File leaks will not be be detected and released due to strong self-references in the tidier
[
https://issues.apache.org/jira/browse/CASSANDRA-17205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459404#comment-17459404
]
Josh McKenzie edited comment on CASSANDRA-17205 at 12/14/21, 6:42 PM:
--
CI looks good except {{TestClientRequestMetricsLocalRemote}} which look both
new and to be failing on trunk. Thanks
[Butler!|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk]
Going to think for a couple minutes on whether it's worth it to logically tie
this "clear out sstable_activity and clear out {{{}TableMetrics{}}}" action
together or keep it bespoke for the {{Tidier}} here...
Edit: Nope. Literally only used in {{SSTableTidier}}
was (Author: jmckenzie):
CI looks good except {{TestClientRequestMetricsLocalRemote}} which look both
new and to be failing on trunk. Thanks
[Butler!|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk]
Going to think for a couple minutes on whether it's worth it to logically tie
this "clear out sstable_activity and clear out {{TableMetrics}}" action
together or keep it bespoke for the {{Tidier}} here...
> File leaks will not be be detected and released due to strong self-references
> in the tidier
> ---
>
> Key: CASSANDRA-17205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17205
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> LogTransaction.SSTableTidier holds a reference to a {{Tracker}} which holds
> references to both a {{ColumnFamilyStore}} and a {{View}}, both of which hold
> refs to SSTableReaders. As per the comment at the top of the SSTableTidier:
> {quote}// must not retain a reference to the SSTableReader, else leak
> detection cannot kick in
> {quote}
> We shouldn't hold a reference to the Tracker here; long running unit tests
> w/-Dcassandra.debugrefcount=true had this pop up.
> {code}ERROR [Strong-Reference-Leak-Detector:1] 2020-10-27T01:10:12,421
> NoSpamLogger.java:97 - Strong self-ref loop detected{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17205) File leaks will not be be detected and released due to strong self-references in the tidier
[
https://issues.apache.org/jira/browse/CASSANDRA-17205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459404#comment-17459404
]
Josh McKenzie commented on CASSANDRA-17205:
---
CI looks good except {{TestClientRequestMetricsLocalRemote}} which look both
new and to be failing on trunk. Thanks
[Butler!|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk]
Going to think for a couple minutes on whether it's worth it to logically tie
this "clear out sstable_activity and clear out {{TableMetrics}}" action
together or keep it bespoke for the {{Tidier}} here...
> File leaks will not be be detected and released due to strong self-references
> in the tidier
> ---
>
> Key: CASSANDRA-17205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17205
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> LogTransaction.SSTableTidier holds a reference to a {{Tracker}} which holds
> references to both a {{ColumnFamilyStore}} and a {{View}}, both of which hold
> refs to SSTableReaders. As per the comment at the top of the SSTableTidier:
> {quote}// must not retain a reference to the SSTableReader, else leak
> detection cannot kick in
> {quote}
> We shouldn't hold a reference to the Tracker here; long running unit tests
> w/-Dcassandra.debugrefcount=true had this pop up.
> {code}ERROR [Strong-Reference-Leak-Detector:1] 2020-10-27T01:10:12,421
> NoSpamLogger.java:97 - Strong self-ref loop detected{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459379#comment-17459379
]
Benjamin Lerer commented on CASSANDRA-17202:
Yes. Please.
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting on my nerves as it's popping up on my flame graphs all the time.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15005) Configurable whilelist for UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-15005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459375#comment-17459375
]
Benjamin Lerer commented on CASSANDRA-15005:
Introducing a different way of plugging some functions sound like a hack to me
and I am strongly against it. It comes with its new set of problems as suddenly
those function will be considered as native functions belonging to the system
keyspace. Those functions will also be ignored by most backup tools. I would
rather improve the UDF framework or add new native functions.
> Configurable whilelist for UDFs
> ---
>
> Key: CASSANDRA-15005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15005
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Adam Soroka
>Priority: Low
>
> I would like to use the UDF system to distribute some simple calculations on
> values. For some use cases, this would require access only to some Java API
> classes that aren't on the (hardcoded) whitelist (e.g.
> {{java.security.MessageDigest}}). In other cases, it would require access to
> a little non-C* library code, pre-distributed to nodes by out-of-band means.
> As I understand the situation now, the whitelist for types UDFs can use is
> hardcoded in java in
> [UDFunction|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99].]
> This ticket, then, is a request for a facility that would allow that list to
> be extended via some kind of deployment-time configuration. I realize that
> serious security concerns immediately arise for this kind of functionality,
> but I hope that by restricting it (only used during startup, no exposing the
> whitelist for introspection, etc.) it could be quite practical.
> I'd like very much to assist with this ticket if it is accepted. (I believe I
> have sufficient Java skill to do that, but no real familiarity with C*'s
> codebase, yet. :) )
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17019: - Status: Ready to Commit (was: Review In Progress) +1 lgtm > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Yuqi Gu >Priority: Normal > Fix For: 4.1 > > Attachments: UTs_snappy_upgrading.txt, cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-17040:
-
Status: Ready to Commit (was: Review In Progress)
Looks like this resolves issues on M1.
+1 lgtm.
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt, UTs_2.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14684:
---
Labels: lhf (was: )
> Queries with a clause involving tokens and Long.MIN_VALUE include rows
> incorrectly
> --
>
> Key: CASSANDRA-14684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14684
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: George Boyle
>Priority: Low
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> [cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
> When running a CQL query where we filter on a token compared to
> -9223372036854775808 (the minimum value for a long), the filter appears to
> have no effect.
> For example:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
> LIMIT 3;
> system.token(user_id)
> ---
> -9223371814601747988
> -9223371814601747988
> -9223371814601747988
> {code}
> It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
> comparison, the results appear the same.
> In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as
> expected:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) <=
> -9223372036854775807 LIMIT 3;
> system.token(user_id)
> ---
> (0 rows)
> {code}
>
> + Additional information for newcomers:+
> Some checks should be added into {{TokenRestriction}} for the different type
> of restrictions when an invalid value is found.
> The unit tests should be added within {{SelectOrderedPartitionerTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14684:
---
Description:
[cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
When running a CQL query where we filter on a token compared to
-9223372036854775808 (the minimum value for a long), the filter appears to have
no effect.
For example:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
LIMIT 3;
system.token(user_id)
---
-9223371814601747988
-9223371814601747988
-9223371814601747988
{code}
It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
comparison, the results appear the same.
In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as expected:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) <= -9223372036854775807
LIMIT 3;
system.token(user_id)
---
(0 rows)
{code}
+ Additional information for newcomers:+
Some checks should be added into {{TokenRestriction}} for the different type of
restrictions when an invalid value is found.
The unit tests should be added within {{SelectOrderedPartitionerTest}}
was:
[cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
When running a CQL query where we filter on a token compared to
-9223372036854775808 (the minimum value for a long), the filter appears to have
no effect.
For example:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
LIMIT 3;
system.token(user_id)
---
-9223371814601747988
-9223371814601747988
-9223371814601747988
{code}
It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
comparison, the results appear the same.
In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as expected:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) <= -9223372036854775807
LIMIT 3;
system.token(user_id)
---
(0 rows)
{code}
> Queries with a clause involving tokens and Long.MIN_VALUE include rows
> incorrectly
> --
>
> Key: CASSANDRA-14684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14684
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: George Boyle
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> [cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
> When running a CQL query where we filter on a token compared to
> -9223372036854775808 (the minimum value for a long), the filter appears to
> have no effect.
> For example:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
> LIMIT 3;
> system.token(user_id)
> ---
> -9223371814601747988
> -9223371814601747988
> -9223371814601747988
> {code}
> It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
> comparison, the results appear the same.
> In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as
> expected:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) <=
> -9223372036854775807 LIMIT 3;
> system.token(user_id)
> ---
> (0 rows)
> {code}
>
> + Additional information for newcomers:+
> Some checks should be added into {{TokenRestriction}} for the different type
> of restrictions when an invalid value is found.
> The unit tests should be added within {{SelectOrderedPartitionerTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14684:
---
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Discovered By: User Report
Mentor: Benjamin Lerer
Severity: Low (was: Normal)
> Queries with a clause involving tokens and Long.MIN_VALUE include rows
> incorrectly
> --
>
> Key: CASSANDRA-14684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14684
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: George Boyle
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> [cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
> When running a CQL query where we filter on a token compared to
> -9223372036854775808 (the minimum value for a long), the filter appears to
> have no effect.
> For example:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
> LIMIT 3;
> system.token(user_id)
> ---
> -9223371814601747988
> -9223371814601747988
> -9223371814601747988
> {code}
> It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
> comparison, the results appear the same.
> In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as
> expected:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) <=
> -9223372036854775807 LIMIT 3;
> system.token(user_id)
> ---
> (0 rows)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459357#comment-17459357
]
Benjamin Lerer commented on CASSANDRA-14684:
Handling it transparently is probably hard due to the way the code is
structured and might be a bit confusing for the user. Failing the query is the
easiest way in my opinion.
> Queries with a clause involving tokens and Long.MIN_VALUE include rows
> incorrectly
> --
>
> Key: CASSANDRA-14684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14684
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: George Boyle
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> [cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
> When running a CQL query where we filter on a token compared to
> -9223372036854775808 (the minimum value for a long), the filter appears to
> have no effect.
> For example:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
> LIMIT 3;
> system.token(user_id)
> ---
> -9223371814601747988
> -9223371814601747988
> -9223371814601747988
> {code}
> It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
> comparison, the results appear the same.
> In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as
> expected:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) <=
> -9223372036854775807 LIMIT 3;
> system.token(user_id)
> ---
> (0 rows)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17205) File leaks will not be be detected and released due to strong self-references in the tidier
[
https://issues.apache.org/jira/browse/CASSANDRA-17205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17205:
--
Test and Documentation Plan: No new testing or documentation needed;
discovered by existing long-running testing
Status: Patch Available (was: Open)
> File leaks will not be be detected and released due to strong self-references
> in the tidier
> ---
>
> Key: CASSANDRA-17205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17205
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> LogTransaction.SSTableTidier holds a reference to a {{Tracker}} which holds
> references to both a {{ColumnFamilyStore}} and a {{View}}, both of which hold
> refs to SSTableReaders. As per the comment at the top of the SSTableTidier:
> {quote}// must not retain a reference to the SSTableReader, else leak
> detection cannot kick in
> {quote}
> We shouldn't hold a reference to the Tracker here; long running unit tests
> w/-Dcassandra.debugrefcount=true had this pop up.
> {code}ERROR [Strong-Reference-Leak-Detector:1] 2020-10-27T01:10:12,421
> NoSpamLogger.java:97 - Strong self-ref loop detected{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17205) File leaks will not be be detected and released due to strong self-references in the tidier
[
https://issues.apache.org/jira/browse/CASSANDRA-17205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17205:
--
Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear
Impact(13164)
Complexity: Normal
Component/s: Local/SSTable
Discovered By: Unit Test
Severity: Normal
Assignee: Josh McKenzie
Status: Open (was: Triage Needed)
> File leaks will not be be detected and released due to strong self-references
> in the tidier
> ---
>
> Key: CASSANDRA-17205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17205
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> LogTransaction.SSTableTidier holds a reference to a {{Tracker}} which holds
> references to both a {{ColumnFamilyStore}} and a {{View}}, both of which hold
> refs to SSTableReaders. As per the comment at the top of the SSTableTidier:
> {quote}// must not retain a reference to the SSTableReader, else leak
> detection cannot kick in
> {quote}
> We shouldn't hold a reference to the Tracker here; long running unit tests
> w/-Dcassandra.debugrefcount=true had this pop up.
> {code}ERROR [Strong-Reference-Leak-Detector:1] 2020-10-27T01:10:12,421
> NoSpamLogger.java:97 - Strong self-ref loop detected{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17205) File leaks will not be be detected and released due to strong self-references in the tidier
[
https://issues.apache.org/jira/browse/CASSANDRA-17205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459347#comment-17459347
]
Josh McKenzie commented on CASSANDRA-17205:
---
[branch|https://github.com/apache/cassandra/compare/trunk...josh-mckenzie:cassandra-17205?expand=1]
[JDK11
CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/151/workflows/ed12dd8c-a3d9-4b87-a895-903132502221]
Functionally changes in a couple subtle ways:
Before, we'd assess if the {{Tracker}} existed and if the {{ColumnFamilyStore}}
was valid *at time of tidy run*; we instead evaluate now at time of *creation*
of the {{SSTableTidier}}, meaning the {{Tracker}} could go out of scope and be
otherwise nullified before the two operations that relied on its presence for
evaluation.
Those 2 operations are pretty benign however; clearing the {{SSTableReadMeter}}
in {{system.sstable_activity}}, and decrementing the {{totalDiskSpaceUsed}}
metric in the {{ColumnFamilyStore}}. Both operations we should be able to just
try and gracefully fail if the Tracker's no longer active or valid by time of
SSTableTidier run.
Second, we now grab a reference to the totalDiskSpaceUsed Counter inside the
ColumnFamilyStore at time of {{SSTableTidier}} creation instead of at run()
runtime, meaning we could theoretically hold a handle to a metric on a
ColumnFamilyStore that's dropped in the interim. I don't _think_ this should be
a problem; the code around releasing metrics in {{TableMetrics.releaseMetric}}
should still run w/out issue and remove the metric from the top level registry,
we'll just hold a ref to it and operate on the {{LongAdder}} in the {{Counter}}
and then drop the ref to it when the {{SSTableTidier}} gets collected.
So in short: I don't love it and I've commented in the diff around these
subtleties, but it sidesteps the current strong ref loop we have to the Tracker.
Going to give CI a bit to run, make sure things are clean before I find a
reviewer.
> File leaks will not be be detected and released due to strong self-references
> in the tidier
> ---
>
> Key: CASSANDRA-17205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17205
> Project: Cassandra
> Issue Type: Bug
>Reporter: Josh McKenzie
>Priority: Normal
>
> LogTransaction.SSTableTidier holds a reference to a {{Tracker}} which holds
> references to both a {{ColumnFamilyStore}} and a {{View}}, both of which hold
> refs to SSTableReaders. As per the comment at the top of the SSTableTidier:
> {quote}// must not retain a reference to the SSTableReader, else leak
> detection cannot kick in
> {quote}
> We shouldn't hold a reference to the Tracker here; long running unit tests
> w/-Dcassandra.debugrefcount=true had this pop up.
> {code}ERROR [Strong-Reference-Leak-Detector:1] 2020-10-27T01:10:12,421
> NoSpamLogger.java:97 - Strong self-ref loop detected{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi reassigned CASSANDRA-16378:
Assignee: Tibor Repasi
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17205) File leaks will not be be detected and released due to strong self-references in the tidier
Josh McKenzie created CASSANDRA-17205:
-
Summary: File leaks will not be be detected and released due to
strong self-references in the tidier
Key: CASSANDRA-17205
URL: https://issues.apache.org/jira/browse/CASSANDRA-17205
Project: Cassandra
Issue Type: Bug
Reporter: Josh McKenzie
LogTransaction.SSTableTidier holds a reference to a {{Tracker}} which holds
references to both a {{ColumnFamilyStore}} and a {{View}}, both of which hold
refs to SSTableReaders. As per the comment at the top of the SSTableTidier:
{quote}// must not retain a reference to the SSTableReader, else leak detection
cannot kick in
{quote}
We shouldn't hold a reference to the Tracker here; long running unit tests
w/-Dcassandra.debugrefcount=true had this pop up.
{code}ERROR [Strong-Reference-Leak-Detector:1] 2020-10-27T01:10:12,421
NoSpamLogger.java:97 - Strong self-ref loop detected{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17204) Upgrade to Logback 1.2.8 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459250#comment-17459250
]
Brandon Williams commented on CASSANDRA-17204:
--
Moved to improvement since there is no bug affecting this project.
> Upgrade to Logback 1.2.8 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Jochen Schalanda
>Priority: Normal
> Fix For: 4.x
>
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17204) Upgrade to Logback 1.2.8 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17204:
-
Change Category: Operability
Complexity: Low Hanging Fruit
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> Upgrade to Logback 1.2.8 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Jochen Schalanda
>Priority: Normal
> Fix For: 4.x
>
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17204) Upgrade to Logback 1.2.8 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17204:
-
Workflow: Copy of Cassandra Default Workflow (was: Copy of Cassandra Bug
Workflow)
Issue Type: Improvement (was: Bug)
> Upgrade to Logback 1.2.8 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Jochen Schalanda
>Priority: Normal
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17204) Upgrade to Logback 1.2.8 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459247#comment-17459247
]
Brandon Williams commented on CASSANDRA-17204:
--
As discussed on the ML, this does not affect Apache Cassandra but we can
consider it for upgrade.
bq. Therefore and as an additional precaution, in addition to upgrading to
version 1.2.8, we also recommend users to set their logback configuration files
as read-only.
I'm -1 on adding this part since it provides no real protection, only
inconvenience.
> Upgrade to Logback 1.2.8 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Jochen Schalanda
>Priority: Normal
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17204) Upgrade to Logback 1.2.8 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Schalanda updated CASSANDRA-17204:
-
Description:
Logback 1.2.8 has been released with a fix for a potential vulnerability in its
JNDI lookup.
* [http://logback.qos.ch/news.html]
* [https://jira.qos.ch/browse/LOGBACK-1591]
{quote}*14th of December, 2021, Release of version 1.2.8*
We note that the vulnerability mentioned in LOGBACK-1591 requires write access
to logback's configuration file as a prerequisite.
* • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
logback until further notice. This impacts {{ContextJNDISelector}} and
{{}} element in configuration files.
* Also in response to LOGBACK-1591, we have removed all database (JDBC) related
code in the project with no replacement.
We note that the vulnerability mentioned in LOGBACK-1591 requires write access
to logback's configuration file as a prerequisite. A successful RCE requires
all of the following to be true:
* write access to logback.xml
* use of versions < 1.2.8
* reloading of poisoned configuration data, which implies application restart
or scan="true" set prior to attack
Therefore and as an additional precaution, in addition to upgrading to version
1.2.8, we also recommend users to set their logback configuration files as
read-only.
{quote}
This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
probably be fixed anyway.
was:
Logback 1.2.8 has been released with a fix for a potential vulnerability in its
JNDI lookup.
* http://logback.qos.ch/news.html
* https://jira.qos.ch/browse/LOGBACK-1591
{quote}14th of December, 2021, Release of version 1.2.8
We note that the vulnerability mentioned in LOGBACK-1591 requires write access
to logback's configuration file as a prerequisite.
* • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
logback until further notice. This impacts {{ContextJNDISelector}} and
{{}} element in configuration files.
* Also in response to LOGBACK-1591, we have removed all database (JDBC) related
code in the project with no replacement.
We note that the vulnerability mentioned in LOGBACK-1591 requires write access
to logback's configuration file as a prerequisite. A successful RCE requires
all of the following to be true:
* write access to logback.xml
* use of versions < 1.2.8
* reloading of poisoned configuration data, which implies application restart
or scan="true" set prior to attack
Therefore and as an additional precaution, in addition to upgrading to version
1.2.8, we also recommend users to set their logback configuration files as
read-only.
{quote}
This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
probably be fixed anyway.
> Upgrade to Logback 1.2.8 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Jochen Schalanda
>Priority: Normal
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17204) Upgrade to Logback 1.2.8 (security)
Jochen Schalanda created CASSANDRA-17204:
Summary: Upgrade to Logback 1.2.8 (security)
Key: CASSANDRA-17204
URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
Project: Cassandra
Issue Type: Bug
Components: Dependencies
Reporter: Jochen Schalanda
Logback 1.2.8 has been released with a fix for a potential vulnerability in its
JNDI lookup.
* http://logback.qos.ch/news.html
* https://jira.qos.ch/browse/LOGBACK-1591
{quote}14th of December, 2021, Release of version 1.2.8
We note that the vulnerability mentioned in LOGBACK-1591 requires write access
to logback's configuration file as a prerequisite.
* • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
logback until further notice. This impacts {{ContextJNDISelector}} and
{{}} element in configuration files.
* Also in response to LOGBACK-1591, we have removed all database (JDBC) related
code in the project with no replacement.
We note that the vulnerability mentioned in LOGBACK-1591 requires write access
to logback's configuration file as a prerequisite. A successful RCE requires
all of the following to be true:
* write access to logback.xml
* use of versions < 1.2.8
* reloading of poisoned configuration data, which implies application restart
or scan="true" set prior to attack
Therefore and as an additional precaution, in addition to upgrading to version
1.2.8, we also recommend users to set their logback configuration files as
read-only.
{quote}
This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-14684:
Fix Version/s: 3.0.x
3.11.x
4.0.x
4.x
> Queries with a clause involving tokens and Long.MIN_VALUE include rows
> incorrectly
> --
>
> Key: CASSANDRA-14684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14684
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: George Boyle
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> [cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
> When running a CQL query where we filter on a token compared to
> -9223372036854775808 (the minimum value for a long), the filter appears to
> have no effect.
> For example:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
> LIMIT 3;
> system.token(user_id)
> ---
> -9223371814601747988
> -9223371814601747988
> -9223371814601747988
> {code}
> It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
> comparison, the results appear the same.
> In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as
> expected:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) <=
> -9223372036854775807 LIMIT 3;
> system.token(user_id)
> ---
> (0 rows)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16592) The token function in where clause return incorrect data when using token equal condition and Specified a non-exist token value
[
https://issues.apache.org/jira/browse/CASSANDRA-16592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16592:
---
Resolution: Duplicate
Status: Resolved (was: Open)
> The token function in where clause return incorrect data when using token
> equal condition and Specified a non-exist token value
> ---
>
> Key: CASSANDRA-16592
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16592
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: cimon
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> I get incorrect value when use query like 'select Token(pk1,pk2),pk1,pk2 from
> ks.table1 where token(pk1,pk2) = tokenValue'. The returned token value
> mismatch the where condition.
> This problem is reproduced in 3.11.3 and 4.0.
> Here is my schema and select statement
> {code:java}
> // schema
> cqlsh> desc testprefix.cprefix_03 ;CREATE TABLE testprefix.cprefix_03 (
> pk1 int,
> pk2 int,
> ck1 text,
> ck2 text,
> t1 int,
> PRIMARY KEY ((pk1, pk2), ck1, ck2)
> ) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 ASC)
> AND additional_write_policy = '99p'
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND cdc = false
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '16', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND default_time_to_live = 0
> AND extensions = {}
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair = 'BLOCKING'
> AND speculative_retry = '99p';
> {code}
> execute cql query
> {code:java}
> // code placeholder
> cqlsh> SELECT Token(pk1,pk2), pk1,pk2 from testprefix.cprefix_03 WHERE
> token(pk1, pk2) =-9223372036854775808 LIMIT 2;
> system.token(pk1, pk2) | pk1| pk2
> ++-
>-9222849988925915479 | 394560 | 3394560
>-9222849988925915479 | 394560 | 3394560
> (2 rows)
> cqlsh> SELECT Token(pk1,pk2) from testprefix.cprefix_03 where pk1 = 394560
> and pk2 = 3394560 LIMIT 2;
> system.token(pk1, pk2)
>
>-9222849988925915479
>-9222849988925915479
> (2 rows)
> cqlsh> SELECT Token(pk1,pk2), pk1,pk2 from testprefix.cprefix_03 WHERE
> token(pk1, pk2) =-9222849988925915479 LIMIT 2;
> system.token(pk1, pk2) | pk1| pk2
> ++-
>-9222849988925915479 | 394560 | 3394560
>-9222849988925915479 | 394560 | 3394560
> (2 rows){code}
> we can find that token value in the condition are inconsistent with the
> values in the result.
>
> Then review the source code, to seek the anwser.
> {code:java}
> // code placeholder
> private static void addRange(SSTableReader sstable,
> AbstractBounds requested,
> List> boundsList)
> {
> if (requested instanceof Range && ((Range)requested).isWrapAround())
> // first condition
> {
> if (requested.right.compareTo(sstable.first) >= 0)
> {
> // since we wrap, we must contain the whole sstable prior to
> stopKey()
> Boundary left = new
> Boundary(sstable.first, true);
> Boundary right;
> right = requested.rightBoundary();
> right = minRight(right, sstable.last, true);
> if (!isEmpty(left, right))
> boundsList.add(AbstractBounds.bounds(left, right));
> }
> if (requested.left.compareTo(sstable.last) <= 0)
> {
> // since we wrap, we must contain the whole sstable after
> dataRange.startKey()
> Boundary right = new
> Boundary(sstable.last, true);
> Boundary left;
> left = requested.leftBoundary();
> left = maxLeft(left, sstable.first, true); // second condition
> if (!isEmpty(left, right))
> boundsList.add(AbstractBounds.bounds(left, right));
> }
> }
> else
> {
> assert requested.left.compareTo(requested.right) <= 0 ||
> requested.right.isMinimum();
> Boundary left, right;
> left = requested.leftBoundary();
> right = requested.rightBoundary();
> left = maxLeft(left, sstable.first, true);
> // apparently isWrapAround() doesn't count Bounds that extend to the
> limit (min) as
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15458:
---
Description:
h3. Overview
For {{text}} attributes, CQL allows escaping single quote [using additional
single
quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
But applying the same syntax for a {{map}} attribute does not work.
Inconsistent behavior was observed between {{text}} datatype and
{{map}} datatype.
h3. CQL semantic proposal
Cassandra (CQL) should apply same escaping semantics on {{text}} and
text-within-map {{map}} datatypes.
h3. Reproducing the bug:
CREATE query:
{code:java}
CREATE TABLE university.test (id int, data map, PRIMARY KEY
(id));{code}
INSERT query:
{code:java}
insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
On running the aforementioned INSERT query, Cassandra inserts and returns
{{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
h3. Technical details
OS: CentOS 7
Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
Cassandra version: 3.11.5
Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
+Additional information for newcomers:+
The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
unit test should also be added in {{SelectTest}}
was:
h3. Overview
For {{text}} attributes, CQL allows escaping single quote [using additional
single
quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
But applying the same syntax for a {{map}} attribute does not work.
Inconsistent behavior was observed between {{text}} datatype and
{{map}} datatype.
h3. CQL semantic proposal
Cassandra (CQL) should apply same escaping semantics on {{text}} and
text-within-map {{map}} datatypes.
h3. Reproducing the bug:
CREATE query:
{code:java}
CREATE TABLE university.test (id int, data map, PRIMARY KEY
(id));{code}
INSERT query:
{code:java}
insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
On running the aforementioned INSERT query, Cassandra inserts and returns
{{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
h3. Technical details
OS: CentOS 7
Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
Cassandra version: 3.11.5
Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15458:
---
Labels: AdventCalendar2021 lhf (was: )
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15458:
---
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Discovered By: User Report
Mentor: Benjamin Lerer
Severity: Low
Status: Open (was: Triage Needed)
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Priority: Normal
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17202:
---
Status: Review In Progress (was: Needs Committer)
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting on my nerves as it's popping up on my flame graphs all the time.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15215) VIntCoding should read and write more efficiently
[ https://issues.apache.org/jira/browse/CASSANDRA-15215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459045#comment-17459045 ] Aleksandr Sorokoumov commented on CASSANDRA-15215: -- No worries, CQLConnectionTest failures indeed looked suspicious. I agree with your commit and am looking forward to green CI and merge :) > VIntCoding should read and write more efficiently > - > > Key: CASSANDRA-15215 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15215 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction, Local/SSTable >Reporter: Benedict Elliott Smith >Assignee: Aleksandr Sorokoumov >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > Attachments: testWriteRandomLongDOP_final.png, > writeUnsignedVInt_megamorphic_BB.png, writeUnsignedVInt_megamorphic_DOP.png > > Time Spent: 40m > Remaining Estimate: 0h > > Most vints occupy significantly fewer than 8 bytes, and most buffers have >= > 8 bytes spare, in which case we can construct the relevant bytes in a > register and memcpy them to the correct position. Since we read and write a > lot of vints, this waste is probably measurable, particularly during > compaction and flush, and can probably be considered a performance bug. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
