[cassandra-website] branch asf-staging updated (b26d8479 -> 62906e61)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard b26d8479 generate docs for 52f24b20 new 62906e61 generate docs for 52f24b20 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 (b26d8479) \ N -- N -- N refs/heads/asf-staging (62906e61) 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 4796900 -> 4796900 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15803) Separate out allow filtering scanning through a partition versus scanning over the table
[
https://issues.apache.org/jira/browse/CASSANDRA-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717514#comment-17717514
]
Benjamin Lerer commented on CASSANDRA-15803:
I realized that my previous comment was confusing and simply wrong on some
parts. The problem of trying to do too much multi-tasking. So I want to have
another round at it ;-)
When I mentioned row filtering I was thinking at things like {{CONTAINS}} or
{{CONTAINS KEY}} that can pottentially have to go through a large collections
but we do not use AF for that so please ignore my over-heating brain.
For me {{ALLOW FILTERING}} is wrong at multiple level. The idea behind SQL was
a separation of concerns a user could ask for some data and it is up to the
database system to return them in the most efficient way. Which could be
through filtering (scan) if it was the most cost efficient thing. Like the
query that [~smiklosovic] mentioned. Filtering is not necessary bad in itself,
which is I believe what [~jeromatron] has been trying to raise here.
> Separate out allow filtering scanning through a partition versus scanning
> over the table
>
>
> Key: CASSANDRA-15803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15803
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Jeremy Hanna
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Currently allow filtering can mean two things in the spirit of "avoid
> operations that don't seek to a specific row or sequential rows of data."
> First, it can mean scanning across the entire table to meet the criteria of
> the query. That's almost always a bad thing and should be discouraged or
> disabled (see CASSANDRA-8303). Second, it can mean filtering within a
> specific partition. For example, in a query you could specify the full
> partition key and if you specify a criterion on a non-key field, it requires
> allow filtering.
> The second reason to require allow filtering is significantly less work to
> scan through a partition. It is still extra work over seeking to a specific
> row and getting N sequential rows though. So while an application developer
> and/or operator needs to be cautious about this second type, it's not
> necessarily a bad thing, depending on the table and the use case.
> I propose that we separate the way to specify allow filtering across an
> entire table from specifying allow filtering across a partition in a
> backwards compatible way. One idea that was brought up in Slack in the
> cassandra-dev room was to have allow filtering mean the superset - scanning
> across the table. Then if you want to specify that you *only* want to scan
> within a partition you would use something like
> {{ALLOW FILTERING [WITHIN PARTITION]}}
> So it will succeed if you specify non-key criteria within a single partition,
> but fail with a message to say it requires the full allow filtering. This
> would allow for a backwards compatible full allow filtering while allowing a
> user to specify that they want to just scan within a partition, but error out
> if trying to scan a full table.
> This is potentially also related to the capability limitation framework by
> which operators could more granularly specify what features are allowed or
> disallowed per user, discussed in CASSANDRA-8303. This way an operator could
> disallow the more general allow filtering while allowing the partition scan
> (or disallow them both at their discretion).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15803) Separate out allow filtering scanning through a partition versus scanning over the table
[
https://issues.apache.org/jira/browse/CASSANDRA-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717514#comment-17717514
]
Benjamin Lerer edited comment on CASSANDRA-15803 at 4/28/23 8:18 AM:
-
I realized that my previous comment was confusing and simply wrong on some
parts. The problem of trying to do too much multi-tasking. So I want to have
another round at it ;-)
When I mentioned row filtering I was thinking at things like {{CONTAINS}} or
{{CONTAINS KEY}} that can pottentially have to go through a large collections
but we do not use AF for that so please ignore my over-heating brain.
For me {{ALLOW FILTERING}} is wrong at multiple level. The idea behind SQL was
a separation of concerns a user could ask for some data and it is up to the
database system to return them in the most efficient way. Which could be
through filtering (scan) if it was the most cost efficient thing. Like the
query that [~smiklosovic] mentioned. Filtering is not necessary bad in itself,
which is I believe what [~jeromatron] has been trying to raise here.
Cassandra does not have a proper query optimizer yet (it is one thing I believe
will change soon) but if it had something like AF would not make sense at the
query level anymore because a user will be less efficient than a proper
optimizer at picking up the best access pattern. At this point we might still
want to be able to configure some safety nets but that will be an operator
level decision about what they believe is acceptable or not. I am not
advocating for removing AF at this point only when we will have a proper
optimizer.
was (Author: blerer):
I realized that my previous comment was confusing and simply wrong on some
parts. The problem of trying to do too much multi-tasking. So I want to have
another round at it ;-)
When I mentioned row filtering I was thinking at things like {{CONTAINS}} or
{{CONTAINS KEY}} that can pottentially have to go through a large collections
but we do not use AF for that so please ignore my over-heating brain.
For me {{ALLOW FILTERING}} is wrong at multiple level. The idea behind SQL was
a separation of concerns a user could ask for some data and it is up to the
database system to return them in the most efficient way. Which could be
through filtering (scan) if it was the most cost efficient thing. Like the
query that [~smiklosovic] mentioned. Filtering is not necessary bad in itself,
which is I believe what [~jeromatron] has been trying to raise here.
> Separate out allow filtering scanning through a partition versus scanning
> over the table
>
>
> Key: CASSANDRA-15803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15803
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Jeremy Hanna
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Currently allow filtering can mean two things in the spirit of "avoid
> operations that don't seek to a specific row or sequential rows of data."
> First, it can mean scanning across the entire table to meet the criteria of
> the query. That's almost always a bad thing and should be discouraged or
> disabled (see CASSANDRA-8303). Second, it can mean filtering within a
> specific partition. For example, in a query you could specify the full
> partition key and if you specify a criterion on a non-key field, it requires
> allow filtering.
> The second reason to require allow filtering is significantly less work to
> scan through a partition. It is still extra work over seeking to a specific
> row and getting N sequential rows though. So while an application developer
> and/or operator needs to be cautious about this second type, it's not
> necessarily a bad thing, depending on the table and the use case.
> I propose that we separate the way to specify allow filtering across an
> entire table from specifying allow filtering across a partition in a
> backwards compatible way. One idea that was brought up in Slack in the
> cassandra-dev room was to have allow filtering mean the superset - scanning
> across the table. Then if you want to specify that you *only* want to scan
> within a partition you would use something like
> {{ALLOW FILTERING [WITHIN PARTITION]}}
> So it will succeed if you specify non-key criteria within a single partition,
> but fail with a message to say it requires the full allow filtering. This
> would allow for a backwards compatible full allow filtering while allowing a
> user to specify that they want to just scan within a partition, but error out
> if trying to scan a full table.
> This is potentially also related to the capability limitation framework by
> which operators could mo
[jira] [Comment Edited] (CASSANDRA-15803) Separate out allow filtering scanning through a partition versus scanning over the table
[
https://issues.apache.org/jira/browse/CASSANDRA-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717514#comment-17717514
]
Benjamin Lerer edited comment on CASSANDRA-15803 at 4/28/23 8:19 AM:
-
I realized that my previous comment was confusing and simply wrong on some
parts. The problem of trying to do too much multi-tasking. So I want to have
another round at it ;-)
When I mentioned row filtering I was thinking at things like {{CONTAINS}} or
{{CONTAINS KEY}} that can pottentially have to go through a large collections
but we do not use AF for that so please ignore my over-heating brain.
For me {{ALLOW FILTERING}} is wrong at multiple level. The idea behind SQL was
a separation of concerns a user could ask for some data and it is up to the
database system to return them in the most efficient way. Which could be
through filtering (scan) if it was the most cost efficient thing. Like the
query that [~smiklosovic] mentioned. Filtering is not necessary bad in itself,
which is I believe is what [~jeromatron] has been trying to raise here.
Cassandra does not have a proper query optimizer yet (it is one thing I believe
will change soon) but if it had one, something like AF would not make sense at
the query level anymore because a user will be less efficient than a proper
optimizer at picking up the best access pattern. At this point we might still
want to be able to configure some safety nets but that will be an operator
level decision about what they believe is acceptable or not. I am not
advocating for removing AF at this point. Only when we will have a proper
optimizer.
was (Author: blerer):
I realized that my previous comment was confusing and simply wrong on some
parts. The problem of trying to do too much multi-tasking. So I want to have
another round at it ;-)
When I mentioned row filtering I was thinking at things like {{CONTAINS}} or
{{CONTAINS KEY}} that can pottentially have to go through a large collections
but we do not use AF for that so please ignore my over-heating brain.
For me {{ALLOW FILTERING}} is wrong at multiple level. The idea behind SQL was
a separation of concerns a user could ask for some data and it is up to the
database system to return them in the most efficient way. Which could be
through filtering (scan) if it was the most cost efficient thing. Like the
query that [~smiklosovic] mentioned. Filtering is not necessary bad in itself,
which is I believe what [~jeromatron] has been trying to raise here.
Cassandra does not have a proper query optimizer yet (it is one thing I believe
will change soon) but if it had something like AF would not make sense at the
query level anymore because a user will be less efficient than a proper
optimizer at picking up the best access pattern. At this point we might still
want to be able to configure some safety nets but that will be an operator
level decision about what they believe is acceptable or not. I am not
advocating for removing AF at this point only when we will have a proper
optimizer.
> Separate out allow filtering scanning through a partition versus scanning
> over the table
>
>
> Key: CASSANDRA-15803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15803
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Jeremy Hanna
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Currently allow filtering can mean two things in the spirit of "avoid
> operations that don't seek to a specific row or sequential rows of data."
> First, it can mean scanning across the entire table to meet the criteria of
> the query. That's almost always a bad thing and should be discouraged or
> disabled (see CASSANDRA-8303). Second, it can mean filtering within a
> specific partition. For example, in a query you could specify the full
> partition key and if you specify a criterion on a non-key field, it requires
> allow filtering.
> The second reason to require allow filtering is significantly less work to
> scan through a partition. It is still extra work over seeking to a specific
> row and getting N sequential rows though. So while an application developer
> and/or operator needs to be cautious about this second type, it's not
> necessarily a bad thing, depending on the table and the use case.
> I propose that we separate the way to specify allow filtering across an
> entire table from specifying allow filtering across a partition in a
> backwards compatible way. One idea that was brought up in Slack in the
> cassandra-dev room was to have allow filtering mean the superset - scanning
> across the table. Then if you want to specify that you *only* want to
[cassandra] tag 3.11.15-tentative created (now 6cdcf5e56a)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to tag 3.11.15-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git at 6cdcf5e56a (commit) This tag includes the following new commits: new 6cdcf5e56a Prepare debian changelog for 3.11.15 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Prepare debian changelog for 3.11.15
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to tag 3.11.15-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 6cdcf5e56a77cf40c251125d68856a614eccbc53 Author: Stefan Miklosovic AuthorDate: Fri Apr 28 12:30:03 2023 +0200 Prepare debian changelog for 3.11.15 --- debian/changelog | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/changelog b/debian/changelog index c895b9fe57..c1e91c0ee5 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,8 +1,8 @@ -cassandra (3.11.15) UNRELEASED; urgency=medium +cassandra (3.11.15) unstable; urgency=medium * New release - -- Mick Semb Wever Wed, 19 Oct 2022 10:27:23 +0200 + -- Stefan Miklosovic Fri, 28 Apr 2023 12:29:32 +0200 cassandra (3.11.14) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r61530 - /dev/cassandra/3.11.15/
Author: smiklosovic Date: Fri Apr 28 10:33:22 2023 New Revision: 61530 Log: staging cassandra 3.11.15 Added: dev/cassandra/3.11.15/ dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz (with props) dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz.asc dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz.sha256 dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz.sha512 dev/cassandra/3.11.15/apache-cassandra-3.11.15-src.tar.gz (with props) dev/cassandra/3.11.15/apache-cassandra-3.11.15-src.tar.gz.asc dev/cassandra/3.11.15/apache-cassandra-3.11.15-src.tar.gz.sha256 dev/cassandra/3.11.15/apache-cassandra-3.11.15-src.tar.gz.sha512 Added: dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz.asc == --- dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz.asc (added) +++ dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz.asc Fri Apr 28 10:33:22 2023 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEdGSq2QaCQcULpqJiMvNcsvVG2T4FAmRLoKQACgkQMvNcsvVG +2T4Vnw//dqT2ZsQ8Bks9JIFtUWiC9ZYxYCbrAGBn7b/Hl329Vkvufg4X7SoT6KMP +JtTT3GYRIomDEOYqb6961S07RVv8YykYZrQRJziQdeBnoub1sc319My15DpopqBS +E0TPMsqwCrbtO4MeNbc3mJRE30rce3fO7GiI9i9Ns65sSalWJ4tB3KOFIa3mdXRB +ig/IE3/xmF+Tkz1z9ocgPgjR48TVKILsZY8chBXGI3ecSV+2G+LL+qPZTc6aocrJ +hLmHUW4a3rd2gHcLxBzfL6fgt7fHD3pl2f7xj0WJhUPTDLkQHDUF8d6suRDNUQYk +G9Q33fJ/kBVaDXccjJNHpLXwla2oaJGfhm0+O9/fFYCMfRKKCtcxfaYVr20y4nhq +eoWJ3aJUCsgiDodjZ8uVWjTe5f9xnfQ5IU66pPMZYMIGXKb010jn0ajtK7SGfLig +aUcQOnQVD4ifMx8vewghiFrpwWyFnj/WO7JdAKpHMd2ekJ5M3KLEWoxOv9pM/8Ux +TM+XF4IhBTXAZQDHpVzj3PTLPYSLnwigJoUcSb45t8+Yst70s+SkdPQnmFCYpw7E +X3aMi1443MfnjYeBedlWp6PUrwp13NtWCTbgrdEOtI1eomEDqmtihl7O7CSeC/TE +3WzOKAP/X5+f19emIeLqRKZIggGKxVyNOc/ftHK9fG2m5ikBaMM= +=20Q4 +-END PGP SIGNATURE- Added: dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz.sha256 == --- dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz.sha256 (added) +++ dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz.sha256 Fri Apr 28 10:33:22 2023 @@ -0,0 +1 @@ +3e410f25e2588617db15a474025243dd74f1aae85d869bed3c5825ebcd5f2fa9 Added: dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz.sha512 == --- dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz.sha512 (added) +++ dev/cassandra/3.11.15/apache-cassandra-3.11.15-bin.tar.gz.sha512 Fri Apr 28 10:33:22 2023 @@ -0,0 +1 @@ +a8de34b57d38a425a9308bee185f1731f46a2977666952ac0ba811ffbb9cbeacb9b08aaf1012951195ba6f94983323afeaf6e51f0f7af5fea34c6d8ac87ca699 Added: dev/cassandra/3.11.15/apache-cassandra-3.11.15-src.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/3.11.15/apache-cassandra-3.11.15-src.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.11.15/apache-cassandra-3.11.15-src.tar.gz.asc == --- dev/cassandra/3.11.15/apache-cassandra-3.11.15-src.tar.gz.asc (added) +++ dev/cassandra/3.11.15/apache-cassandra-3.11.15-src.tar.gz.asc Fri Apr 28 10:33:22 2023 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEdGSq2QaCQcULpqJiMvNcsvVG2T4FAmRLoKYACgkQMvNcsvVG +2T52/Q//WvkIrZB19uQyRWkqlpfGjkbbv5u2h1JXU2OOsvm1g71JHHy6hmlahrlj +f8OJQmGFvg47eJLhHhjIb8HMkw4IkR6iCwSj2rT4E9B4JalsD4A4qv9MDvgh3u31 +rpUQftVrRaW/PSLodkRifAqzDRm/TZGfJsoG+2exAiQv8mGylGP8t5zArnrH8Uck +UBl5cEUOJI7LJf+J3lwhrg5pmsYwkL7Haut2mnGOmF2bb+fnd/Hn2PRL9zTpk996 +ytPnt9gEAAgfy0biQPYqOnZHCNvMNQ0AWZImNqCct3z7nFSGHNaLuT8bTOGtRKN0 +olIMl3MtemvdNPrHB+j0FgsYVBjou+upWEr2fOaF3ripLne3+1icYONxH8lZrBMj +DE15Rn4IokCBAStJa3YGavsSDGlZs+s9azqkw2i5WcoKUiq6JyttiDDC46kR4wPN +bdf4DACDYM9BtkYuQOT18zpDLcqGsDKTABAUSXSs+EKxn5q4scwed0D+NjJNmyfg +5hHzbL9JzuQJpCnyGStREWfpYJ7YeFiy7no9XfE6XcFhUBDVJn0C/p8Z3Je1xheg +e4cJ+/TJN3z+svtq4DaQKiK1xpoUcOqjvu2LDUBxDo2sSzn5Aqfc+RCKZqK/z09o +QtYDKoUoOITx3679HZzacE+D5kMkHx/ANpd33YJrlnlAhkWRWbw= +=TdV2 +-END PGP SIGNATURE- Added: dev/cassandra/3.11.15/apache-cassandra-3.11.15-src.tar.gz.sha256 == --- dev/cassandra/3.11.15/apache-cassandra-3.11.15-src.tar.gz.sha256 (added) +++ dev/cassandra/3.11.15/apache-cassandra-3.11.15-src.tar.gz.sha256 Fri Apr 28 10:33:22
svn commit: r61531 - in /dev/cassandra/3.11.15/debian: ./ dists/ dists/311x/ dists/311x/main/ dists/311x/main/binary-amd64/ dists/311x/main/binary-arm64/ dists/311x/main/binary-i386/ dists/311x/main/s
Author: smiklosovic Date: Fri Apr 28 10:38:14 2023 New Revision: 61531 Log: staging cassandra debian packages for 3.11.15 Added: dev/cassandra/3.11.15/debian/ dev/cassandra/3.11.15/debian/cassandra-tools_3.11.15_all.deb (with props) dev/cassandra/3.11.15/debian/cassandra_3.11.15.dsc dev/cassandra/3.11.15/debian/cassandra_3.11.15.tar.gz (with props) dev/cassandra/3.11.15/debian/cassandra_3.11.15_all.deb (with props) dev/cassandra/3.11.15/debian/cassandra_3.11.15_amd64.buildinfo dev/cassandra/3.11.15/debian/cassandra_3.11.15_amd64.changes dev/cassandra/3.11.15/debian/dists/ dev/cassandra/3.11.15/debian/dists/311x/ dev/cassandra/3.11.15/debian/dists/311x/InRelease dev/cassandra/3.11.15/debian/dists/311x/Release dev/cassandra/3.11.15/debian/dists/311x/Release.gpg dev/cassandra/3.11.15/debian/dists/311x/main/ dev/cassandra/3.11.15/debian/dists/311x/main/binary-amd64/ dev/cassandra/3.11.15/debian/dists/311x/main/binary-amd64/Packages dev/cassandra/3.11.15/debian/dists/311x/main/binary-amd64/Packages.gz (with props) dev/cassandra/3.11.15/debian/dists/311x/main/binary-amd64/Release dev/cassandra/3.11.15/debian/dists/311x/main/binary-arm64/ dev/cassandra/3.11.15/debian/dists/311x/main/binary-arm64/Packages dev/cassandra/3.11.15/debian/dists/311x/main/binary-arm64/Packages.gz (with props) dev/cassandra/3.11.15/debian/dists/311x/main/binary-arm64/Release dev/cassandra/3.11.15/debian/dists/311x/main/binary-i386/ dev/cassandra/3.11.15/debian/dists/311x/main/binary-i386/Packages dev/cassandra/3.11.15/debian/dists/311x/main/binary-i386/Packages.gz (with props) dev/cassandra/3.11.15/debian/dists/311x/main/binary-i386/Release dev/cassandra/3.11.15/debian/dists/311x/main/source/ dev/cassandra/3.11.15/debian/dists/311x/main/source/Release dev/cassandra/3.11.15/debian/dists/311x/main/source/Sources.gz (with props) dev/cassandra/3.11.15/debian/pool/ dev/cassandra/3.11.15/debian/pool/main/ dev/cassandra/3.11.15/debian/pool/main/c/ dev/cassandra/3.11.15/debian/pool/main/c/cassandra/ dev/cassandra/3.11.15/debian/pool/main/c/cassandra/cassandra-tools_3.11.15_all.deb (with props) dev/cassandra/3.11.15/debian/pool/main/c/cassandra/cassandra_3.11.15.dsc dev/cassandra/3.11.15/debian/pool/main/c/cassandra/cassandra_3.11.15.tar.gz (with props) dev/cassandra/3.11.15/debian/pool/main/c/cassandra/cassandra_3.11.15_all.deb (with props) Added: dev/cassandra/3.11.15/debian/cassandra-tools_3.11.15_all.deb == Binary file - no diff available. Propchange: dev/cassandra/3.11.15/debian/cassandra-tools_3.11.15_all.deb -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.11.15/debian/cassandra_3.11.15.dsc == --- dev/cassandra/3.11.15/debian/cassandra_3.11.15.dsc (added) +++ dev/cassandra/3.11.15/debian/cassandra_3.11.15.dsc Fri Apr 28 10:38:14 2023 @@ -0,0 +1,41 @@ +-BEGIN PGP SIGNED MESSAGE- +Hash: SHA512 + +Format: 1.0 +Source: cassandra +Binary: cassandra, cassandra-tools +Architecture: all +Version: 3.11.15 +Maintainer: Eric Evans +Uploaders: Sylvain Lebresne +Homepage: http://cassandra.apache.org +Standards-Version: 3.8.3 +Vcs-Browser: https://git-wip-us.apache.org/repos/asf?p=cassandra.git +Vcs-Git: http://git-wip-us.apache.org/repos/asf/cassandra.git +Build-Depends: debhelper (>= 5), openjdk-8-jdk | java8-jdk, ant (>= 1.9), ant-optional (>= 1.9), dh-python, python-dev (>= 2.7) | python2-dev (>= 2.7), dpatch, bash-completion +Package-List: + cassandra deb misc extra arch=all + cassandra-tools deb misc extra arch=all +Checksums-Sha1: + b3779144f9dc4cda540af72b87b9b57257158757 245032862 cassandra_3.11.15.tar.gz +Checksums-Sha256: + c2f5923fa60036cdee21fb2cdcf9d3f416bf0db632bd74cddd8151c3f92d8eff 245032862 cassandra_3.11.15.tar.gz +Files: + 711007605b74f16a9145942467d4dc56 245032862 cassandra_3.11.15.tar.gz + +-BEGIN PGP SIGNATURE- + +iQIzBAEBCgAdFiEEdGSq2QaCQcULpqJiMvNcsvVG2T4FAmRLoeUACgkQMvNcsvVG +2T45Pg//dj6x9Mikyk43ccj+PgPltuI6JmrW6PNBqG56yHc3LinqLz3+/1Qq929C +LgXsx+mspwA4AdUqFp3fykmJywaXjSuJOoN91Fk+usrbDo7s38CXagOeJt8iXDwa +1TqrGlyUeFukiewyb06bk3Ppxaum/3xUbYBffZIAd0O8EvCJCeiLWwLPD+W/kf59 +5ua0dbRTvbGlUdw64ol2NAmi11xOxo5M99gn9WbuoQqgfaaD/SHnn+YPeeQBcR4h +vjPM2u/Uoe2j7RgUrTfxZtLBd6zUiCnCCrlf8VRnrN0eeOvL7euR1s9BYymgUP7v +vfqpjgkyJ7GQYbLJnW/Uzl9F89SVhbd/X86uTOVzLmxE8N4NMmCYcWGEk5M3zSGD +4XFTpJszi18PSVzaLAevhNIXwG1tHNjla4OfxiX2vRim8p6IT6/KZyUk5qzjJNo/ +QjnTlc4ykh7qQK23T6AHCCfrAW31HAcMTfI0RsS/Dk8t3jxPj9u87y4BacDHEroQ +yZpz0T5GUMflhGvJ2j3j6Xe1rKW3JEv/v0WQ1A2gT51MUToSaThCEVJ87L5FuxqR +wgeQ//X4cplwuzNfGBiw+vYNxMQJH7mRQG6kJPjVJe/SKrxVtMQIGzxrgT/3WFeH +rH3PphKCL8uPGQvNhdFo8oLOb9yeKpa7xz8zqgzbHkShnEsssIw= +=xJHX +
svn commit: r61532 - in /dev/cassandra/3.11.15/redhat: ./ repodata/
Author: smiklosovic Date: Fri Apr 28 10:40:00 2023 New Revision: 61532 Log: staging cassandra rpm packages for 3.11.15 Added: dev/cassandra/3.11.15/redhat/ dev/cassandra/3.11.15/redhat/cassandra-3.11.15-1.noarch.rpm (with props) dev/cassandra/3.11.15/redhat/cassandra-3.11.15-1.src.rpm (with props) dev/cassandra/3.11.15/redhat/cassandra-tools-3.11.15-1.noarch.rpm (with props) dev/cassandra/3.11.15/redhat/repodata/ dev/cassandra/3.11.15/redhat/repodata/227b420e9b5ffee04cf1a40d101805b1ad484a3de66754603e79f583a258fbb5-primary.sqlite.bz2 (with props) dev/cassandra/3.11.15/redhat/repodata/227b420e9b5ffee04cf1a40d101805b1ad484a3de66754603e79f583a258fbb5-primary.sqlite.bz2.asc dev/cassandra/3.11.15/redhat/repodata/431f6fecde6521e90bc19d2a54ce6ca62af9115057cc751e69ab37efacc02cfb-filelists.sqlite.bz2 (with props) dev/cassandra/3.11.15/redhat/repodata/431f6fecde6521e90bc19d2a54ce6ca62af9115057cc751e69ab37efacc02cfb-filelists.sqlite.bz2.asc dev/cassandra/3.11.15/redhat/repodata/4d383d0b5c2ff4b6a3d06adb736d99ae08146d506dc7eda5bb376432b2b79bd4-filelists.xml.gz (with props) dev/cassandra/3.11.15/redhat/repodata/4d383d0b5c2ff4b6a3d06adb736d99ae08146d506dc7eda5bb376432b2b79bd4-filelists.xml.gz.asc dev/cassandra/3.11.15/redhat/repodata/a1205e39fcfd4887ed7087d851f4ea930a1e3b83d4e99dc7be9d4729050946ce-primary.xml.gz (with props) dev/cassandra/3.11.15/redhat/repodata/a1205e39fcfd4887ed7087d851f4ea930a1e3b83d4e99dc7be9d4729050946ce-primary.xml.gz.asc dev/cassandra/3.11.15/redhat/repodata/b386caf0f7fc1def22788cd4c0a64f57c99fd88b9e41317f7d57e9ece43186c7-other.xml.gz (with props) dev/cassandra/3.11.15/redhat/repodata/b386caf0f7fc1def22788cd4c0a64f57c99fd88b9e41317f7d57e9ece43186c7-other.xml.gz.asc dev/cassandra/3.11.15/redhat/repodata/be83cd8cda794a0659601510e9a40a9c7d470a1d851e5a50d2725324b7d2e622-other.sqlite.bz2 (with props) dev/cassandra/3.11.15/redhat/repodata/be83cd8cda794a0659601510e9a40a9c7d470a1d851e5a50d2725324b7d2e622-other.sqlite.bz2.asc dev/cassandra/3.11.15/redhat/repodata/repomd.xml dev/cassandra/3.11.15/redhat/repodata/repomd.xml.asc Added: dev/cassandra/3.11.15/redhat/cassandra-3.11.15-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/3.11.15/redhat/cassandra-3.11.15-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.11.15/redhat/cassandra-3.11.15-1.src.rpm == Binary file - no diff available. Propchange: dev/cassandra/3.11.15/redhat/cassandra-3.11.15-1.src.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.11.15/redhat/cassandra-tools-3.11.15-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/3.11.15/redhat/cassandra-tools-3.11.15-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.11.15/redhat/repodata/227b420e9b5ffee04cf1a40d101805b1ad484a3de66754603e79f583a258fbb5-primary.sqlite.bz2 == Binary file - no diff available. Propchange: dev/cassandra/3.11.15/redhat/repodata/227b420e9b5ffee04cf1a40d101805b1ad484a3de66754603e79f583a258fbb5-primary.sqlite.bz2 -- svn:mime-type = application/octet-stream Added: dev/cassandra/3.11.15/redhat/repodata/227b420e9b5ffee04cf1a40d101805b1ad484a3de66754603e79f583a258fbb5-primary.sqlite.bz2.asc == --- dev/cassandra/3.11.15/redhat/repodata/227b420e9b5ffee04cf1a40d101805b1ad484a3de66754603e79f583a258fbb5-primary.sqlite.bz2.asc (added) +++ dev/cassandra/3.11.15/redhat/repodata/227b420e9b5ffee04cf1a40d101805b1ad484a3de66754603e79f583a258fbb5-primary.sqlite.bz2.asc Fri Apr 28 10:40:00 2023 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEdGSq2QaCQcULpqJiMvNcsvVG2T4FAmRLonQACgkQMvNcsvVG +2T5pkRAAtfSEEHzNv2FY1Z9dw/4LUKiKFyQGJgVwT/30QwdvQmIVVqqz3Sn61qud +jtVrYl2dsk4a1kOEi+0f2Hvvv46qp2RsEXNvHwV3qgeEs/0nKDcN+E2Q0Zd+HI26 +plzbxK24I8a02fgCcsc9GNuRSdIvANfo9lvYRUbb5bSGYJzwGOayuRqu/YNMm207 +RT8yU2nBLdETpHH5XvjnQzeXxJ5xqrUuEYcrhkYHqpVEFoyU0As9K2KfW/xozvJY +HMVNcoFZGAnhe7wCtmdrn8ri2KGMliWC2cuwmsHYcR6BxHXTyss8AOoH7TeoIV1u +Po0XYe8Qpg4lT9vw5WyUcRcJeJ051agtlOpzz23uQZtlvAciIu3PMl5CvEApJxzA +dJaxHY4ycNCnmOByUx/uicYoSSkXMDBLIU9mnb/wJGTYm+ufb3hdL16sFJcMgJlA +prrj1zkIlfLukcNc3hbCq3iTl8k/VpqAvz5tzQNd1ndb6HDRm11b6Rbh/wog9PTy +PuDlC7CtV6+PFbEZFfXib3tEE75
[cassandra] branch cassandra-4.0 updated (c4a305d17a -> b183e1f0de)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from c4a305d17a Merge branch 'cassandra-3.11' into cassandra-4.0 add 6cdcf5e56a Prepare debian changelog for 3.11.15 add b183e1f0de Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (ba72d90141 -> 1a72fbd9c6)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from ba72d90141 Merge branch 'cassandra-4.0' into cassandra-4.1 add 6cdcf5e56a Prepare debian changelog for 3.11.15 add b183e1f0de Merge branch 'cassandra-3.11' into cassandra-4.0 add 1a72fbd9c6 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (c74c9bb037 -> 6cdcf5e56a)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from c74c9bb037 Merge branch 'cassandra-3.0' into cassandra-3.11 add 6cdcf5e56a Prepare debian changelog for 3.11.15 No new revisions were added by this update. Summary of changes: debian/changelog | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 63ab8e09286e4b2076695f62e08a7f39cb6860d1 Merge: cf48c04c00 1a72fbd9c6 Author: Stefan Miklosovic AuthorDate: Fri Apr 28 12:41:39 2023 +0200 Merge branch 'cassandra-4.1' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (cf48c04c00 -> 63ab8e0928)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from cf48c04c00 Merge branch 'cassandra-4.1' into trunk add 6cdcf5e56a Prepare debian changelog for 3.11.15 add b183e1f0de Merge branch 'cassandra-3.11' into cassandra-4.0 add 1a72fbd9c6 Merge branch 'cassandra-4.0' into cassandra-4.1 new 63ab8e0928 Merge branch 'cassandra-4.1' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18228) Reorganize Apache C* docs in trunk branch to match the IA
[ https://issues.apache.org/jira/browse/CASSANDRA-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717609#comment-17717609 ] Michael Semb Wever commented on CASSANDRA-18228: second PR: https://github.com/apache/cassandra/pull/2294 > Reorganize Apache C* docs in trunk branch to match the IA > - > > Key: CASSANDRA-18228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18228 > Project: Cassandra > Issue Type: New Feature > Components: Documentation >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Fix For: 5.x > > > An agreed-upon Information Architecture will be used to reorganize the C* 5.0 > docs. > IA doc: > https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing -- This message was sent by Atlassian 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-18484) FunctionCall can throw more specific exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic reassigned CASSANDRA-18484:
-
Assignee: Stefan Miklosovic
> FunctionCall can throw more specific exceptions
> ---
>
> Key: CASSANDRA-18484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18484
> Project: Cassandra
> Issue Type: Bug
>Reporter: Hao Zhong
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> FunctionCall has the following code:
> {code:java}
> private static ByteBuffer executeInternal(ProtocolVersion protocolVersion,
> ScalarFunction fun, List params) throws InvalidRequestException
> {
> ByteBuffer result = fun.execute(protocolVersion, params);
> try
> {
> // Check the method didn't lied on it's declared return type
> if (result != null)
> fun.returnType().validate(result);
> return result;
> }
> catch (MarshalException e)
> {
> throw new RuntimeException(String.format("Return of function %s
> (%s) is not a valid value for its declared return type %s",
> fun,
> ByteBufferUtil.bytesToHex(result), fun.returnType().asCQL3Type()), e);
> }
> }
> {code}
> When validate throws MarshalException, it rethrows RuntimeException. Other
> methods throw more specific exceptions. For example, BytesConversionFcts
> throws
> {color:#00}InvalidRequestException:{color}
> {code:java}
> public ByteBuffer execute(ProtocolVersion protocolVersion, List
> parameters)
> {
> ByteBuffer val = parameters.get(0);
> if (val != null)
> {
> try
> {
> toType.getType().validate(val);
> }
> catch (MarshalException e)
> {
> throw new InvalidRequestException(String.format("In call
> to function %s, value 0x%s is not a " +
> "valid
> binary representation for type %s",
> name,
> ByteBufferUtil.bytesToHex(val), toType));
> }
> }
> return val;
> }
> {code}
> {color:#00}{color:#00}As another example, Validation also rethrows
> this exception:{color}{color}
> {code:java}
> public static void validateKey(TableMetadata metadata, ByteBuffer key)
> {
> ...
> try
> {
> metadata.partitionKeyType.validate(key);
> }
> catch (MarshalException e)
> {
> throw new InvalidRequestException(e.getMessage());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18486) LeveledCompactionStrategy does not check its constructor
[
https://issues.apache.org/jira/browse/CASSANDRA-18486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18486:
-
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Component/s: Local/Compaction/LCS
Discovered By: User Report
Fix Version/s: 5.x
Severity: Low
Status: Open (was: Triage Needed)
> LeveledCompactionStrategy does not check its constructor
>
>
> Key: CASSANDRA-18486
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18486
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Hao Zhong
>Priority: Normal
> Fix For: 5.x
>
>
> LeveledCompactionStrategy has the following code:
>
> {code:java}
> public static Map validateOptions(Map
> options) throws ConfigurationException
> {
> Map uncheckedOptions =
> AbstractCompactionStrategy.validateOptions(options);
> String size = options.containsKey(SSTABLE_SIZE_OPTION) ?
> options.get(SSTABLE_SIZE_OPTION) : "1";
> try
> {
> int ssSize = Integer.parseInt(size);
> if (ssSize < 1)
> {
> throw new ConfigurationException(String.format("%s must be
> larger than 0, but was %s", SSTABLE_SIZE_OPTION, ssSize));
> }
> }
> catch (NumberFormatException ex)
> {
> throw new ConfigurationException(String.format("%s is not a
> parsable int (base10) for %s", size, SSTABLE_SIZE_OPTION), ex);
> }
> ...
> } {code}
> This method throws ConfigurationException when the configuration file is
> wrong. The thrown exception is easy to understand, and calling code can catch
> this exception to handle configuration files with wrong formats. However, the
> constructor of this class does not check configuration files:
>
>
>
> {code:java}
> public LeveledCompactionStrategy(ColumnFamilyStore cfs, Map
> options)
> {...
>
> configuredMaxSSTableSize = Integer.parseInt(options.get(SSTABLE_SIZE_OPTION));
> ...
> configuredLevelFanoutSize =
> Integer.parseInt(options.get(LEVEL_FANOUT_SIZE_OPTION));
> ...
> }
> {code}
> As a result, this class can throw NumberFormatException when configuration
> files are wrong, and will not throw ConfigurationException.
> It is strange for calling code to call the static validation method before
> calling its constructor. Can this problem be fixed?
>
>
--
This message was sent by Atlassian 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-18487) MappedByteBufferIndexInputProvider can better throw UndeclaredThrowableException
[
https://issues.apache.org/jira/browse/CASSANDRA-18487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18487:
-
Resolution: Invalid
Status: Resolved (was: Triage Needed)
> MappedByteBufferIndexInputProvider can better throw
> UndeclaredThrowableException
>
>
> Key: CASSANDRA-18487
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18487
> Project: Cassandra
> Issue Type: Bug
>Reporter: Hao Zhong
>Priority: Normal
>
> MappedByteBufferIndexInputProvider has the following code:
> {code:java}
> private static BufferCleaner newBufferCleaner(final MethodHandle unmapper) {
> ...
> try {
> unmapper.invokeExact(buffer);
> } catch (Throwable t) {
> throw new IOException("Unable to unmap the mapped buffer: " +
> resourceDescription, t);
> }
> }{code}
> This method rethrow IOException, when calling invokeExact fails. However,
> other methods throw UndeclaredThrowableException for the same errors. For
> example, SnowballProgram.find_among is as follows:
> {code:java}
> protected int find_among(Among v[]) {
> ..,
>
> try {
> res = (boolean) w.method.invokeExact(this);
> } catch (Error | RuntimeException e) {
> throw e;
> } catch (Throwable e) {
> throw new UndeclaredThrowableException(e);
> }
> }{code}
> Another example is AttributeFactory.{color:#00}createInstance{color}
> :
> {code:java}
>
> protected A createInstance() {
> try {
> // be explicit with casting, so javac compiles correct call to
> polymorphic signature:
> final AttributeImpl impl = (AttributeImpl) constr.invokeExact();
> // now cast to generic type:
> return (A) impl;
> } catch (Error | RuntimeException e) {
> throw e;
> } catch (Throwable e) {
> throw new UndeclaredThrowableException(e);
> }
> }
> {code}
> UndeclaredThrowableException looks more reasonable. Can this be fixed?
--
This message was sent by Atlassian 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-18484) FunctionCall can throw more specific exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717619#comment-17717619
]
Stefan Miklosovic commented on CASSANDRA-18484:
---
[~haozhong] lets give it a week or two to have a chance to report additional
issues you may find so we are not returning to this issue again in the future
and we fix it all in one shot.
> FunctionCall can throw more specific exceptions
> ---
>
> Key: CASSANDRA-18484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18484
> Project: Cassandra
> Issue Type: Bug
>Reporter: Hao Zhong
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> FunctionCall has the following code:
> {code:java}
> private static ByteBuffer executeInternal(ProtocolVersion protocolVersion,
> ScalarFunction fun, List params) throws InvalidRequestException
> {
> ByteBuffer result = fun.execute(protocolVersion, params);
> try
> {
> // Check the method didn't lied on it's declared return type
> if (result != null)
> fun.returnType().validate(result);
> return result;
> }
> catch (MarshalException e)
> {
> throw new RuntimeException(String.format("Return of function %s
> (%s) is not a valid value for its declared return type %s",
> fun,
> ByteBufferUtil.bytesToHex(result), fun.returnType().asCQL3Type()), e);
> }
> }
> {code}
> When validate throws MarshalException, it rethrows RuntimeException. Other
> methods throw more specific exceptions. For example, BytesConversionFcts
> throws
> {color:#00}InvalidRequestException:{color}
> {code:java}
> public ByteBuffer execute(ProtocolVersion protocolVersion, List
> parameters)
> {
> ByteBuffer val = parameters.get(0);
> if (val != null)
> {
> try
> {
> toType.getType().validate(val);
> }
> catch (MarshalException e)
> {
> throw new InvalidRequestException(String.format("In call
> to function %s, value 0x%s is not a " +
> "valid
> binary representation for type %s",
> name,
> ByteBufferUtil.bytesToHex(val), toType));
> }
> }
> return val;
> }
> {code}
> {color:#00}{color:#00}As another example, Validation also rethrows
> this exception:{color}{color}
> {code:java}
> public static void validateKey(TableMetadata metadata, ByteBuffer key)
> {
> ...
> try
> {
> metadata.partitionKeyType.validate(key);
> }
> catch (MarshalException e)
> {
> throw new InvalidRequestException(e.getMessage());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18488) WEBSITE - Replace Forward banner with Summit banner on pages
Stefano Lottini created CASSANDRA-18488: --- Summary: WEBSITE - Replace Forward banner with Summit banner on pages Key: CASSANDRA-18488 URL: https://issues.apache.org/jira/browse/CASSANDRA-18488 Project: Cassandra Issue Type: Task Reporter: Stefano Lottini Attachments: banner_on_events_page.png, banner_on_index_page.png Cassandra Forward is in the past, so this addresses the fact by simply replacing the banner and the "register now" CTA with an equivalent thing for the December C* Summit. The (very simple) PR is available for inspection here: https://github.com/apache/cassandra-website/pull/219 See images: -- This message was sent by Atlassian 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-18488) WEBSITE - Replace Forward banner with Summit banner on pages
[ https://issues.apache.org/jira/browse/CASSANDRA-18488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Lottini reassigned CASSANDRA-18488: --- Assignee: Stefano Lottini > WEBSITE - Replace Forward banner with Summit banner on pages > > > Key: CASSANDRA-18488 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18488 > Project: Cassandra > Issue Type: Task >Reporter: Stefano Lottini >Assignee: Stefano Lottini >Priority: Normal > Attachments: banner_on_events_page.png, banner_on_index_page.png > > > Cassandra Forward is in the past, so this addresses the fact by simply > replacing the banner and the "register now" CTA with an equivalent thing for > the December C* Summit. > The (very simple) PR is available for inspection here: > https://github.com/apache/cassandra-website/pull/219 > See images: -- This message was sent by Atlassian 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-18484) FunctionCall can throw more specific exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-18484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717621#comment-17717621
]
Brandon Williams commented on CASSANDRA-18484:
--
They should be separate tickets at this point, and already are, like
CASSANDRA-18486, so go ahead imo.
> FunctionCall can throw more specific exceptions
> ---
>
> Key: CASSANDRA-18484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18484
> Project: Cassandra
> Issue Type: Bug
>Reporter: Hao Zhong
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> FunctionCall has the following code:
> {code:java}
> private static ByteBuffer executeInternal(ProtocolVersion protocolVersion,
> ScalarFunction fun, List params) throws InvalidRequestException
> {
> ByteBuffer result = fun.execute(protocolVersion, params);
> try
> {
> // Check the method didn't lied on it's declared return type
> if (result != null)
> fun.returnType().validate(result);
> return result;
> }
> catch (MarshalException e)
> {
> throw new RuntimeException(String.format("Return of function %s
> (%s) is not a valid value for its declared return type %s",
> fun,
> ByteBufferUtil.bytesToHex(result), fun.returnType().asCQL3Type()), e);
> }
> }
> {code}
> When validate throws MarshalException, it rethrows RuntimeException. Other
> methods throw more specific exceptions. For example, BytesConversionFcts
> throws
> {color:#00}InvalidRequestException:{color}
> {code:java}
> public ByteBuffer execute(ProtocolVersion protocolVersion, List
> parameters)
> {
> ByteBuffer val = parameters.get(0);
> if (val != null)
> {
> try
> {
> toType.getType().validate(val);
> }
> catch (MarshalException e)
> {
> throw new InvalidRequestException(String.format("In call
> to function %s, value 0x%s is not a " +
> "valid
> binary representation for type %s",
> name,
> ByteBufferUtil.bytesToHex(val), toType));
> }
> }
> return val;
> }
> {code}
> {color:#00}{color:#00}As another example, Validation also rethrows
> this exception:{color}{color}
> {code:java}
> public static void validateKey(TableMetadata metadata, ByteBuffer key)
> {
> ...
> try
> {
> metadata.partitionKeyType.validate(key);
> }
> catch (MarshalException e)
> {
> throw new InvalidRequestException(e.getMessage());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-18484) FunctionCall can throw more specific exceptions
[ https://issues.apache.org/jira/browse/CASSANDRA-18484 ]
Brandon Williams deleted comment on CASSANDRA-18484:
--
was (Author: brandon.williams):
They should be separate tickets at this point, and already are, like
CASSANDRA-18486, so go ahead imo.
> FunctionCall can throw more specific exceptions
> ---
>
> Key: CASSANDRA-18484
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18484
> Project: Cassandra
> Issue Type: Bug
>Reporter: Hao Zhong
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> FunctionCall has the following code:
> {code:java}
> private static ByteBuffer executeInternal(ProtocolVersion protocolVersion,
> ScalarFunction fun, List params) throws InvalidRequestException
> {
> ByteBuffer result = fun.execute(protocolVersion, params);
> try
> {
> // Check the method didn't lied on it's declared return type
> if (result != null)
> fun.returnType().validate(result);
> return result;
> }
> catch (MarshalException e)
> {
> throw new RuntimeException(String.format("Return of function %s
> (%s) is not a valid value for its declared return type %s",
> fun,
> ByteBufferUtil.bytesToHex(result), fun.returnType().asCQL3Type()), e);
> }
> }
> {code}
> When validate throws MarshalException, it rethrows RuntimeException. Other
> methods throw more specific exceptions. For example, BytesConversionFcts
> throws
> {color:#00}InvalidRequestException:{color}
> {code:java}
> public ByteBuffer execute(ProtocolVersion protocolVersion, List
> parameters)
> {
> ByteBuffer val = parameters.get(0);
> if (val != null)
> {
> try
> {
> toType.getType().validate(val);
> }
> catch (MarshalException e)
> {
> throw new InvalidRequestException(String.format("In call
> to function %s, value 0x%s is not a " +
> "valid
> binary representation for type %s",
> name,
> ByteBufferUtil.bytesToHex(val), toType));
> }
> }
> return val;
> }
> {code}
> {color:#00}{color:#00}As another example, Validation also rethrows
> this exception:{color}{color}
> {code:java}
> public static void validateKey(TableMetadata metadata, ByteBuffer key)
> {
> ...
> try
> {
> metadata.partitionKeyType.validate(key);
> }
> catch (MarshalException e)
> {
> throw new InvalidRequestException(e.getMessage());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13981) Enable Cassandra for Persistent Memory
[ https://issues.apache.org/jira/browse/CASSANDRA-13981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717633#comment-17717633 ] Jyothilekshmi commented on CASSANDRA-13981: --- The final version of the PMem code can be found at [https://github.com/apache/cassandra/pull/2274]. It is only intended for design reference and should not be merged. > Enable Cassandra for Persistent Memory > --- > > Key: CASSANDRA-13981 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13981 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core >Reporter: Preetika Tyagi >Assignee: Preetika Tyagi >Priority: Normal > Fix For: 5.x > > Attachments: in-mem-cassandra-1.0.patch, in-mem-cassandra-2.0.patch, > in-mem-cassandra-2.1.patch, readme.txt, readme2.1.txt, readme2_0.txt > > > Currently, Cassandra relies on disks for data storage and hence it needs data > serialization, compaction, bloom filters and partition summary/index for > speedy access of the data. However, with persistent memory, data can be > stored directly in the form of Java objects and collections, which can > greatly simplify the retrieval mechanism of the data. What we are proposing > is to make use of faster and scalable B+ tree-based data collections built > for persistent memory in Java (PCJ: https://github.com/pmem/pcj) and enable a > complete in-memory version of Cassandra, while still keeping the data > persistent. -- This message was sent by Atlassian 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-13981) Enable Cassandra for Persistent Memory
[ https://issues.apache.org/jira/browse/CASSANDRA-13981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717633#comment-17717633 ] Jyothilekshmi edited comment on CASSANDRA-13981 at 4/28/23 11:52 AM: - The final version of the PMem code can be found at [https://github.com/apache/cassandra/pull/2274]. It is only intended for reference and should not be merged. was (Author: JIRAUSER300121): The final version of the PMem code can be found at [https://github.com/apache/cassandra/pull/2274]. It is only intended for design reference and should not be merged. > Enable Cassandra for Persistent Memory > --- > > Key: CASSANDRA-13981 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13981 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core >Reporter: Preetika Tyagi >Assignee: Preetika Tyagi >Priority: Normal > Fix For: 5.x > > Attachments: in-mem-cassandra-1.0.patch, in-mem-cassandra-2.0.patch, > in-mem-cassandra-2.1.patch, readme.txt, readme2.1.txt, readme2_0.txt > > > Currently, Cassandra relies on disks for data storage and hence it needs data > serialization, compaction, bloom filters and partition summary/index for > speedy access of the data. However, with persistent memory, data can be > stored directly in the form of Java objects and collections, which can > greatly simplify the retrieval mechanism of the data. What we are proposing > is to make use of faster and scalable B+ tree-based data collections built > for persistent memory in Java (PCJ: https://github.com/pmem/pcj) and enable a > complete in-memory version of Cassandra, while still keeping the data > persistent. -- This message was sent by Atlassian 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-13981) Enable Cassandra for Persistent Memory
[ https://issues.apache.org/jira/browse/CASSANDRA-13981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717634#comment-17717634 ] Brandon Williams commented on CASSANDRA-13981: -- Should this ticket be closed? > Enable Cassandra for Persistent Memory > --- > > Key: CASSANDRA-13981 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13981 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core >Reporter: Preetika Tyagi >Assignee: Preetika Tyagi >Priority: Normal > Fix For: 5.x > > Attachments: in-mem-cassandra-1.0.patch, in-mem-cassandra-2.0.patch, > in-mem-cassandra-2.1.patch, readme.txt, readme2.1.txt, readme2_0.txt > > > Currently, Cassandra relies on disks for data storage and hence it needs data > serialization, compaction, bloom filters and partition summary/index for > speedy access of the data. However, with persistent memory, data can be > stored directly in the form of Java objects and collections, which can > greatly simplify the retrieval mechanism of the data. What we are proposing > is to make use of faster and scalable B+ tree-based data collections built > for persistent memory in Java (PCJ: https://github.com/pmem/pcj) and enable a > complete in-memory version of Cassandra, while still keeping the data > persistent. -- This message was sent by Atlassian 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717644#comment-17717644 ] Stefan Miklosovic commented on CASSANDRA-16855: --- There are classes in o.a.c.cql3.Json which are related just to CQL. I left them there and I moved everything else to o.a.c.utils.JsonUtils. So the state we find ourselves in is: 1) o.a.c.cql3.Json is used just in that package (or subpackages) and nowhere else. I can not make that class package protected because it is also used in o.a.c.cql3.selection.Selection 2) I moved all other stuff from o.a.c.cql3.Json to o.a.c.utils.JsonUtils 3) I moved all JSON related code in FBUtilities to o.a.c.utils.JsonUtils This means that all other code which needs to interact with JSON goes to o.a.c.utils.JsonUtils only, FBUtilities are a lightweight a bit and Json stuff in cql3 package is not spilling over. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- This message was sent by Atlassian 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717644#comment-17717644 ] Stefan Miklosovic edited comment on CASSANDRA-16855 at 4/28/23 12:12 PM: - There are classes in o.a.c.cql3.Json which are related just to CQL. I left them there and I moved everything else to o.a.c.utils.JsonUtils. So the state we find ourselves in is: 1) o.a.c.cql3.Json is used just in that package (or subpackages) and nowhere else. I can not make that class package protected because it is also used in o.a.c.cql3.selection.Selection 2) I moved all other stuff from o.a.c.cql3.Json to o.a.c.utils.JsonUtils 3) I moved all JSON related code in FBUtilities to o.a.c.utils.JsonUtils 4) There is one global instance of Json ObjectMapper. This means that all other code which needs to interact with JSON goes to o.a.c.utils.JsonUtils only, FBUtilities are a lightweight a bit and Json stuff in cql3 package is not spilling over. was (Author: smiklosovic): There are classes in o.a.c.cql3.Json which are related just to CQL. I left them there and I moved everything else to o.a.c.utils.JsonUtils. So the state we find ourselves in is: 1) o.a.c.cql3.Json is used just in that package (or subpackages) and nowhere else. I can not make that class package protected because it is also used in o.a.c.cql3.selection.Selection 2) I moved all other stuff from o.a.c.cql3.Json to o.a.c.utils.JsonUtils 3) I moved all JSON related code in FBUtilities to o.a.c.utils.JsonUtils This means that all other code which needs to interact with JSON goes to o.a.c.utils.JsonUtils only, FBUtilities are a lightweight a bit and Json stuff in cql3 package is not spilling over. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- This message was sent by Atlassian 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717644#comment-17717644 ] Stefan Miklosovic edited comment on CASSANDRA-16855 at 4/28/23 12:13 PM: - There are classes in o.a.c.cql3.Json which are related just to CQL. I left them there and I moved everything else to o.a.c.utils.JsonUtils. So the state we find ourselves in is: 1) o.a.c.cql3.Json is used just in that package (or subpackages) and nowhere else. I can not make that class package protected because it is also used in o.a.c.cql3.selection.Selection 2) I moved all other stuff from o.a.c.cql3.Json to o.a.c.utils.JsonUtils 3) I moved all JSON related code in FBUtilities to o.a.c.utils.JsonUtils 4) There is one global instance of Json ObjectMapper. This means that all other code which needs to interact with JSON goes to o.a.c.utils.JsonUtils only, FBUtilities lost some baggage and Json stuff in cql3 package is not spilling over. was (Author: smiklosovic): There are classes in o.a.c.cql3.Json which are related just to CQL. I left them there and I moved everything else to o.a.c.utils.JsonUtils. So the state we find ourselves in is: 1) o.a.c.cql3.Json is used just in that package (or subpackages) and nowhere else. I can not make that class package protected because it is also used in o.a.c.cql3.selection.Selection 2) I moved all other stuff from o.a.c.cql3.Json to o.a.c.utils.JsonUtils 3) I moved all JSON related code in FBUtilities to o.a.c.utils.JsonUtils 4) There is one global instance of Json ObjectMapper. This means that all other code which needs to interact with JSON goes to o.a.c.utils.JsonUtils only, FBUtilities are a lightweight a bit and Json stuff in cql3 package is not spilling over. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- This message was sent by Atlassian 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-18067) On-disk numeric index
[ https://issues.apache.org/jira/browse/CASSANDRA-18067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18067: -- Status: Review In Progress (was: Patch Available) > On-disk numeric index > - > > Key: CASSANDRA-18067 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18067 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Labels: SAI > Fix For: NA > > > An on-disk numeric index for all datatypes not supported by the on-disk > literal index (CASSANDRA-18062) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (62906e61 -> 44492fe1)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 62906e61 generate docs for 52f24b20 new 44492fe1 generate docs for 52f24b20 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 (62906e61) \ N -- N -- N refs/heads/asf-staging (44492fe1) 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 4796900 -> 4796900 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18449) Integer(int), Long(long), Float(double) were deprecated in JDK9
[ https://issues.apache.org/jira/browse/CASSANDRA-18449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717708#comment-17717708 ] Brandon Williams commented on CASSANDRA-18449: -- How does this look now, [~bereng]? > Integer(int), Long(long), Float(double) were deprecated in JDK9 > --- > > Key: CASSANDRA-18449 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18449 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.x > > > Now when we are moving with Cassandra 5.0 to 11+17, it is good to declutter > at least a bit our build log which contains 76 deprecation warnings. > Half of them are for deprecation of Integer(int), Long(long) and > Float(double). > Oracle advises to use factory methods which are likely to yield significantly > better space and time performance too. The factory methods are also marked > with > @IntrinsicCandidate > -- This message was sent by Atlassian 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-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717744#comment-17717744 ] Brandon Williams commented on CASSANDRA-16999: -- bq. the most consistent thing seems to be adding "native_port_ssl" to me If this is the route we want to take, here it is against 4.0: ||Branch||CI|| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-16999-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/990/workflows/df72d3cf-b746-48fb-a597-547fb9ee7c62], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/990/workflows/20488cb6-fda8-4303-b956-2baae2b245c0]| > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- This message was sent by Atlassian 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-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan reassigned CASSANDRA-18400:
---
Assignee: Ningzi Zhan
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
>
--
This message was sent by Atlassian 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-18486) LeveledCompactionStrategy does not check its constructor
[
https://issues.apache.org/jira/browse/CASSANDRA-18486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717751#comment-17717751
]
Caleb Rackliffe commented on CASSANDRA-18486:
-
{{validateOptions()}} is called in {{CompactionParams#validate()}} via
reflection, and I think the reason for this is that compaction strategies are
defined in DDL/on a table-by-table basis.
Do you have a specific proposal in mind?
> LeveledCompactionStrategy does not check its constructor
>
>
> Key: CASSANDRA-18486
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18486
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Hao Zhong
>Priority: Normal
> Fix For: 5.x
>
>
> LeveledCompactionStrategy has the following code:
>
> {code:java}
> public static Map validateOptions(Map
> options) throws ConfigurationException
> {
> Map uncheckedOptions =
> AbstractCompactionStrategy.validateOptions(options);
> String size = options.containsKey(SSTABLE_SIZE_OPTION) ?
> options.get(SSTABLE_SIZE_OPTION) : "1";
> try
> {
> int ssSize = Integer.parseInt(size);
> if (ssSize < 1)
> {
> throw new ConfigurationException(String.format("%s must be
> larger than 0, but was %s", SSTABLE_SIZE_OPTION, ssSize));
> }
> }
> catch (NumberFormatException ex)
> {
> throw new ConfigurationException(String.format("%s is not a
> parsable int (base10) for %s", size, SSTABLE_SIZE_OPTION), ex);
> }
> ...
> } {code}
> This method throws ConfigurationException when the configuration file is
> wrong. The thrown exception is easy to understand, and calling code can catch
> this exception to handle configuration files with wrong formats. However, the
> constructor of this class does not check configuration files:
>
>
>
> {code:java}
> public LeveledCompactionStrategy(ColumnFamilyStore cfs, Map
> options)
> {...
>
> configuredMaxSSTableSize = Integer.parseInt(options.get(SSTABLE_SIZE_OPTION));
> ...
> configuredLevelFanoutSize =
> Integer.parseInt(options.get(LEVEL_FANOUT_SIZE_OPTION));
> ...
> }
> {code}
> As a result, this class can throw NumberFormatException when configuration
> files are wrong, and will not throw ConfigurationException.
> It is strange for calling code to call the static validation method before
> calling its constructor. Can this problem be fixed?
>
>
--
This message was sent by Atlassian 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-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18400:
-
Mentor: Brandon Williams
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
>
--
This message was sent by Atlassian 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-16158) Avoid Unnecessary Chunk Cache Usage During Compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-16158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe reassigned CASSANDRA-16158:
---
Assignee: Caleb Rackliffe
> Avoid Unnecessary Chunk Cache Usage During Compaction
> -
>
> Key: CASSANDRA-16158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16158
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Compression, Feature/Encryption, Local/Compaction
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
>
> We have at least some evidence from CASSANDRA-16036 that compaction can cause
> significant churn in the chunk cache for a mixed workloads. Conceptually,
> this makes sense, as the files compaction is scanning are destined for
> deletion. It seems like we could avoid most of the cache churn mess by having
> the {{ISSTableScanner}} implementations returned by {{SSTableReader}} during
> compaction use file handles that don't use {{CachingRebufferer}}.
> {{FileHandle.Builder#complete()}} already seems to roughly have the logic we
> would need to produce the correct (uncached) {{RebuffererFactory}}.
> (NOTE: {{SSTableReader#getScanner(ColumnFilter, DataRange,
> SSTableReadsListener)}} is used on the read path, and we likely don't want to
> touch it here.)
> Given that CASSANDRA-16036 settled on disabling the chunk cache by default in
> 4.0, CASSANDRA-15229 further segregates the negative effects of this, and it
> isn't entirely clear that the decompression/decryption cache is actually
> adding measurable value for any workload, this may not be a critical priority
> for 4.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18260) Add details to Error message: Not enough space for compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-18260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717756#comment-17717756
]
Henrik Ingo commented on CASSANDRA-18260:
-
Ok I have added whitespace also the patch against trunk.
If I'm following correctly, I've addressed all comments, except for the DEBUG
log message, which isn't introduced by this patch, it is merely adjacent and
copied from one branch to another when backporting.
So I would suggest we merge and close this, and if there is sufficient
movitvation to remove the DEBUG message, that can easily be done in a separate
commit later.
> Add details to Error message: Not enough space for compaction
> --
>
> Key: CASSANDRA-18260
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18260
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction, Observability/Logging
>Reporter: Brad Schoening
>Assignee: Henrik Ingo
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> When compaction fails, the log message should list a) the free space
> available on disk at that point in time and b) perhaps the number and/or size
> of the source sstables being compacted.
> Free space can change from one moment to the next, so when the below
> compaction failed because it needed 161GB, upon checking the server a few
> minutes later, it had 184GB free. Similarly, the error message mentions it
> was writing out one SSTable on this STCS table, but its not clear if it was
> combining X -> 1 tables, or something else.
> {noformat}
> [INFO ] [CompactionExecutor:77758] cluster_id=87 ip_address=127.1.1.1
> CompactionTask.java:241 - Compacted (8a1cffe0-abb5-11ed-b3fc-8d2ac2c52f0d) 1
> sstables to [...] to level=0. 86.997GiB to 86.997GiB (~99% of original) in
> 1,508,155ms. Read Throughput = 59.069MiB/s, Write Throughput = 59.069MiB/s,
> Row Throughput = ~20,283/s. 21,375 total partitions merged to 21,375.
> Partition merge counts were \{1:21375, }
> [ERROR] [CompactionExecutor:4] cluster_id=87 ip_address=127.1.1.1
> CassandraDaemon.java:581 - Exception in thread
> Thread[CompactionExecutor:4,1,main]
> java.lang.RuntimeException: Not enough space for compaction, estimated
> sstables = 1, expected write size = 161228934093
> at
> org.apache.cassandra.db.compaction.CompactionTask.buildCompactionCandidatesForAvailableDiskSpace(CompactionTask.java:386)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:126)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:77)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
> at
> org.apache.cassandra.db.compaction.CompactionManager$7.execute(CompactionManager.java:613)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:377)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (44492fe1 -> 913474cd)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 44492fe1 generate docs for 52f24b20 new 913474cd generate docs for 52f24b20 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 (44492fe1) \ N -- N -- N refs/heads/asf-staging (913474cd) 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: site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18398) CEP-25: Trie-indexed SSTable format
[ https://issues.apache.org/jira/browse/CASSANDRA-18398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717758#comment-17717758 ] Caleb Rackliffe commented on CASSANDRA-18398: - This is more venting than constructive feedback, but there are certainly parts of this patch that would be simpler without early open in play. Are there any active proposals to remove it for 5.0? > CEP-25: Trie-indexed SSTable format > --- > > Key: CASSANDRA-18398 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18398 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Branimir Lambov >Assignee: Branimir Lambov >Priority: Normal > Fix For: 5.x > > Time Spent: 21h > Remaining Estimate: 0h > > Implementation of Big Trie-Indexed (BTI) SSTable format, per > [CEP-25|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format]. -- This message was sent by Atlassian 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-18398) CEP-25: Trie-indexed SSTable format
[
https://issues.apache.org/jira/browse/CASSANDRA-18398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717764#comment-17717764
]
Caleb Rackliffe commented on CASSANDRA-18398:
-
RE checksumming on the partition/row index files, would a reasonable path
forward for now be to spin off a separate Jira where we look into at least
verifying integrity on startup (and streaming?), sort of like what we do w/
{{DIGEST}}?
> CEP-25: Trie-indexed SSTable format
> ---
>
> Key: CASSANDRA-18398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18398
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 21h
> Remaining Estimate: 0h
>
> Implementation of Big Trie-Indexed (BTI) SSTable format, per
> [CEP-25|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format].
--
This message was sent by Atlassian 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16855: -- Status: Patch Available (was: In Progress) https://github.com/apache/cassandra/pull/2297 j8 pre-commit [https://app.circleci.com/pipelines/github/instaclustr/cassandra/2159/workflows/c53de0ea-721f-4545-bb6d-761ff6e3f3f2] j11 pre-commit [https://app.circleci.com/pipelines/github/instaclustr/cassandra/2159/workflows/6c3d588e-fcb0-43e2-a493-ba4ffcc47d22] > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- This message was sent by Atlassian 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16855: -- Status: In Progress (was: Patch Available) > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 40m > Remaining Estimate: 0h > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- This message was sent by Atlassian 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-18228) Reorganize Apache C* docs in trunk branch to match the IA
[ https://issues.apache.org/jira/browse/CASSANDRA-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717818#comment-17717818 ] Michael Semb Wever commented on CASSANDRA-18228: +1 > Reorganize Apache C* docs in trunk branch to match the IA > - > > Key: CASSANDRA-18228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18228 > Project: Cassandra > Issue Type: New Feature > Components: Documentation >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Fix For: 5.x > > > An agreed-upon Information Architecture will be used to reorganize the C* 5.0 > docs. > IA doc: > https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (913474cd8 -> 795013f51)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 913474cd8 generate docs for 52f24b20 new 795013f51 generate docs for 52f24b20 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 (913474cd8) \ N -- N -- N refs/heads/asf-staging (795013f51) 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 4796900 -> 4796900 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18228) Reorganize Apache C* docs in trunk branch to match the IA
[
https://issues.apache.org/jira/browse/CASSANDRA-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717825#comment-17717825
]
Stefan Miklosovic commented on CASSANDRA-18228:
---
I see there are most likely some merge conflicts not resolved properly like here
[https://github.com/apache/cassandra/pull/2294/files#diff-f5ac1a3fa235363ccbeb5a176535dd2e8f4036f0f8f24af7ab09ed3592e7c479]
check stuff like this
{code:java}
<<< HEAD{code}
> Reorganize Apache C* docs in trunk branch to match the IA
> -
>
> Key: CASSANDRA-18228
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18228
> Project: Cassandra
> Issue Type: New Feature
> Components: Documentation
>Reporter: Lorina Poland
>Assignee: Lorina Poland
>Priority: Normal
> Fix For: 5.x
>
>
> An agreed-upon Information Architecture will be used to reorganize the C* 5.0
> docs.
> IA doc:
> https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing
--
This message was sent by Atlassian 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-18228) Reorganize Apache C* docs in trunk branch to match the IA
[ https://issues.apache.org/jira/browse/CASSANDRA-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717833#comment-17717833 ] Lorina Poland commented on CASSANDRA-18228: --- Just the one, which I've fixed. I had done a search for merge conflicts, but in the `pages` directories. I wasn't expecting one in the nav.adoc. Thanks [~smiklosovic] ! > Reorganize Apache C* docs in trunk branch to match the IA > - > > Key: CASSANDRA-18228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18228 > Project: Cassandra > Issue Type: New Feature > Components: Documentation >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Fix For: 5.x > > > An agreed-upon Information Architecture will be used to reorganize the C* 5.0 > docs. > IA doc: > https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (795013f51 -> 73546f13b)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 795013f51 generate docs for 52f24b20 new 73546f13b generate docs for 52f24b20 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 (795013f51) \ N -- N -- N refs/heads/asf-staging (73546f13b) 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: site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717869#comment-17717869
]
Brad Schoening edited comment on CASSANDRA-17667 at 4/29/23 3:16 AM:
-
[~brandon.williams] Maybe the test itself is wrong, but its looking for a
quotedStringLiteral as the result
{code:java}
self.assertSequenceEqual(tokens_with_types(CqlRuleSet.lex(s)), [(s,
'quotedStringLiteral')]){code}
which works with nested quotes:
{code:java}
>>> CqlRuleSet.lex("'foo /* bar'")
[('quotedStringLiteral', "'foo /* bar'", (0, 12))]
{code}
but fails without them:
{code:java}
>>> CqlRuleSet.lex("foo /* bar")
[('identifier', 'foo', (0, 3)), ('op', '/', (4, 5)), ('star', '*', (5, 6)),
('identifier', 'bar', (7, 10))]
{code}
was (Author: bschoeni):
[~brandon.williams] Maybe the test itself is wrong, but its looking for a
quotedStringLiteral as the result
{code:java}
self.assertSequenceEqual(tokens_with_types(CqlRuleSet.lex(s)), [(s,
'quotedStringLiteral')]){code}
which works with nested quotes:
{code:java}
>>> CqlRuleSet.lex("'foo /* bar'")
[('quotedStringLiteral', "'foo /* bar'", (0, 12))]
{code}
but fails without them:
{code:java}
>>> CqlRuleSet.lex("foo /* bar")
[('identifier', 'foo', (0, 3)), ('op', '/', (4, 5)), ('star', '*', (5, 6)),
('identifier', 'bar', (7, 10))]
{code}
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
--
This message was sent by Atlassian 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-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717869#comment-17717869
]
Brad Schoening commented on CASSANDRA-17667:
[~brandon.williams] Maybe the test itself is wrong, but its looking for a
quotedStringLiteral as the result
{code:java}
self.assertSequenceEqual(tokens_with_types(CqlRuleSet.lex(s)), [(s,
'quotedStringLiteral')]){code}
which works with nested quotes:
{code:java}
>>> CqlRuleSet.lex("'foo /* bar'")
[('quotedStringLiteral', "'foo /* bar'", (0, 12))]
{code}
but fails without them:
{code:java}
>>> CqlRuleSet.lex("foo /* bar")
[('identifier', 'foo', (0, 3)), ('op', '/', (4, 5)), ('star', '*', (5, 6)),
('identifier', 'bar', (7, 10))]
{code}
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
--
This message was sent by Atlassian 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-18454) Enhance nodetool gcstats
[
https://issues.apache.org/jira/browse/CASSANDRA-18454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-18454:
---
Description:
Nodetool gcstats reports historical GC activity with Max, Total, Stdev, etc
{noformat}
% nodetool gcstats
Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed
(ms) GC Reclaimed (MB) Collections Direct Memory Bytes
11979 0 0
NaN 0 0 -1
{noformat}
* Interval (ms)
* Max GC Elapsed (ms)
* Total GC Elapsed (ms)
* Stdev GC Elapsed (ms)
* GC Reclaimed (MB)
* Collections
* Direct Memory Bytes
but in the MBean java.lang.GarbageCollector there are recent statistic in
events/second for:
* GcThreadCount
* Duration
It would be useful to see size of eden / survivor / old space and humongous
allocations.
The metrics show with jhsdb jmap would be very helpful as well, if they're
available.
[https://docs.oracle.com/en/java/javase/11/troubleshoot/diagnostic-tools.html#GUID-A69901EC-F87D-4B63-A8B7-DE8684AD4FF9]
was:
Nodetool gcstats reports historical GC activity:
* Interval (ms)
* Max GC Elapsed (ms)
* Total GC Elapsed (ms)
* Stdev GC Elapsed (ms)
* GC Reclaimed (MB)
* Collections
* Direct Memory Bytes
but in the MBean java.lang.GarbageCollector there are recent statistic in
events/second for:
* GcThreadCount
* Duration
It would be useful to see size of eden / survivor / old space and humongous
allocations.
The metrics show with jhsdb jmap would be very helpful as well, if they're
available.
https://docs.oracle.com/en/java/javase/11/troubleshoot/diagnostic-tools.html#GUID-A69901EC-F87D-4B63-A8B7-DE8684AD4FF9
> Enhance nodetool gcstats
> -
>
> Key: CASSANDRA-18454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18454
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Priority: Normal
>
> Nodetool gcstats reports historical GC activity with Max, Total, Stdev, etc
>
>
> {noformat}
> % nodetool gcstats
> Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed
> (ms) GC Reclaimed (MB) Collections Direct Memory Bytes
> 11979 0 0
> NaN 0 0 -1
> {noformat}
>
> * Interval (ms)
> * Max GC Elapsed (ms)
> * Total GC Elapsed (ms)
> * Stdev GC Elapsed (ms)
> * GC Reclaimed (MB)
> * Collections
> * Direct Memory Bytes
> but in the MBean java.lang.GarbageCollector there are recent statistic in
> events/second for:
> * GcThreadCount
> * Duration
> It would be useful to see size of eden / survivor / old space and humongous
> allocations.
> The metrics show with jhsdb jmap would be very helpful as well, if they're
> available.
> [https://docs.oracle.com/en/java/javase/11/troubleshoot/diagnostic-tools.html#GUID-A69901EC-F87D-4B63-A8B7-DE8684AD4FF9]
--
This message was sent by Atlassian 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-18454) Enhance nodetool gcstats
[
https://issues.apache.org/jira/browse/CASSANDRA-18454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-18454:
---
Description:
Nodetool gcstats provides only a brief one line output of historical GC
activity with Max, Total, Stdev, etc
{noformat}
% nodetool gcstats
Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed
(ms) GC Reclaimed (MB) Collections Direct Memory Bytes
11979 0 0
NaN 0 0 -1
{noformat}
Performance of garbage collection is such an key part of Cassandra performance
that it would be helpful to have more complete metrics with *gcstats* here.
The MBean java.lang.GarbageCollector has recent statistic which could be added
in events/second for:
* GcThreadCount
* Duration
The current size of eden / survivor / old space and humongous allocations
should be shown as well.
The metrics show with jhsdb jmap would be very helpful as well, if they're
available.
[https://docs.oracle.com/en/java/javase/11/troubleshoot/diagnostic-tools.html#GUID-A69901EC-F87D-4B63-A8B7-DE8684AD4FF9]
was:
Nodetool gcstats reports historical GC activity with Max, Total, Stdev, etc
{noformat}
% nodetool gcstats
Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed
(ms) GC Reclaimed (MB) Collections Direct Memory Bytes
11979 0 0
NaN 0 0 -1
{noformat}
* Interval (ms)
* Max GC Elapsed (ms)
* Total GC Elapsed (ms)
* Stdev GC Elapsed (ms)
* GC Reclaimed (MB)
* Collections
* Direct Memory Bytes
but in the MBean java.lang.GarbageCollector there are recent statistic in
events/second for:
* GcThreadCount
* Duration
It would be useful to see size of eden / survivor / old space and humongous
allocations.
The metrics show with jhsdb jmap would be very helpful as well, if they're
available.
[https://docs.oracle.com/en/java/javase/11/troubleshoot/diagnostic-tools.html#GUID-A69901EC-F87D-4B63-A8B7-DE8684AD4FF9]
> Enhance nodetool gcstats
> -
>
> Key: CASSANDRA-18454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18454
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Priority: Normal
>
> Nodetool gcstats provides only a brief one line output of historical GC
> activity with Max, Total, Stdev, etc
> {noformat}
> % nodetool gcstats
> Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed
> (ms) GC Reclaimed (MB) Collections Direct Memory Bytes
> 11979 0 0
> NaN 0 0 -1
> {noformat}
> Performance of garbage collection is such an key part of Cassandra
> performance that it would be helpful to have more complete metrics with
> *gcstats* here. The MBean java.lang.GarbageCollector has recent statistic
> which could be added in events/second for:
> * GcThreadCount
> * Duration
> The current size of eden / survivor / old space and humongous allocations
> should be shown as well.
> The metrics show with jhsdb jmap would be very helpful as well, if they're
> available.
> [https://docs.oracle.com/en/java/javase/11/troubleshoot/diagnostic-tools.html#GUID-A69901EC-F87D-4B63-A8B7-DE8684AD4FF9]
--
This message was sent by Atlassian 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-18454) Enhance nodetool gcstats
[
https://issues.apache.org/jira/browse/CASSANDRA-18454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717873#comment-17717873
]
Brad Schoening commented on CASSANDRA-18454:
[~smiklosovic] that's a good suggestion and a useful tool I haven't really
used, but it appears to poll continually for results and doesn't return a
specific value.
> Enhance nodetool gcstats
> -
>
> Key: CASSANDRA-18454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18454
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Priority: Normal
>
> Nodetool gcstats provides only a brief one line output of historical GC
> activity with Max, Total, Stdev, etc
> {noformat}
> % nodetool gcstats
> Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed
> (ms) GC Reclaimed (MB) Collections Direct Memory Bytes
> 11979 0 0
> NaN 0 0 -1
> {noformat}
> Performance of garbage collection is such an key part of Cassandra
> performance that it would be helpful to have more complete metrics with
> *gcstats* here. The MBean java.lang.GarbageCollector has recent statistic
> which could be added in events/second for:
> * GcThreadCount
> * Duration
> The current size of eden / survivor / old space and humongous allocations
> should be shown as well.
> The metrics show with jhsdb jmap would be very helpful as well, if they're
> available.
> [https://docs.oracle.com/en/java/javase/11/troubleshoot/diagnostic-tools.html#GUID-A69901EC-F87D-4B63-A8B7-DE8684AD4FF9]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
