[jira] [Commented] (CASSANDRA-19654) Update bundled Cassandra cassandra-driver-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-19654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848457#comment-17848457 ] Jackson Fleming commented on CASSANDRA-19654: - [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14721] - is the CVE someone has flagged to us, but there's a lot more reported on the maven page for 3.11.0 ([https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core/3.11.0] ) > Update bundled Cassandra cassandra-driver-core dependency > - > > Key: CASSANDRA-19654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19654 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Jackson Fleming >Priority: Normal > > There's a dependency in Cassandra project on an old version of the Java > driver cassandra-driver-core - 3.11.0 in the 4.0 and later releases of > Cassandra > > (For example on the 4.1 branch > [https://github.com/apache/cassandra/blob/cassandra-4.1/build.xml#L691)] > > It appears that this dependency may have some security vulnerabilities in > transitive dependencies. > But also this is a very old version of the driver, ideally it would be > aligned to a newer version, I would suggest either 3.11.5 which is the latest > in that line of driver versions > [https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core|https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core)] > or this gets updated to the latest 4.x driver (as of writing that's 4.18.1 in > [https://mvnrepository.com/artifact/org.apache.cassandra/java-driver-core] ) > but this seems like a larger undertaking. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19654) Update bundled Cassandra cassandra-driver-core dependency
Jackson Fleming created CASSANDRA-19654: --- Summary: Update bundled Cassandra cassandra-driver-core dependency Key: CASSANDRA-19654 URL: https://issues.apache.org/jira/browse/CASSANDRA-19654 Project: Cassandra Issue Type: Task Components: Dependencies Reporter: Jackson Fleming There's a dependency in Cassandra project on an old version of the Java driver cassandra-driver-core - 3.11.0 in the 4.0 and later releases of Cassandra (For example on the 4.1 branch [https://github.com/apache/cassandra/blob/cassandra-4.1/build.xml#L691)] It appears that this dependency may have some security vulnerabilities in transitive dependencies. But also this is a very old version of the driver, ideally it would be aligned to a newer version, I would suggest either 3.11.5 which is the latest in that line of driver versions [https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core|https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core)] or this gets updated to the latest 4.x driver (as of writing that's 4.18.1 in [https://mvnrepository.com/artifact/org.apache.cassandra/java-driver-core] ) but this seems like a larger undertaking. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r69323 - /dev/cassandra/cassandra-java-driver/4.18.1/
Author: absurdfarce Date: Tue May 21 22:36:17 2024 New Revision: 69323 Log: Cassandra Java Driver 4.18.1 Added: dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz (with props) dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz.asc dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz.sha256 dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz.sha512 dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1.tar.gz (with props) dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1.tar.gz.asc dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1.tar.gz.sha256 dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1.tar.gz.sha512 Added: dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz.asc == --- dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz.asc (added) +++ dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz.asc Tue May 21 22:36:17 2024 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEESYqsNUqlyzb6q3YItug6LS5EflYFAmZNHBMACgkQtug6LS5E +flZ8pw//RqqLQANI/ePNeWhA60ADo3iLqhBtTtXCnL2tezrMoPOPDoa+8FlG5S1a +ot8P9w7mM1hvtnDDFVr8QlQqk4khNl7fmBW564kg7j1rFLquQ46amBtAVl1SXnv6 +xR/f3MGbctbWZw/bMOLtxWb+mRZfgT0MF8gS27JVCjcli+Wp49RKRFNI9EMbmNOj +MZocZsbcM9ufLM+2xVwsB1jIJGGwM0qSQ8i5FPiNbp9veqxPfHyPv8A+Fk7yPBgu +7FSWgzD7WlBSprFdgA0xSYeV93i2sToNvX43O8swN5KhxwG/rCnEH17qnduLtJPX +gs1nYQGvb5Hg29N8a8pMWCyMbRtzsjhRkFJzn0jtY7RqwljyoVOx1zoKuPHp2qit +WzWsNjbIgTNlmXMtBNG2AgL8zgKbODr2UNPjmmycGiK6hN2jWFdbjhHH+Mxx8/T2 +k1SacEvv5cAOlYEk0IRPDxr8dwV4NVrZlKgvsEpK6MhUI5Jdxqhfp5APjBchbyil +JUWOYKd0hGv6I/tdQ0GB4RZF+qogbbr8eu/kK6hZKGJ6GFowfTqqwnLVvaCiNpvN +9UbX6tZx3nFpSybGGqVF1BcJOYn5j+FXElz57xLKYB0yLK4W/EW7rCPYjZ7squl9 +FDfEPZLJCN62u7qKz0cihNG5jHGhMl5YceIFdZckf3sVft1zFZI= +=j7Ke +-END PGP SIGNATURE- Added: dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz.sha256 == --- dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz.sha256 (added) +++ dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz.sha256 Tue May 21 22:36:17 2024 @@ -0,0 +1 @@ +b1d67f9283cc52abc234ab8094426b415c4b0896313d0c9cfb5b53458f9062dc apache-cassandra-java-driver-4.18.1-source.tar.gz Added: dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz.sha512 == --- dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz.sha512 (added) +++ dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1-source.tar.gz.sha512 Tue May 21 22:36:17 2024 @@ -0,0 +1 @@ +da18c16e3caf49a39c33ea659ec85279f454225bf5b5b25e411f5d79401d1423ce6fca786389ee3e923bf00bd896330233ed0ea94a0dbb207a7563383ada58df apache-cassandra-java-driver-4.18.1-source.tar.gz Added: dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1.tar.gz.asc == --- dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1.tar.gz.asc (added) +++ dev/cassandra/cassandra-java-driver/4.18.1/apache-cassandra-java-driver-4.18.1.tar.gz.asc Tue May 21 22:36:17 2024 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEESYqsNUqlyzb6q3YItug6LS5EflYFAmZM9xUACgkQtug6LS5E +flaeSQ//SZOOrOcdYDwu1PKzy6Ff/VQjgXBAAos7K4C0I7HudZGZi6XyRFBHHcWf +bIp9oIYL3iJNTwWEoEzekdLLzXyzqxhFks3+MS+5knl1simJWT44tMjIkvQ2peee +JeJzm14jpo1G4myMaUsAKyeTUek+jMmSKrT+25m7RhCQNWlx8
svn commit: r69322 - in /dev/cassandra/cassandra-java-driver: ./ 4.18.1/
Author: absurdfarce Date: Tue May 21 22:18:56 2024 New Revision: 69322 Log: Cassandra Java Driver 4.18.1 Added: dev/cassandra/cassandra-java-driver/ dev/cassandra/cassandra-java-driver/4.18.1/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12864) "commitlog_sync_batch_window_in_ms" parameter is not documented correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-12864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848377#comment-17848377 ] Michael Semb Wever edited comment on CASSANDRA-12864 at 5/21/24 9:29 PM: - In addition, the page has a number of faults that should be corrected: - the default is periodic, - there's an odd '(Default Value: (complex option): ' section (maybe this is just asciidoc ?) - the sentence "Any data written to Cassandra will first be written to a commit log before being written to a memtable." isn't strictly-speaking correct, the commitlog and the memtable happen in parallel… And, it would be worthwhile if the page referenced, for more advanced info, this [blog post|https://cassandra.apache.org/_/blog/Learn-How-CommitLog-Works-in-Apache-Cassandra.html] these pages are now found at - https://cassandra.apache.org/doc/3.11/cassandra/architecture/storage_engine.html#commit-log - https://cassandra.apache.org/doc/4.0/cassandra/architecture/storage_engine.html#commit-log - https://cassandra.apache.org/doc/4.1/cassandra/architecture/storage_engine.html#commit-log - https://cassandra.apache.org/doc/5.0/cassandra/architecture/storage-engine.html - https://cassandra.apache.org/doc/5.1/cassandra/architecture/storage-engine.html - https://cassandra.apache.org/doc/latest/cassandra/architecture/storage-engine.html was (Author: michaelsembwever): In addition, the page has a number of faults that should be corrected: - the default is periodic, - there's an odd '(Default Value: (complex option): ' section (maybe this is just asciidoc ?) - the sentence "Any data written to Cassandra will first be written to a commit log before being written to a memtable." isn't strictly-speaking correct, the commitlog and the memtable happen in parallel… And, it would be worthwhile if the page referenced, for more advanced info, this [blog post|https://cassandra.apache.org/_/blog/Learn-How-CommitLog-Works-in-Apache-Cassandra.html] > "commitlog_sync_batch_window_in_ms" parameter is not documented correctly > - > > Key: CASSANDRA-12864 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12864 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Hiroyuki Yamada >Priority: Normal > > "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in > the latest versions in 2.1.16, 2.2.8 and 3.9. > Here is the way to reproduce the bug. > 1. set the following parameters in cassandra.yaml > * commitlog_sync: batch > * commitlog_sync_batch_window_in_ms: 1 (10s) > 2. issue an insert from cqlsh > 3. it immediately returns instead of waiting for 10 seconds. > Please refer to the communication in the mailing list. > http://www.mail-archive.com/user@cassandra.apache.org/msg49642.html -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18732) Baseline Diagnostic vtables for Accord
[
https://issues.apache.org/jira/browse/CASSANDRA-18732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848391#comment-17848391
]
Caleb Rackliffe commented on CASSANDRA-18732:
-
A quick note on cache stats...
Since CASSANDRA-14572, the JMX "AccordStateCache" metrics have been exposed as
virtual tables automatically. The only new cache stats virtual table in this
patch covers the global {{AccordCommandStore#stateCache}}.
> Baseline Diagnostic vtables for Accord
> --
>
> Key: CASSANDRA-18732
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18732
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: pull-request-available
> Fix For: 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In addition to JMX-based metrics, there are bits of diagnostic information
> for Accord that we should consider exposing through vtables:
> 1.) We should ensure that coordinator-level CQL transactions and the local
> reads and writes they spawn are visible to the existing {{QueriesTable}}
> vtable.
> The first may already just work. We may need to make some tweaks to
> {{TxnNamedRead}} and {{TxnWrite}} for the local operations though.
> ({{CommandStore}} tasks are out of scope here, as they would probably be more
> confusing than useful in {{QueriesTable}}?)
> 2.) A new vtable for pending commands for a key.
> - Disable SELECT */require a partition key
> - Might require partial back-port of stringifying table/partition key from
> Accord to be correct
> - ex. {{SELECT timestamps FROM myawesometable where ks=? and table=? and
> partition_key=?}}
> - Clustering can be the Accord timestamp elements, no further normal columns.
> 3.) A new vtable for command store-specific cache stats
> - Gather via {{Store.execute()}} for correctness.
> - Store id should be partition key (see {{AccordCommandStore}})
> - hits, misses, total (maybe just throw out the keyspaces and coalesce
> ranges?)
> 4.) (Requires [~aweisberg]'s outstanding work) A new vtable for live
> migration state
> - {{TableMigrationState}} could be flattened into a row
> - Is this already persisted? If so, why a new vtable?
> 5.) A vtable to expose {{accord.local.Node#coordinating()}} as a map
> - ex. {{SELECT txn_id, type}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19653) Fix Cassandra 4 build for snakeyaml >= 2.0
Manuel Rojas created CASSANDRA-19653:
Summary: Fix Cassandra 4 build for snakeyaml >= 2.0
Key: CASSANDRA-19653
URL: https://issues.apache.org/jira/browse/CASSANDRA-19653
Project: Cassandra
Issue Type: Bug
Reporter: Manuel Rojas
Hello,
We're trying to build a custom version of cassandra 4.1.4 that fixes some of
the CVEs reported here:
[https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.1.4]
So far the build passes with these upgrades on build.xml dependencies:
|*Name*|*Default version*|*Modified version*|
|slf4j|1.7.25|1.7.36|
|*{color:#00875a}snakeyaml{color}*|*{color:#00875a}1.26{color}*|*{color:#00875a}1.33{color}*|
|jackson-databind|2.13.2.2|2.17.0|
|netty|4.1.58.Final|4.1.109.Final|
|guava|27.0-jre|33.2.0-jre|
|commons-codec|1.9|1.17.0|
We're being asked to bump *snakeyaml* to >= {*}2.0{*}. This causes the build to
fail with:
{code:java}
_build_java:
[echo] Compiling for Java 8...
[javac] Compiling 2138 source files to
/Users/mrojas/git/cassandra/build/classes/main
[javac] Note: Processing compiler hints annotations
[javac] Note: Processing compiler hints annotations
[javac] Note: Writing compiler command file at META-INF/hotspot_compiler
[javac] Note: Done processing compiler hints annotations
[javac]
/Users/mrojas/git/cassandra/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java:226:
error: constructor Composer in class Composer cannot be applied to given types;
[javac] constructor.setComposer(new Composer(null, null)
[javac] ^
[javac] required: Parser,Resolver,LoaderOptions
[javac] found: ,
[javac] reason: actual and formal argument lists differ in length
[javac]
/Users/mrojas/git/cassandra/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java:279:
error: incompatible types: Class cannot be converted to ClassLoader
[javac] super(theRoot, classLoader);
[javac] ^
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends Object from capture of ?
[javac]
/Users/mrojas/git/cassandra/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java:260:
error: constructor Composer in class Composer cannot be applied to given types;
[javac] constructor.setComposer(new Composer(null, null)
[javac] ^
[javac] required: Parser,Resolver,LoaderOptions
[javac] found: ,
[javac] reason: actual and formal argument lists differ in length
[javac]
/Users/mrojas/git/cassandra/src/java/org/apache/cassandra/tools/JMXTool.java:168:
error: constructor Representer in class Representer cannot be applied to given
types;
[javac] Representer representer = new Representer();
[javac] ^
[javac] required: DumperOptions
[javac] found: no arguments
[javac] reason: actual and formal argument lists differ in length
[javac]
/Users/mrojas/git/cassandra/src/java/org/apache/cassandra/tools/JMXTool.java:398:
error: no suitable constructor found for Constructor(no arguments)
[javac] {
[javac] ^
[javac] constructor Constructor.Constructor(LoaderOptions) is not
applicable
[javac] (actual and formal argument lists differ in length)
[javac] constructor Constructor.Constructor(Class,LoaderOptions) is not applicable
[javac] (actual and formal argument lists differ in length)
[javac] constructor
Constructor.Constructor(TypeDescription,LoaderOptions) is not applicable
[javac] (actual and formal argument lists differ in length)
[javac] constructor
Constructor.Constructor(TypeDescription,Collection,LoaderOptions)
is not applicable
[javac] (actual and formal argument lists differ in length)
[javac] constructor Constructor.Constructor(String,LoaderOptions) is
not applicable
[javac] (actual and formal argument lists differ in length)
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] Note: Some messages have been simplified; recompile with
-Xdiags:verbose to get full output
[javac] 5 errorsBUILD FAILED {code}
This is result of running:
{code:java}
➜ cassandra git:(99d9faeef5) ✗ ant realclean
➜ cassandra git:(99d9faeef5) ✗ ant artifacts {code}
Could you please fix build to work with snakeyaml >= 2.0?
Thanks
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cass
[jira] [Commented] (CASSANDRA-12864) "commitlog_sync_batch_window_in_ms" parameter is not documented correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-12864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848377#comment-17848377 ] Michael Semb Wever commented on CASSANDRA-12864: In addition, the page has a number of faults that should be corrected: - the default is periodic, - there's an odd '(Default Value: (complex option): ' section (maybe this is just asciidoc ?) - the sentence "Any data written to Cassandra will first be written to a commit log before being written to a memtable." isn't strictly-speaking correct, the commitlog and the memtable happen in parallel… And, it would be worthwhile if the page referenced, for more advanced info, this [blog post|https://cassandra.apache.org/_/blog/Learn-How-CommitLog-Works-in-Apache-Cassandra.html] > "commitlog_sync_batch_window_in_ms" parameter is not documented correctly > - > > Key: CASSANDRA-12864 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12864 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Hiroyuki Yamada >Priority: Normal > > "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in > the latest versions in 2.1.16, 2.2.8 and 3.9. > Here is the way to reproduce the bug. > 1. set the following parameters in cassandra.yaml > * commitlog_sync: batch > * commitlog_sync_batch_window_in_ms: 1 (10s) > 2. issue an insert from cqlsh > 3. it immediately returns instead of waiting for 10 seconds. > Please refer to the communication in the mailing list. > http://www.mail-archive.com/user@cassandra.apache.org/msg49642.html -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18493) SAI - LIKE prefix/suffix support
[ https://issues.apache.org/jira/browse/CASSANDRA-18493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18493: - Component/s: Feature/SAI (was: Feature/2i Index) > SAI - LIKE prefix/suffix support > > > Key: CASSANDRA-18493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18493 > Project: Cassandra > Issue Type: Epic > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.x > > > This should provide the following functionality: > * LIKE abc% - prefix support > * LIKE %bcd - suffix support > * LIKE ab%cd - prefix/suffix support > Out of scope: > * LIKE %abc% - contains support > The index support for this can broken down as follows (general ideas that are > open to suggestions): > * Prefix support. This can currently be achieved with the existing trie > index but this needs work to make it more performant in coalescing postings. > An alternative approach could be to modify the block balanced tree to support > variable length datatypes. This would make general range queries possible on > variable length types as well as prefix queries. These would benefit from the > auxilary postings present in the balanced tree. > * Suffix support. This will need a reverse index on the values. This allows > a search of the suffix to operate in the same way as a prefix query. There is > no reason why suffix index cannot be built on top of the prefix index with > separate postings for prefix and suffix. We would need to look at the byte > comparable code in order to produce reverse values efficiently that sort > correctly. > * Prefix/Suffix support. This would require separate prefix and suffix index > searches and an intersection on the resulting postings. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18493) SAI - LIKE prefix/suffix support
[ https://issues.apache.org/jira/browse/CASSANDRA-18493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18493: - Description: This should provide the following functionality: * LIKE abc% - prefix support * LIKE %bcd - suffix support * LIKE ab%cd - prefix/suffix support Out of scope: * LIKE %abc% - contains support The index support for this can broken down as follows (general ideas that are open to suggestions): * Prefix support. This can currently be achieved with the existing trie index but this needs work to make it more performant in coalescing postings. An alternative approach could be to modify the block balanced tree to support variable length datatypes. This would make general range queries possible on variable length types as well as prefix queries. These would benefit from the auxilary postings present in the balanced tree. * Suffix support. This will need a reverse index on the values. This allows a search of the suffix to operate in the same way as a prefix query. There is no reason why suffix index cannot be built on top of the prefix index with separate postings for prefix and suffix. We would need to look at the byte comparable code in order to produce reverse values efficiently that sort correctly. * Prefix/Suffix support. This would require separate prefix and suffix index searches and an intersection on the resulting postings. was: This should provide the following functionality: * LIKE abc% - prefix support * LIKE %bcd - suffix support * LIKE %bc% - prefix/suffix support > SAI - LIKE prefix/suffix support > > > Key: CASSANDRA-18493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18493 > Project: Cassandra > Issue Type: Epic > Components: Feature/2i Index >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.x > > > This should provide the following functionality: > * LIKE abc% - prefix support > * LIKE %bcd - suffix support > * LIKE ab%cd - prefix/suffix support > Out of scope: > * LIKE %abc% - contains support > The index support for this can broken down as follows (general ideas that are > open to suggestions): > * Prefix support. This can currently be achieved with the existing trie > index but this needs work to make it more performant in coalescing postings. > An alternative approach could be to modify the block balanced tree to support > variable length datatypes. This would make general range queries possible on > variable length types as well as prefix queries. These would benefit from the > auxilary postings present in the balanced tree. > * Suffix support. This will need a reverse index on the values. This allows > a search of the suffix to operate in the same way as a prefix query. There is > no reason why suffix index cannot be built on top of the prefix index with > separate postings for prefix and suffix. We would need to look at the byte > comparable code in order to produce reverse values efficiently that sort > correctly. > * Prefix/Suffix support. This would require separate prefix and suffix index > searches and an intersection on the resulting postings. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18493) SAI - LIKE prefix/suffix support
[ https://issues.apache.org/jira/browse/CASSANDRA-18493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18493: - Epic Link: CASSANDRA-19224 Issue Type: Epic (was: Improvement) Summary: SAI - LIKE prefix/suffix support (was: Add LIKE prefix/suffix support to SAI) > SAI - LIKE prefix/suffix support > > > Key: CASSANDRA-18493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18493 > Project: Cassandra > Issue Type: Epic > Components: Feature/2i Index >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.x > > > This should provide the following functionality: > * LIKE abc% - prefix support > * LIKE %bcd - suffix support > * LIKE %bc% - prefix/suffix support -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18493) SAI - LIKE prefix/suffix support
[ https://issues.apache.org/jira/browse/CASSANDRA-18493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18493: - Epic Link: (was: CASSANDRA-19224) > SAI - LIKE prefix/suffix support > > > Key: CASSANDRA-18493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18493 > Project: Cassandra > Issue Type: Epic > Components: Feature/2i Index >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.x > > > This should provide the following functionality: > * LIKE abc% - prefix support > * LIKE %bcd - suffix support > * LIKE %bc% - prefix/suffix support -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18493) Add LIKE prefix/suffix support to SAI
[ https://issues.apache.org/jira/browse/CASSANDRA-18493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18493: - Change Category: Operability Complexity: Byzantine Status: Open (was: Triage Needed) > Add LIKE prefix/suffix support to SAI > - > > Key: CASSANDRA-18493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18493 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Mike Adamson >Priority: Normal > Fix For: 5.x > > > This should provide the following functionality: > * LIKE abc% - prefix support > * LIKE %bcd - suffix support > * LIKE %bc% - prefix/suffix support -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorina Poland updated CASSANDRA-19628:
--
Component/s: Legacy/Documentation and Website
(was: Documentation)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.31, 4.0.14, 4.1.6, 5.0-beta2, 5.0, 5.1
>
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12864) "commitlog_sync_batch_window_in_ms" parameter is not documented correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-12864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-12864: -- Component/s: Documentation (was: Legacy/Documentation and Website) > "commitlog_sync_batch_window_in_ms" parameter is not documented correctly > - > > Key: CASSANDRA-12864 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12864 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Hiroyuki Yamada >Priority: Normal > > "commitlog_sync_batch_window_in_ms" doesn't seem to be working at least in > the latest versions in 2.1.16, 2.2.8 and 3.9. > Here is the way to reproduce the bug. > 1. set the following parameters in cassandra.yaml > * commitlog_sync: batch > * commitlog_sync_batch_window_in_ms: 1 (10s) > 2. issue an insert from cqlsh > 3. it immediately returns instead of waiting for 10 seconds. > Please refer to the communication in the mailing list. > http://www.mail-archive.com/user@cassandra.apache.org/msg49642.html -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorina Poland updated CASSANDRA-19628:
--
Component/s: Documentation
(was: Legacy/Documentation and Website)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.31, 4.0.14, 4.1.6, 5.0-beta2, 5.0, 5.1
>
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated CASSANDRA-19651:
Since Version: 4.0 (was: 4.1.0)
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: 19651-4.1.patch
>
>
> org.apache.cassandra.service.AbstractWriteResponseHandler:
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19641) Accord barriers/inclusive sync points cause failures in BurnTest
[ https://issues.apache.org/jira/browse/CASSANDRA-19641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19641: --- Attachment: ci_summary.html > Accord barriers/inclusive sync points cause failures in BurnTest > > > Key: CASSANDRA-19641 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19641 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > Attachments: ci_summary.html > > > The burn test fails almost every run at the moment we found several things to > fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19641) Accord barriers/inclusive sync points cause failures in BurnTest
[ https://issues.apache.org/jira/browse/CASSANDRA-19641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-19641: --- Test and Documentation Plan: Small tweaks to one of the Accord tests, covered by existing simulator tests, going to add checks in AccordMigrationTest that validate that the cache and system table for migrated keys is being correctly populated Status: Patch Available (was: Open) > Accord barriers/inclusive sync points cause failures in BurnTest > > > Key: CASSANDRA-19641 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19641 > Project: Cassandra > Issue Type: Bug > Components: Accord >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > The burn test fails almost every run at the moment we found several things to > fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19652) ShallowInfoRetriever: cache offsets to void resetting of RandomAccessReader buffer
[ https://issues.apache.org/jira/browse/CASSANDRA-19652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19652: - Change Category: Performance Complexity: Normal Status: Open (was: Triage Needed) > ShallowInfoRetriever: cache offsets to void resetting of RandomAccessReader > buffer > -- > > Key: CASSANDRA-19652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19652 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Dmitry Konstantinov >Assignee: Dmitry Konstantinov >Priority: Normal > Fix For: 5.x > > > Currently in > org.apache.cassandra.io.sstable.format.big.RowIndexEntry.ShallowInfoRetriever#fetchIndex > we do 2 seek/read operations: 1st is to find the offset for IndexInfo and > the 2nd to read it. These are two quite distant regions of the file and for > standard disk access mode we do not use a benefit from a buffer in > RandomAccessReader due to jumping between the regions and reseting this > buffer again and again. A possible improvement here can be to read and cache > N first offsets (to limit the amount of memory to use) on the first read and > do later only sequential reads of IndexInfo data. By caching of less than 1Kb > we can reduce the number of syscalls even more, in my case: from few hundred > to less than 10. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19652) ShallowInfoRetriever: cache offsets to void resetting of RandomAccessReader buffer
[ https://issues.apache.org/jira/browse/CASSANDRA-19652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Konstantinov reassigned CASSANDRA-19652: --- Assignee: Dmitry Konstantinov > ShallowInfoRetriever: cache offsets to void resetting of RandomAccessReader > buffer > -- > > Key: CASSANDRA-19652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19652 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Dmitry Konstantinov >Assignee: Dmitry Konstantinov >Priority: Normal > Fix For: 5.x > > > Currently in > org.apache.cassandra.io.sstable.format.big.RowIndexEntry.ShallowInfoRetriever#fetchIndex > we do 2 seek/read operations: 1st is to find the offset for IndexInfo and > the 2nd to read it. These are two quite distant regions of the file and for > standard disk access mode we do not use a benefit from a buffer in > RandomAccessReader due to jumping between the regions and reseting this > buffer again and again. A possible improvement here can be to read and cache > N first offsets (to limit the amount of memory to use) on the first read and > do later only sequential reads of IndexInfo data. By caching of less than 1Kb > we can reduce the number of syscalls even more, in my case: from few hundred > to less than 10. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19652) ShallowInfoRetriever: cache offsets to void resetting of RandomAccessReader buffer
[ https://issues.apache.org/jira/browse/CASSANDRA-19652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Konstantinov updated CASSANDRA-19652: Fix Version/s: 5.x > ShallowInfoRetriever: cache offsets to void resetting of RandomAccessReader > buffer > -- > > Key: CASSANDRA-19652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19652 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Dmitry Konstantinov >Priority: Normal > Fix For: 5.x > > > Currently in > org.apache.cassandra.io.sstable.format.big.RowIndexEntry.ShallowInfoRetriever#fetchIndex > we do 2 seek/read operations: 1st is to find the offset for IndexInfo and > the 2nd to read it. These are two quite distant regions of the file and for > standard disk access mode we do not use a benefit from a buffer in > RandomAccessReader due to jumping between the regions and reseting this > buffer again and again. A possible improvement here can be to read and cache > N first offsets (to limit the amount of memory to use) on the first read and > do later only sequential reads of IndexInfo data. By caching of less than 1Kb > we can reduce the number of syscalls even more, in my case: from few hundred > to less than 10. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19652) ShallowInfoRetriever: cache offsets to void resetting of RandomAccessReader buffer
Dmitry Konstantinov created CASSANDRA-19652: --- Summary: ShallowInfoRetriever: cache offsets to void resetting of RandomAccessReader buffer Key: CASSANDRA-19652 URL: https://issues.apache.org/jira/browse/CASSANDRA-19652 Project: Cassandra Issue Type: Improvement Components: Local/SSTable Reporter: Dmitry Konstantinov Currently in org.apache.cassandra.io.sstable.format.big.RowIndexEntry.ShallowInfoRetriever#fetchIndex we do 2 seek/read operations: 1st is to find the offset for IndexInfo and the 2nd to read it. These are two quite distant regions of the file and for standard disk access mode we do not use a benefit from a buffer in RandomAccessReader due to jumping between the regions and reseting this buffer again and again. A possible improvement here can be to read and cache N first offsets (to limit the amount of memory to use) on the first read and do later only sequential reads of IndexInfo data. By caching of less than 1Kb we can reduce the number of syscalls even more, in my case: from few hundred to less than 10. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov reassigned CASSANDRA-19651:
---
Assignee: Dmitry Konstantinov
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Assignee: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: 19651-4.1.patch
>
>
> org.apache.cassandra.service.AbstractWriteResponseHandler:
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-java-driver) branch 4.x-rerelease deleted (was 69996f9ef)
This is an automated email from the ASF dual-hosted git repository. absurdfarce pushed a change to branch 4.x-rerelease in repository https://gitbox.apache.org/repos/asf/cassandra-java-driver.git was 69996f9ef [maven-release-plugin] prepare release 4.18.1 This change permanently discards the following revisions: discard 69996f9ef [maven-release-plugin] prepare release 4.18.1 discard b24e52ef5 Revert "[maven-release-plugin] prepare release 4.18.1" discard 325dd9d8f Revert "[maven-release-plugin] prepare for next development iteration" - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-java-driver) 02/03: Revert "[maven-release-plugin] prepare release 4.18.1"
This is an automated email from the ASF dual-hosted git repository. absurdfarce pushed a commit to branch 4.x-rerelease in repository https://gitbox.apache.org/repos/asf/cassandra-java-driver.git commit b24e52ef5949c98499e9ee33405a25e500d65e6c Author: absurdfarce AuthorDate: Tue May 21 10:43:19 2024 -0500 Revert "[maven-release-plugin] prepare release 4.18.1" This reverts commit cbdde2878786fa6c4077a21352cbe738875f2106. --- bom/pom.xml | 18 +- core-shaded/pom.xml | 2 +- core/pom.xml | 2 +- distribution-source/pom.xml | 2 +- distribution-tests/pom.xml | 2 +- distribution/pom.xml | 2 +- examples/pom.xml | 2 +- integration-tests/pom.xml| 2 +- mapper-processor/pom.xml | 2 +- mapper-runtime/pom.xml | 2 +- metrics/micrometer/pom.xml | 2 +- metrics/microprofile/pom.xml | 2 +- osgi-tests/pom.xml | 2 +- pom.xml | 4 ++-- query-builder/pom.xml| 2 +- test-infra/pom.xml | 2 +- 16 files changed, 25 insertions(+), 25 deletions(-) diff --git a/bom/pom.xml b/bom/pom.xml index 87920ed98..72e00c483 100644 --- a/bom/pom.xml +++ b/bom/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1 +4.18.1-SNAPSHOT java-driver-bom pom @@ -33,42 +33,42 @@ org.apache.cassandra java-driver-core -4.18.1 +4.18.1-SNAPSHOT org.apache.cassandra java-driver-core-shaded -4.18.1 +4.18.1-SNAPSHOT org.apache.cassandra java-driver-mapper-processor -4.18.1 +4.18.1-SNAPSHOT org.apache.cassandra java-driver-mapper-runtime -4.18.1 +4.18.1-SNAPSHOT org.apache.cassandra java-driver-query-builder -4.18.1 +4.18.1-SNAPSHOT org.apache.cassandra java-driver-test-infra -4.18.1 +4.18.1-SNAPSHOT org.apache.cassandra java-driver-metrics-micrometer -4.18.1 +4.18.1-SNAPSHOT org.apache.cassandra java-driver-metrics-microprofile -4.18.1 +4.18.1-SNAPSHOT com.datastax.oss diff --git a/core-shaded/pom.xml b/core-shaded/pom.xml index 93a74696c..c2768c3a6 100644 --- a/core-shaded/pom.xml +++ b/core-shaded/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1 +4.18.1-SNAPSHOT java-driver-core-shaded Apache Cassandra Java Driver - core with shaded deps diff --git a/core/pom.xml b/core/pom.xml index 59465763c..c54c6b8c6 100644 --- a/core/pom.xml +++ b/core/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1 +4.18.1-SNAPSHOT java-driver-core bundle diff --git a/distribution-source/pom.xml b/distribution-source/pom.xml index dc0cdfd1a..8c4f695af 100644 --- a/distribution-source/pom.xml +++ b/distribution-source/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1 +4.18.1-SNAPSHOT java-driver-distribution-source pom diff --git a/distribution-tests/pom.xml b/distribution-tests/pom.xml index 11a0797b3..099bddba9 100644 --- a/distribution-tests/pom.xml +++ b/distribution-tests/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1 +4.18.1-SNAPSHOT java-driver-distribution-tests Apache Cassandra Java Driver - distribution tests diff --git a/distribution/pom.xml b/distribution/pom.xml index 8bfbeecd8..8933d3f5f 100644 --- a/distribution/pom.xml +++ b/distribution/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1 +4.18.1-SNAPSHOT java-driver-distribution diff --git a/examples/pom.xml b/examples/pom.xml index 0cf0c6389..7e2d7f1b6 100644 --- a/examples/pom.xml +++ b/examples/pom.xml @@ -23,7 +23,7 @@ java-driver-parent org.apache.cassandra -4.18.1 +4.18.1-SNAPSHOT java-driver-examples Apache Cassandra Java Driver - examples. diff --git a/integration-tests/pom.xml b/integration-tests/pom.xml index f867bcce7..5c684e90b 100644 --- a/integration-tests/pom.xml +++ b/integration-tests/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1 +4.18.1-SNAPSHOT java-driver-integration-tests jar diff --git a/mapper-processor/pom.xml b/mapper-processor/pom.xml index 47f816bdc..768327591 100644 --- a/mapper-processor/pom.xml +++ b/mapper-processor/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1 +4.18.1-SNAPSHOT java-driver-mapper-processor Apache Cassandra Java Driver - object mapper processor diff --git a/mapper-runtime/pom.xml b/mapper-runtime/pom.x
(cassandra-java-driver) 01/03: Revert "[maven-release-plugin] prepare for next development iteration"
This is an automated email from the ASF dual-hosted git repository. absurdfarce pushed a commit to branch 4.x-rerelease in repository https://gitbox.apache.org/repos/asf/cassandra-java-driver.git commit 325dd9d8fd151409cff0ea3f871d295fa12df956 Author: absurdfarce AuthorDate: Tue May 21 10:43:00 2024 -0500 Revert "[maven-release-plugin] prepare for next development iteration" This reverts commit db4c8075e11d6dc020552d711c2a2e96dc651ad4. --- bom/pom.xml | 18 +- core-shaded/pom.xml | 2 +- core/pom.xml | 2 +- distribution-source/pom.xml | 2 +- distribution-tests/pom.xml | 2 +- distribution/pom.xml | 2 +- examples/pom.xml | 2 +- integration-tests/pom.xml| 2 +- mapper-processor/pom.xml | 2 +- mapper-runtime/pom.xml | 2 +- metrics/micrometer/pom.xml | 2 +- metrics/microprofile/pom.xml | 2 +- osgi-tests/pom.xml | 2 +- pom.xml | 4 ++-- query-builder/pom.xml| 2 +- test-infra/pom.xml | 2 +- 16 files changed, 25 insertions(+), 25 deletions(-) diff --git a/bom/pom.xml b/bom/pom.xml index 96b7a6ceb..87920ed98 100644 --- a/bom/pom.xml +++ b/bom/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.2-SNAPSHOT +4.18.1 java-driver-bom pom @@ -33,42 +33,42 @@ org.apache.cassandra java-driver-core -4.18.2-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-core-shaded -4.18.2-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-mapper-processor -4.18.2-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-mapper-runtime -4.18.2-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-query-builder -4.18.2-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-test-infra -4.18.2-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-metrics-micrometer -4.18.2-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-metrics-microprofile -4.18.2-SNAPSHOT +4.18.1 com.datastax.oss diff --git a/core-shaded/pom.xml b/core-shaded/pom.xml index 6c139aab1..93a74696c 100644 --- a/core-shaded/pom.xml +++ b/core-shaded/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.2-SNAPSHOT +4.18.1 java-driver-core-shaded Apache Cassandra Java Driver - core with shaded deps diff --git a/core/pom.xml b/core/pom.xml index 33688754f..59465763c 100644 --- a/core/pom.xml +++ b/core/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.2-SNAPSHOT +4.18.1 java-driver-core bundle diff --git a/distribution-source/pom.xml b/distribution-source/pom.xml index ee5b52958..dc0cdfd1a 100644 --- a/distribution-source/pom.xml +++ b/distribution-source/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.2-SNAPSHOT +4.18.1 java-driver-distribution-source pom diff --git a/distribution-tests/pom.xml b/distribution-tests/pom.xml index fafd8c467..11a0797b3 100644 --- a/distribution-tests/pom.xml +++ b/distribution-tests/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.2-SNAPSHOT +4.18.1 java-driver-distribution-tests Apache Cassandra Java Driver - distribution tests diff --git a/distribution/pom.xml b/distribution/pom.xml index dfc406baf..8bfbeecd8 100644 --- a/distribution/pom.xml +++ b/distribution/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.2-SNAPSHOT +4.18.1 java-driver-distribution diff --git a/examples/pom.xml b/examples/pom.xml index a76cc8d2b..0cf0c6389 100644 --- a/examples/pom.xml +++ b/examples/pom.xml @@ -23,7 +23,7 @@ java-driver-parent org.apache.cassandra -4.18.2-SNAPSHOT +4.18.1 java-driver-examples Apache Cassandra Java Driver - examples. diff --git a/integration-tests/pom.xml b/integration-tests/pom.xml index 32cabdb34..f867bcce7 100644 --- a/integration-tests/pom.xml +++ b/integration-tests/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.2-SNAPSHOT +4.18.1 java-driver-integration-tests jar diff --git a/mapper-processor/pom.xml b/mapper-processor/pom.xml index 61906f419..47f816bdc 100644 --- a/mapper-processor/pom.xml +++ b/mapper-processor/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.2-SNAPSHOT +4.18.1 java-driver-mapper-processor Apache Cassandra Java Driver - object mapper processor diff --git a/mapper-runtime/pom.xml b/mapp
(cassandra-java-driver) branch 4.x-rerelease created (now 69996f9ef)
This is an automated email from the ASF dual-hosted git repository. absurdfarce pushed a change to branch 4.x-rerelease in repository https://gitbox.apache.org/repos/asf/cassandra-java-driver.git at 69996f9ef [maven-release-plugin] prepare release 4.18.1 This branch includes the following new commits: new 325dd9d8f Revert "[maven-release-plugin] prepare for next development iteration" new b24e52ef5 Revert "[maven-release-plugin] prepare release 4.18.1" new 69996f9ef [maven-release-plugin] prepare release 4.18.1 The 3 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-java-driver) 03/03: [maven-release-plugin] prepare release 4.18.1
This is an automated email from the ASF dual-hosted git repository. absurdfarce pushed a commit to branch 4.x-rerelease in repository https://gitbox.apache.org/repos/asf/cassandra-java-driver.git commit 69996f9efafe6b9865e6c3fa5740bff848a4a8ec Author: absurdfarce AuthorDate: Tue May 21 10:45:56 2024 -0500 [maven-release-plugin] prepare release 4.18.1 --- bom/pom.xml | 18 +- core-shaded/pom.xml | 2 +- core/pom.xml | 2 +- distribution-source/pom.xml | 2 +- distribution-tests/pom.xml | 2 +- distribution/pom.xml | 2 +- examples/pom.xml | 2 +- integration-tests/pom.xml| 2 +- mapper-processor/pom.xml | 2 +- mapper-runtime/pom.xml | 2 +- metrics/micrometer/pom.xml | 2 +- metrics/microprofile/pom.xml | 2 +- osgi-tests/pom.xml | 2 +- pom.xml | 4 ++-- query-builder/pom.xml| 2 +- test-infra/pom.xml | 2 +- 16 files changed, 25 insertions(+), 25 deletions(-) diff --git a/bom/pom.xml b/bom/pom.xml index 72e00c483..87920ed98 100644 --- a/bom/pom.xml +++ b/bom/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1-SNAPSHOT +4.18.1 java-driver-bom pom @@ -33,42 +33,42 @@ org.apache.cassandra java-driver-core -4.18.1-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-core-shaded -4.18.1-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-mapper-processor -4.18.1-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-mapper-runtime -4.18.1-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-query-builder -4.18.1-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-test-infra -4.18.1-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-metrics-micrometer -4.18.1-SNAPSHOT +4.18.1 org.apache.cassandra java-driver-metrics-microprofile -4.18.1-SNAPSHOT +4.18.1 com.datastax.oss diff --git a/core-shaded/pom.xml b/core-shaded/pom.xml index c2768c3a6..93a74696c 100644 --- a/core-shaded/pom.xml +++ b/core-shaded/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1-SNAPSHOT +4.18.1 java-driver-core-shaded Apache Cassandra Java Driver - core with shaded deps diff --git a/core/pom.xml b/core/pom.xml index c54c6b8c6..59465763c 100644 --- a/core/pom.xml +++ b/core/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1-SNAPSHOT +4.18.1 java-driver-core bundle diff --git a/distribution-source/pom.xml b/distribution-source/pom.xml index 8c4f695af..dc0cdfd1a 100644 --- a/distribution-source/pom.xml +++ b/distribution-source/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1-SNAPSHOT +4.18.1 java-driver-distribution-source pom diff --git a/distribution-tests/pom.xml b/distribution-tests/pom.xml index 099bddba9..11a0797b3 100644 --- a/distribution-tests/pom.xml +++ b/distribution-tests/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1-SNAPSHOT +4.18.1 java-driver-distribution-tests Apache Cassandra Java Driver - distribution tests diff --git a/distribution/pom.xml b/distribution/pom.xml index 8933d3f5f..8bfbeecd8 100644 --- a/distribution/pom.xml +++ b/distribution/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1-SNAPSHOT +4.18.1 java-driver-distribution diff --git a/examples/pom.xml b/examples/pom.xml index 7e2d7f1b6..0cf0c6389 100644 --- a/examples/pom.xml +++ b/examples/pom.xml @@ -23,7 +23,7 @@ java-driver-parent org.apache.cassandra -4.18.1-SNAPSHOT +4.18.1 java-driver-examples Apache Cassandra Java Driver - examples. diff --git a/integration-tests/pom.xml b/integration-tests/pom.xml index 5c684e90b..f867bcce7 100644 --- a/integration-tests/pom.xml +++ b/integration-tests/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1-SNAPSHOT +4.18.1 java-driver-integration-tests jar diff --git a/mapper-processor/pom.xml b/mapper-processor/pom.xml index 768327591..47f816bdc 100644 --- a/mapper-processor/pom.xml +++ b/mapper-processor/pom.xml @@ -23,7 +23,7 @@ org.apache.cassandra java-driver-parent -4.18.1-SNAPSHOT +4.18.1 java-driver-mapper-processor Apache Cassandra Java Driver - object mapper processor diff --git a/mapper-runtime/pom.xml b/mapper-runtime/pom.xml index 95ead75dd..ca3a27367 100644 --- a/mapper-runtime/pom.xml +++ b/mapper-r
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated CASSANDRA-19651:
Description:
org.apache.cassandra.service.AbstractWriteResponseHandler:
{code:java}
private final void decrementResponseOrExpired()
{
int decrementedValue = responsesAndExpirations.decrementAndGet();
if (decrementedValue == 0)
{
// The condition being signaled is a valid proxy for the CL being
achieved
// Only mark it as failed if the requested CL was achieved.
if (!condition.isSignalled() && requestedCLAchieved)
{
replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
}
else
{
replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
queryStartNanoTime);
}
}
} {code}
Actual result: responsesAndExpirations is a total number of replicas across all
DCs which does not depend on the ideal CL, so the metric value for
replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
latest response/timeout for all replicas.
Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
when we get enough responses from replicas according to the ideal CL.
was:
{code:java}
private final void decrementResponseOrExpired()
{
int decrementedValue = responsesAndExpirations.decrementAndGet();
if (decrementedValue == 0)
{
// The condition being signaled is a valid proxy for the CL being
achieved
// Only mark it as failed if the requested CL was achieved.
if (!condition.isSignalled() && requestedCLAchieved)
{
replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
}
else
{
replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
queryStartNanoTime);
}
}
} {code}
Actual result: responsesAndExpirations is a total number of replicas across all
DCs which does not depend on the ideal CL, so the metric value for
replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
latest response/timeout for all replicas.
Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
when we get enough responses from replicas according to the ideal CL.
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: 19651-4.1.patch
>
>
> org.apache.cassandra.service.AbstractWriteResponseHandler:
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848235#comment-17848235
]
Dmitry Konstantinov edited comment on CASSANDRA-19651 at 5/21/24 2:56 PM:
--
Please find the patch for 4.1 branch attached: [^19651-4.1.patch]
was (Author: dnk):
I am going to attach a patch with a fix soon.
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: 19651-4.1.patch
>
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated CASSANDRA-19651:
Attachment: 19651-4.1.patch
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: 19651-4.1.patch
>
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848235#comment-17848235
]
Dmitry Konstantinov commented on CASSANDRA-19651:
-
I am going to attach a patch with a fix soon.
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19651:
-
Fix Version/s: 5.0.x
5.x
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19651:
-
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Component/s: Legacy/Observability
Severity: Normal
Status: Open (was: Triage Needed)
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x
>
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19651:
-
Fix Version/s: 4.1.x
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x
>
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated CASSANDRA-19651:
Discovered By: User Report
Since Version: 4.1.0
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dmitry Konstantinov
>Priority: Normal
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
Dmitry Konstantinov created CASSANDRA-19651:
---
Summary: idealCLWriteLatency metric reports the worst response
time instead of the time when ideal CL is satisfied
Key: CASSANDRA-19651
URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
Project: Cassandra
Issue Type: Bug
Reporter: Dmitry Konstantinov
{code:java}
private final void decrementResponseOrExpired()
{
int decrementedValue = responsesAndExpirations.decrementAndGet();
if (decrementedValue == 0)
{
// The condition being signaled is a valid proxy for the CL being
achieved
// Only mark it as failed if the requested CL was achieved.
if (!condition.isSignalled() && requestedCLAchieved)
{
replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
}
else
{
replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
queryStartNanoTime);
}
}
} {code}
Actual result: responsesAndExpirations is a total number of replicas across all
DCs which does not depend on the ideal CL, so the metric value for
replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
latest response/timeout for all replicas.
Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] Annotate BatchStatement methods with CheckReturnValue [cassandra-java-driver]
lukasz-antoniak commented on PR #1607:
URL:
https://github.com/apache/cassandra-java-driver/pull/1607#issuecomment-2122499865
Shall we also add `@CheckReturnValue` to `Statement#setNowInSeconds(int)`?
All Implementations are immutable and create new object.
```java
@NonNull
@SuppressWarnings("unchecked")
default SelfT setNowInSeconds(int nowInSeconds) {
return (SelfT) this;
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19593) Transactional Guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-19593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848171#comment-17848171
]
Stefan Miklosovic edited comment on CASSANDRA-19593 at 5/21/24 11:45 AM:
-
Progress:
I finished all transformations (Flags, Values, Thresholds, Customs) (Custom is
a custom guardrail as per CEP-24). I have also tested ser/de of these
transformations, there are tests for vtables and diffing of transformations as
well.
I have also started to validate the input in vtables before it is committed to
TCM. That means that no invalid configuration (e.g. warn threshold bigger than
fail threshold) will be committed when CQL statement against such vtables is
executed. Validations are done per each logical guardrail category if
applicable.
It is worth to say that from the implementation perspective, Values (related to
values guardrail) are rather special when it comes to CQL.
If we want to have this table
{code:java}
VIRTUAL TABLE system_guardrails.values (
name text PRIMARY KEY,
disallowed frozen>,
ignored frozen>,
warned frozen>
) {code}
when we do this query:
{code:java}
update system_guardrails.values set warned = {'QUORUM'}, disallowed =
{'EACH_QUORUM'} WHERE name = 'read_consistency_levels'; {code}
the way how it works until now is that each value for respective column will
come to
AbstractMutableVirtualTable#applyColumnUpdate. But, think about that, if we
have two columns modified, as in the above example, that would translate to two
separate commits into TCM, just because mutable vtable iterates over such
columns.
I do not think this is desirable, there should be one commit per query,
basically. So the transformation might contain more than one column.
In order to do that, I had to override "apply" method in
AbstractMutableVirtualTable and I had to remove "final" modifier. This was
already discussed with [~blerer] that it might be possible to remove that in
order to accommodate this kind of situations.
Also, I am making sure that I am not committing something which has not
changed. E.g. when I execute above query twice, it will be actually committed
just once, because for the second time, when diffing it, there is no
difference, hence no commit is necessary. This was quite tricky to get right,
especially for values, because I wanted to model the situation when we are
removing the value by setting it to null, like this:
{code:java}
update system_guardrails.values set warned = null, disallowed = {} WHERE name =
'read_consistency_levels'; {code}
"null" and "empty" are two different operations in terms of mutable vtable. If
it is set to null, it is looked at as if we are going to delete but if it is an
empty set, it is a regular update. This was tricky to get right too but I think
I am there.
was (Author: smiklosovic):
Progress:
I finished all transformations (Flags, Values, Thresholds, Customs) (Custom is
a custom guardrail as per CEP-24). I have also tested ser/de of these
transformations, there are tests for vtables and diffing of transformations as
well.
I have also started to validate the input in vtables before it is committed to
TCM. That means that no invalid configuration (e.g. warn threshold bigger than
fail threshold) will be committed when CQL statement against such vtables is
executed. Validations are done per each logical guardrail category if
applicable.
> Transactional Guardrails
>
>
> Key: CASSANDRA-19593
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19593
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails, Transactional Cluster Metadata
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I think it is time to start to think about this more seriously. TCM is
> getting into pretty nice shape and we might start to investigate how to do
> this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19593) Transactional Guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-19593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848171#comment-17848171 ] Stefan Miklosovic commented on CASSANDRA-19593: --- Progress: I finished all transformations (Flags, Values, Thresholds, Customs) (Custom is a custom guardrail as per CEP-24). I have also tested ser/de of these transformations, there are tests for vtables and diffing of transformations as well. I have also started to validate the input in vtables before it is committed to TCM. That means that no invalid configuration (e.g. warn threshold bigger than fail threshold) will be committed when CQL statement against such vtables is executed. Validations are done per each logical guardrail category if applicable. > Transactional Guardrails > > > Key: CASSANDRA-19593 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19593 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails, Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > I think it is time to start to think about this more seriously. TCM is > getting into pretty nice shape and we might start to investigate how to do > this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] JAVA-3057 Allow decoding a UDT that has more fields than expected [cassandra-java-driver]
lukasz-antoniak commented on PR #1635:
URL:
https://github.com/apache/cassandra-java-driver/pull/1635#issuecomment-2122314815
I've had hard time trying to replicate this issue. Attempts to ignore schema
updates on control connection did not replicate the problem. In fact,
`DefaultCodecRegistry` will always attempt to create new codec if it does not
find corresponding one in the cache
([source](https://github.com/apache/cassandra-java-driver/blob/4.x/core/src/main/java/com/datastax/oss/driver/internal/core/type/codec/registry/DefaultCodecRegistry.java#L97)).
Cache key takes into account UDT name, but also names and types of fields.
This triggered my attention to the way application attempts to read UDT from
row. Leveraging `row.getUdtValue(...)` will again register new codec
([source](https://github.com/apache/cassandra-java-driver/blob/4.x/core/src/main/java/com/datastax/oss/driver/api/core/data/GettableByIndex.java#L128)).
However, trying to read the data with given `UdtCodec` will indeed expose the
issue. Since there is a public API method to read the column using certain
codec, I think that this issue is valid.
Below is the integration test that exposes the problem. Shall we add it to
the PR?
```java
/**
* @jira_ticket JAVA-3057
*/
@Test
public void should_decoding_udt_be_backward_compatible() {
CqlSession session = sessionRule.session();
session.execute("CREATE TYPE test_type_1 (a text, b int)");
session.execute("CREATE TABLE test_table_1 (e int primary key, f
frozen)");
// insert a row using version 1 of the UDT schema
session.execute("INSERT INTO test_table_1(e, f) VALUES(1, {a: 'a', b:
1})");
UserDefinedType udt = session
.getMetadata()
.getKeyspace(sessionRule.keyspace())
.flatMap(ks -> ks.getUserDefinedType("test_type_1"))
.orElseThrow(IllegalStateException::new);
TypeCodec oldCodec =
session.getContext().getCodecRegistry().codecFor(udt);
// update UDT schema
session.execute("ALTER TYPE test_type_1 add i text");
// insert a row using version 2 of the UDT schema
session.execute("INSERT INTO test_table_1(e, f) VALUES(2, {a: 'b', b: 2,
i: 'b'})");
Row row = session.execute("SELECT f FROM test_table_1 WHERE e = ?",
2).one();
// Try to read new row with old codec. Using row.getUdtValue() would not
cause any issues,
// because new codec will be automatically registered (using all 3
attributes).
// If application leverages generic row.get(String, Codec) method, data
reading with old codec should
// be backward-compatible.
UdtValue value = (UdtValue) row.get("f", oldCodec);
assertThat(value.getString("a")).isEqualTo("b");
assertThat(value.getInt("b")).isEqualTo(2);
assertThatThrownBy(() -> value.getString("i")).hasMessage("i is not a
field in this UDT");
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-website) branch asf-staging updated (1044bb609 -> 0efa1889d)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git omit 1044bb609 generate docs for 707ddcb3 new 0efa1889d generate docs for 707ddcb3 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (1044bb609) \ N -- N -- N refs/heads/asf-staging (0efa1889d) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4883646 -> 4883646 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19650:
---
Reviewers: Michael Semb Wever, Michael Semb Wever
Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever)
Status: Review In Progress (was: Patch Available)
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: NA
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19650:
--
Test and Documentation Plan: manual test
Status: Patch Available (was: Open)
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: NA
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19650) CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19650:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Low Hanging Fruit
Discovered By: User Report
Fix Version/s: NA
Severity: Low
Status: Open (was: Triage Needed)
> CCM wrongly interprets CASSANDRA_USE_JDK11 for Cassandra 4.x
>
>
> Key: CASSANDRA-19650
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19650
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/dtest/python
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: NA
>
>
> CCM interprets {{CASSANDRA_USE_JDK11}} only by its existence in the
> environment rather than by its actual value (true/false).
> I can see two solutions:
> - make it interpret {{CASSANDRA_USE_JDK11}} properly
> - do not take into account {{CASSANDRA_USE_JDK11}} in the current env and set
> it or unset it automatically when starting a node basing on which Java
> version was selected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
