[jira] [Commented] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528503#comment-17528503
]
Simon Chess commented on CASSANDRA-17221:
-
Hey [~e.dimitrova],
I rebased, deleted BigDecimalUtil.java, and I replaced it with BigDecimalMath
[https://github.com/eobermuhlner/big-math|https://github.com/eobermuhlner/big-math].
I will add documentation soon, before May 1. Let me know if I should change
anything with anything else.
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
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 (0a7ac18a -> 8cb641a1)
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 0a7ac18a generate docs for 8fd077a6 new 8cb641a1 generate docs for 8fd077a6 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 (0a7ac18a) \ N -- N -- N refs/heads/asf-staging (8cb641a1) 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 4740078 -> 4740078 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-17571) Config upper bound should be handled earlier
[ https://issues.apache.org/jira/browse/CASSANDRA-17571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528475#comment-17528475 ] Ekaterina Dimitrova commented on CASSANDRA-17571: - On the bright side, this is not a regression as we handle the old config input types in Converters(former ints cannot be set long value) so in my humble opinion even if we fix the new config upper bound after the freeze on the 1st, this is not a regression we have here and no API change will be involved. I don't plan too prolong it but if we want more time to shape the solution a bit or for final review - I think we have it. CC [~mck] in case he disagrees with this statement > Config upper bound should be handled earlier > > > Key: CASSANDRA-17571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17571 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1 > > > Config upper bound should be handled on startup/config setup and not during > conversion -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17571) Config upper bound should be handled earlier
[ https://issues.apache.org/jira/browse/CASSANDRA-17571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528472#comment-17528472 ] Ekaterina Dimitrova commented on CASSANDRA-17571: - I spent my evening again thinking about this as really those extensions become convoluted but I don't see a better way at this point. Like I can get back validation utility methods in the DD and leave considering better general handling with next version but this is error-prone. Creating a new range max annotation to all new properties in Config is not really easy option as we would need conversions... The best is to do it in the constructors at this point. I will sleep on it and finish tomorrow morning. In case someone has something better in the meantime - I am open to hear it. > Config upper bound should be handled earlier > > > Key: CASSANDRA-17571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17571 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1 > > > Config upper bound should be handled on startup/config setup and not during > conversion -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-36) Support for ErrorHandler route in Sidecar
[
https://issues.apache.org/jira/browse/CASSANDRASC-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRASC-36:
--
Description:
Add a default {{Route#failureHandler()}} that returns a {{JSON}} representation
of the error for {{io.vertx.ext.web.handler.HttpException}} as well as
{{REQUEST_TIMEOUT}} errors.
Additionally, we need to allow for custom implementations of the
{{ErrorHandler}} interface to be injected. Downstream projects can provide
custom implementations of the {{ErrorHandler}} to fit the needs of the project.
was:
Add a default {{Route#failureHandler()}} that returns a {{JSON}} representation
of the error for {{io.vertx.ext.web.handler.HttpException}}s as well as
{{REQUEST_TIMEOUT}} errors.
Additionally, we need to allow for custom implementations of the
{{ErrorHandler}} interface to be injected. Downstream projects can provide
custom implementations of the {{ErrorHandler}} to fit the needs of the project.
> Support for ErrorHandler route in Sidecar
> -
>
> Key: CASSANDRASC-36
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-36
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>
> Add a default {{Route#failureHandler()}} that returns a {{JSON}}
> representation of the error for {{io.vertx.ext.web.handler.HttpException}}
> as well as {{REQUEST_TIMEOUT}} errors.
> Additionally, we need to allow for custom implementations of the
> {{ErrorHandler}} interface to be injected. Downstream projects can provide
> custom implementations of the {{ErrorHandler}} to fit the needs of the
> project.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-36) Support for ErrorHandler route in Sidecar
[
https://issues.apache.org/jira/browse/CASSANDRASC-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRASC-36:
--
Change Category: Operability
Complexity: Normal
Component/s: Configuration
Status: Open (was: Triage Needed)
> Support for ErrorHandler route in Sidecar
> -
>
> Key: CASSANDRASC-36
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-36
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>
> Add a default {{Route#failureHandler()}} that returns a {{JSON}}
> representation of the error for {{io.vertx.ext.web.handler.HttpException}}s
> as well as {{REQUEST_TIMEOUT}} errors.
> Additionally, we need to allow for custom implementations of the
> {{ErrorHandler}} interface to be injected. Downstream projects can provide
> custom implementations of the {{ErrorHandler}} to fit the needs of the
> project.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRASC-36) Support for ErrorHandler route in Sidecar
Francisco Guerrero created CASSANDRASC-36:
-
Summary: Support for ErrorHandler route in Sidecar
Key: CASSANDRASC-36
URL: https://issues.apache.org/jira/browse/CASSANDRASC-36
Project: Sidecar for Apache Cassandra
Issue Type: Improvement
Reporter: Francisco Guerrero
Assignee: Francisco Guerrero
Add a default {{Route#failureHandler()}} that returns a {{JSON}} representation
of the error for {{io.vertx.ext.web.handler.HttpException}}s as well as
{{REQUEST_TIMEOUT}} errors.
Additionally, we need to allow for custom implementations of the
{{ErrorHandler}} interface to be injected. Downstream projects can provide
custom implementations of the {{ErrorHandler}} to fit the needs of the project.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528423#comment-17528423
]
Josh McKenzie commented on CASSANDRA-17212:
---
bq. we probably want to apply the guardrails for restrictions on IN queries
even when querying system tables, since those queries can be quite harmful
I suppose if we always have the superuser accounts excluded it effectively
gives us the same outcome - guaranteed reliable functionality for node-internal
operations. Fair point on user queries with excessive pk's in IN() being
painful; seen that a time or two.
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17563) Fix CircleCI Midres config
[ https://issues.apache.org/jira/browse/CASSANDRA-17563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17563: -- Reviewers: Ekaterina Dimitrova, Josh McKenzie (was: Ekaterina Dimitrova) > Fix CircleCI Midres config > -- > > Key: CASSANDRA-17563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17563 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1 > > > During CircleCI addition of a new job to the config, the midres file got > messy. Two of the immediate issues (but we need to verify all jobs will use > the right executors and resources): > * the new job needs to use higher parallelism as the original in-jvm job > * j8_dtests_with_vnodes should get from midres 50 large but currently > midres makes it run with 25 and medium which fails around 100 tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528404#comment-17528404 ] Brandon Williams edited comment on CASSANDRA-16456 at 4/26/22 9:08 PM: --- This lgtm and I'm +1, but I can't test Kerberos -so I'm interested to see- but I see your results. /cc [~djoshi] and [~paulo] if you want to do a final pass too. was (Author: brandon.williams): This lgtm and I'm +1, but I can't test Kerberos -so I'm interested to see- but I see your results. /cc [~djoshi] and [~paulo] if you want do to a final pass too. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528412#comment-17528412 ] Stefan Miklosovic commented on CASSANDRA-16456: --- Thanks [~paulo] for letting me know you wont make it so I do not need to wait unnecessarilly. I ll wait for Dinesh if he is up to it and I ll sleep on it and will eventually merge. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528408#comment-17528408 ] Paulo Motta commented on CASSANDRA-16456: - bq. [~paulo] if you want do to a final pass too. Thanks for the ping. Unfortunately I'll not be able to review this before merge, so don't wait on me. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16456: Reviewers: Brandon Williams, Dinesh Joshi, Stefan Miklosovic (was: Brandon Williams, Dinesh Joshi, Paulo Motta, Stefan Miklosovic) > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528404#comment-17528404 ] Brandon Williams edited comment on CASSANDRA-16456 at 4/26/22 8:46 PM: --- This lgtm and I'm +1, but I can't test Kerberos -so I'm interested to see- but I see your results. /cc [~djoshi] and [~paulo] if you want do to a final pass too. was (Author: brandon.williams): This lgtm and I'm +1, but I can't test Kerberos so I'm interested to see your results. /cc [~djoshi] and [~paulo] if you want do to a final pass too. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528404#comment-17528404 ] Brandon Williams commented on CASSANDRA-16456: -- This lgtm and I'm +1, but I can't test Kerberos so I'm interested to see your results. /cc [~djoshi] and [~paulo] if you want do to a final pass too. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528400#comment-17528400 ] Stefan Miklosovic commented on CASSANDRA-16456: --- I am + 1, works fine, checked against Kerberos using SaslAuthProvider from the driver from cassandra.auth module. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) - 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 (5ee940df -> 0a7ac18a)
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 5ee940df generate docs for 8fd077a6 new 0a7ac18a generate docs for 8fd077a6 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 (5ee940df) \ N -- N -- N refs/heads/asf-staging (0a7ac18a) 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: .../cassandra/configuration/cass_yaml_file.html| 12 .../cassandra/configuration/cass_yaml_file.html| 12 .../cassandra/configuration/cass_yaml_file.html| 12 content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078 bytes 5 files changed, 37 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528376#comment-17528376 ] Doug Whitfield edited comment on CASSANDRA-16619 at 4/26/22 7:47 PM: - oops, I was wanting to do a search for things since 3.11.9 but I changed this bug. I clearly need more coffee. going to see if I can figure out what it was. UPDATE: Unfortunately, this is not on Wayback...digging. UPDATE: History tab to the rescue was (Author: douglasawh): oops, I was wanting to do a search for things since 3.11.9 but I changed this bug. I clearly need more coffee. going to see if I can figure out what it was. UPDATE: Unfortunately, this is not on Wayback...digging. > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0 > > Time Spent: 2h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17579) WEBSITE - April 2022 blog "Liquibase is Ready to Support Cassandra 4.0 Users" + Liquidbase case study
[ https://issues.apache.org/jira/browse/CASSANDRA-17579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17579: - Fix Version/s: 4.0.x (was: NA) Impacts: Docs (was: None) > WEBSITE - April 2022 blog "Liquibase is Ready to Support Cassandra 4.0 Users" > + Liquidbase case study > - > > Key: CASSANDRA-17579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17579 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Fix For: 4.0.x > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Liquibase is Ready to Support Cassandra 4.0 Users" and adding the > Liquidbase case study to the website. > If this blog + case study cannot be published by the *April 28, 2022 publish > date*, please contact me, suggest changes, or correct the date when possible > in the pull request for the appropriate time that the blog will go live (on > both the blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Whitfield updated CASSANDRA-16619: --- Since Version: 0.3 (was: 3.11.9) > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0 > > Time Spent: 2h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528376#comment-17528376 ] Doug Whitfield edited comment on CASSANDRA-16619 at 4/26/22 7:45 PM: - oops, I was wanting to do a search for things since 3.11.9 but I changed this bug. I clearly need more coffee. going to see if I can figure out what it was. UPDATE: Unfortunately, this is not on Wayback...digging. was (Author: douglasawh): oops, I was wanting to do a search for things since 3.11.9 but I changed this bug. I clearly need more coffee. going to see if I can figure out what it was. > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0 > > Time Spent: 2h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528376#comment-17528376 ] Doug Whitfield commented on CASSANDRA-16619: oops, I was wanting to do a search for things since 3.11.9 but I changed this bug. I clearly need more coffee. going to see if I can figure out what it was. > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0 > > Time Spent: 2h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17579) WEBSITE - April 2022 blog "Liquibase is Ready to Support Cassandra 4.0 Users" + Liquidbase case study
[ https://issues.apache.org/jira/browse/CASSANDRA-17579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17579: - Authors: Chris Thornett Fix Version/s: NA Test and Documentation Plan: * Add blog post titled "Liquibase is Ready to Support Cassandra 4.0 Users" * Modify blog index page * Add Liquidbase case study * Modify case studies page was: * Add blog post * Modify blog index page Description: This ticket is to capture the work associated with publishing the April 2022 blog "Liquibase is Ready to Support Cassandra 4.0 Users" and adding the Liquidbase case study to the website. If this blog + case study cannot be published by the *April 28, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file). was: This ticket is to capture the work associated with publishing the April 2022 blog If this blog cannot be published by the *April 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file). > WEBSITE - April 2022 blog "Liquibase is Ready to Support Cassandra 4.0 Users" > + Liquidbase case study > - > > Key: CASSANDRA-17579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17579 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Liquibase is Ready to Support Cassandra 4.0 Users" and adding the > Liquidbase case study to the website. > If this blog + case study cannot be published by the *April 28, 2022 publish > date*, please contact me, suggest changes, or correct the date when possible > in the pull request for the appropriate time that the blog will go live (on > both the blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Whitfield updated CASSANDRA-16619: --- Since Version: 3.11.9 (was: 0.3) > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0 > > Time Spent: 2h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17579) WEBSITE - April 2022 blog "Liquibase is Ready to Support Cassandra 4.0 Users" + Liquidbase case study
[ https://issues.apache.org/jira/browse/CASSANDRA-17579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17579: - Summary: WEBSITE - April 2022 blog "Liquibase is Ready to Support Cassandra 4.0 Users" + Liquidbase case study (was: WEBSITE - April 2022 blog) > WEBSITE - April 2022 blog "Liquibase is Ready to Support Cassandra 4.0 Users" > + Liquidbase case study > - > > Key: CASSANDRA-17579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17579 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with publishing the April 2022 > blog > If this blog cannot be published by the *April 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17571) Config upper bound should be handled earlier
[ https://issues.apache.org/jira/browse/CASSANDRA-17571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528372#comment-17528372 ] Ekaterina Dimitrova commented on CASSANDRA-17571: - Thanks, looking forward for your feedback. I am on standby ready to incorporate any feedback and move the former int config to the extended classes before the 1st is here. Unfortunately, it will become noisy but it should be quick type change, using the old methods. > Config upper bound should be handled earlier > > > Key: CASSANDRA-17571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17571 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1 > > > Config upper bound should be handled on startup/config setup and not during > conversion -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528334#comment-17528334
]
Savni Nagarkar edited comment on CASSANDRA-17212 at 4/26/22 5:52 PM:
-
||min_rf||ci||
|[GitHub|https://github.com/apache/cassandra/pull/1583/]|[j8|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/a6691dc4-6512-4c66-b175-7e275e2c9343]
[j11|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/21882e40-7a6c-478c-aa0e-371b9a0aaa05]|
was (Author: JIRAUSER284678):
||min_rf||ci||
|[GitHub|https://github.com/apache/cassandra/pull/1583/]|[j8|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/a6691dc4-6512-4c66-b175-7e275e2c9343]
[j11\|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/21882e40-7a6c-478c-aa0e-371b9a0aaa05
]|
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528334#comment-17528334
]
Savni Nagarkar edited comment on CASSANDRA-17212 at 4/26/22 5:51 PM:
-
||min_rf||ci||
|[GitHub|https://github.com/apache/cassandra/pull/1583/]|[j8|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/a6691dc4-6512-4c66-b175-7e275e2c9343]
[j11\|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/21882e40-7a6c-478c-aa0e-371b9a0aaa05
]|
was (Author: JIRAUSER284678):
||min_rf||ci||
|[GitHub\|https://github.com/apache/cassandra/pull/1583/]|[j8
|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/a6691dc4-6512-4c66-b175-7e275e2c9343][j11\|[https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/21882e40-7a6c-478c-aa0e-371b9a0aaa05]]|
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528334#comment-17528334
]
Savni Nagarkar commented on CASSANDRA-17212:
||min_rf||ci||
|[GitHub\|https://github.com/apache/cassandra/pull/1583/]|[j8
|https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/a6691dc4-6512-4c66-b175-7e275e2c9343][j11\|[https://app.circleci.com/pipelines/github/thingtwin1/cassandra/44/workflows/21882e40-7a6c-478c-aa0e-371b9a0aaa05]]|
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17370) Add flag enabling operators to restrict use of ALLOW FILTERING in queries
[ https://issues.apache.org/jira/browse/CASSANDRA-17370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17370: -- Fix Version/s: 4.1 (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/f444c4028680c78b6167161833d6564c3557618f Resolution: Fixed Status: Resolved (was: Ready to Commit) > Add flag enabling operators to restrict use of ALLOW FILTERING in queries > - > > Key: CASSANDRA-17370 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17370 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics, Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.1 > > Time Spent: 3.5h > Remaining Estimate: 0h > > This ticket adds the ability for operators to disallow use of ALLOW FILTERING > predicates in CQL SELECT statements. As queries that ALLOW FILTERING can > place additional load on the database, the flag enables operators to provide > tighter bounds on performance guarantees. The patch includes a new yaml > property, as well as a hot property enabling the value to be modified via JMX > at runtime. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17370) Add flag enabling operators to restrict use of ALLOW FILTERING in queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528327#comment-17528327
]
Andres de la Peña commented on CASSANDRA-17370:
---
Committed to {{trunk}} as
[f444c4028680c78b6167161833d6564c3557618f|https://github.com/apache/cassandra/commit/f444c4028680c78b6167161833d6564c3557618f].
> Add flag enabling operators to restrict use of ALLOW FILTERING in queries
> -
>
> Key: CASSANDRA-17370
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17370
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics, Feature/Guardrails
>Reporter: Savni Nagarkar
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> This ticket adds the ability for operators to disallow use of ALLOW FILTERING
> predicates in CQL SELECT statements. As queries that ALLOW FILTERING can
> place additional load on the database, the flag enables operators to provide
> tighter bounds on performance guarantees. The patch includes a new yaml
> property, as well as a hot property enabling the value to be modified via JMX
> at runtime.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Add guardrail to disallow querying with ALLOW FILTERING
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new f444c40286 Add guardrail to disallow querying with ALLOW FILTERING
f444c40286 is described below
commit f444c4028680c78b6167161833d6564c3557618f
Author: Savni Nagarkar
AuthorDate: Thu Feb 17 13:29:58 2022 -0600
Add guardrail to disallow querying with ALLOW FILTERING
patch by Savni Nagarkar; reviewed by Andres de la Peña, David Capwell and
Josh McKenzie for CASSANDRA-17370
---
CHANGES.txt| 1 +
NEWS.txt | 1 +
conf/cassandra.yaml| 2 +
src/java/org/apache/cassandra/config/Config.java | 1 +
.../apache/cassandra/config/GuardrailsOptions.java | 14
.../cassandra/cql3/statements/SelectStatement.java | 4 +-
.../apache/cassandra/db/guardrails/Guardrails.java | 20 +
.../cassandra/db/guardrails/GuardrailsConfig.java | 7 ++
.../cassandra/db/guardrails/GuardrailsMBean.java | 14
.../db/guardrails/GuardrailAllowFilteringTest.java | 94 ++
10 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 9410f075bc..4ae12a7c97 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Add guardrail to disallow querying with ALLOW FILTERING (CASSANDRA-17370)
* Enhance SnakeYAML properties to be reusable outside of YAML parsing,
support camel case conversion to snake case, and add support to ignore
properties (CASSANDRA-17166)
* nodetool compact should support using a key string to find the range to
avoid operators having to manually do this (CASSANDRA-17537)
* Add guardrail for data disk usage (CASSANDRA-17150)
diff --git a/NEWS.txt b/NEWS.txt
index 72c95e00c4..97bfd331c4 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -84,6 +84,7 @@ New features
- Whether GROUP BY queries are allowed.
- Whether the creation of secondary indexes is allowed.
- Whether the creation of uncompressed tables is allowed.
+- Whether querying with ALLOW FILTERING is allowed.
- Add support for the use of pure monotonic functions on the last
attribute of the GROUP BY clause.
- Add floor functions that can be use to group by time range.
- Support for native transport rate limiting via
native_transport_rate_limiting_enabled and
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index b28f4388f5..f6f0a3ccad 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -1664,6 +1664,8 @@ drop_compact_storage_enabled: false
# The two thresholds default to -1 to disable.
# items_per_collection_warn_threshold: -1
# items_per_collection_fail_threshold: -1
+# Guardrail to allow/disallow querying with ALLOW FILTERING. Defaults to true.
+# allow_filtering_enabled: true
# Guardrail to warn or fail when creating a user-defined-type with more fields
in than threshold.
# Default -1 to disable.
# fields_per_udt_warn_threshold: -1
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index 2f339418b1..a3d6348fa1 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -812,6 +812,7 @@ public class Config
public volatile boolean uncompressed_tables_enabled = true;
public volatile boolean compact_tables_enabled = true;
public volatile boolean read_before_write_list_operations_enabled = true;
+public volatile boolean allow_filtering_enabled = true;
public volatile DataStorageSpec collection_size_warn_threshold = null;
public volatile DataStorageSpec collection_size_fail_threshold = null;
public volatile int items_per_collection_warn_threshold = -1;
diff --git a/src/java/org/apache/cassandra/config/GuardrailsOptions.java
b/src/java/org/apache/cassandra/config/GuardrailsOptions.java
index 160906353e..d32f3b1bc6 100644
--- a/src/java/org/apache/cassandra/config/GuardrailsOptions.java
+++ b/src/java/org/apache/cassandra/config/GuardrailsOptions.java
@@ -385,6 +385,20 @@ public class GuardrailsOptions implements GuardrailsConfig
x ->
config.read_before_write_list_operations_enabled = x);
}
+@Override
+public boolean getAllowFilteringEnabled()
+{
+return config.allow_filtering_enabled;
+}
+
+public void setAllowFilteringEnabled(boolean enabled)
+{
+updatePropertyWithLogging("allow_filtering_enabled",
+ enabled,
+ () -> config.allow_filtering_enabled,
+ x -> config.allow_filtering_enabled = x);
+}
+
@Override
public int getInSelectCartesianProductWarnThreshold()
{
diff --git
[jira] [Commented] (CASSANDRA-17370) Add flag enabling operators to restrict use of ALLOW FILTERING in queries
[ https://issues.apache.org/jira/browse/CASSANDRA-17370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528317#comment-17528317 ] Andres de la Peña commented on CASSANDRA-17370: --- One last CI run after rebasing: ||Patch||CI|| |[trunk|https://github.com/adelapena/cassandra/commit/14edb9f1b78381242cf2638cfff189e399af7630]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1509/workflows/1b23e520-34b0-4501-8480-1dfe926cff09] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1509/workflows/4f51b970-4a7a-442f-974c-c2ad55aece4b]| It looks clean to me, all the failing tests are well-known. > Add flag enabling operators to restrict use of ALLOW FILTERING in queries > - > > Key: CASSANDRA-17370 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17370 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics, Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > Time Spent: 3.5h > Remaining Estimate: 0h > > This ticket adds the ability for operators to disallow use of ALLOW FILTERING > predicates in CQL SELECT statements. As queries that ALLOW FILTERING can > place additional load on the database, the flag enables operators to provide > tighter bounds on performance guarantees. The patch includes a new yaml > property, as well as a hot property enabling the value to be modified via JMX > at runtime. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17370) Add flag enabling operators to restrict use of ALLOW FILTERING in queries
[ https://issues.apache.org/jira/browse/CASSANDRA-17370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17370: -- Status: Ready to Commit (was: Review In Progress) > Add flag enabling operators to restrict use of ALLOW FILTERING in queries > - > > Key: CASSANDRA-17370 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17370 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics, Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > Time Spent: 3.5h > Remaining Estimate: 0h > > This ticket adds the ability for operators to disallow use of ALLOW FILTERING > predicates in CQL SELECT statements. As queries that ALLOW FILTERING can > place additional load on the database, the flag enables operators to provide > tighter bounds on performance guarantees. The patch includes a new yaml > property, as well as a hot property enabling the value to be modified via JMX > at runtime. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17566) Fix flaky test - org.apache.cassandra.distributed.test.repair.ForceRepairTest.force
[
https://issues.apache.org/jira/browse/CASSANDRA-17566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528283#comment-17528283
]
Brandon Williams edited comment on CASSANDRA-17566 at 4/26/22 4:41 PM:
---
I haven't been able to reproduce this exact error, but it looks like it could
be a timeout, and timeouts I can reproduce with this test on a machine with
plenty of resources. I went back to when this test was committed, and this
behavior has been there since inception:
{noformat}
[junit-timeout] Testcase:
org.apache.cassandra.distributed.test.repair.ForceRepairTest:forceWithDifference:
Caused an ERROR
[junit-timeout] Timeout occurred. Please note the time in the report does not
reflect the time until the timeout.
[junit-timeout] junit.framework.AssertionFailedError: Timeout occurred. Please
note the time in the report does not reflect the time until the timeout.
[junit-timeout] at java.util.Vector.forEach(Vector.java:1277)
[junit-timeout] at java.util.Vector.forEach(Vector.java:1277)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test
org.apache.cassandra.distributed.test.repair.ForceRepairTest FAILED (timeout)
{noformat}
I added some logging around the [args
loop|https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/test/repair/ForceRepairTest.java#L83],
which shows that sometimes there's a delay in the [nodetool
failure|https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/test/repair/ForceRepairTest.java#L95]:
{noformat}
INFO [main] 2022-04-26 10:41:32,673 beginning --full
INFO [main] 2022-04-26 10:41:32,686 failure finished
INFO [main] 2022-04-26 10:41:32,723 success finished
INFO [main] 2022-04-26 10:41:32,724 finished --full
INFO [main] 2022-04-26 10:41:32,724 beginning --preview
INFO [main] 2022-04-26 10:46:32,734 failure finished
INFO [main] 2022-04-26 10:46:32,794 success finished
INFO [main] 2022-04-26 10:46:32,796 finished --preview
INFO [main] 2022-04-26 10:46:32,796 beginning --validate
INFO [main] 2022-04-26 10:51:32,803 failure finished
INFO [main] 2022-04-26 10:51:32,840 success finished
INFO [main] 2022-04-26 10:51:32,848 finished --validate
{noformat}
which is interestingly always 5 minutes. Here is node1's relevant log for the
preview at 10:41:32,724:
{noformat}
DEBUG [node1_Repair#6:1] node1 2022-04-26 10:41:32,726 [preview repair
#5906ca00-c577-11ec-b392-2548bbd24495] session task executor shut down
gracefully
INFO [node1_Repair-Task:1] node1 2022-04-26 10:41:32,732 Starting repair
command #7 (590b0fc0-c577-11ec-b392-2548bbd24495), repairing keyspace
distributed_test_keyspace with repair options (parallelism: parallel, primary
range: false, incremental: true, job threads: 1, ColumnFamilies: [],
dataCenters: [], hosts: [], previewKind: UNREPAIRED, # of ranges: 3, pull
repair: false, force repair: false, optimise streams: false, ignore
unreplicated keyspaces: false, repairPaxos: false, paxosOnly: false)
ERROR [node1_Repair-Task:1] node1 2022-04-26 10:41:32,733 Repair
590b0fc0-c577-11ec-b392-2548bbd24495 failed:
java.lang.RuntimeException: Endpoint not alive: /127.0.0.2:7012
at
org.apache.cassandra.service.ActiveRepairService.failRepair(ActiveRepairService.java:726)
at
org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:652)
at
org.apache.cassandra.repair.RepairRunnable.prepare(RepairRunnable.java:401)
at
org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:280)
at
org.apache.cassandra.repair.RepairRunnable.run(RepairRunnable.java:249)
at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
INFO [node1_Repair-Task:1] node1 2022-04-26 10:41:32,733 [preview repair
#590b0fc0-c577-11ec-b392-2548bbd24495]Repair command #7 finished with error
{noformat}
which indicates it should have returned the failure at 10:41:32,733, but this
doesn't happen for 5 minutes, and the only thing in node1's log is:
{noformat}
INFO [node1_Messaging-EventLoop-3-1] node1 2022-04-26 10:42:01,657
[jira] [Updated] (CASSANDRA-17524) Schema mutations may not be completed on drain
[
https://issues.apache.org/jira/browse/CASSANDRA-17524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-17524:
-
Status: Ready to Commit (was: Review In Progress)
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|cassandra-3.0|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17524-cassandra-3.0-B2CD88DD-CD43-41E1-AC67-692E1D870936]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17524-cassandra-3.0-B2CD88DD-CD43-41E1-AC67-692E1D870936]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1632/]|
|cassandra-3.11|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17524-cassandra-3.11-B2CD88DD-CD43-41E1-AC67-692E1D870936]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17524-cassandra-3.11-B2CD88DD-CD43-41E1-AC67-692E1D870936]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1633/]|
|cassandra-4.0|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17524-cassandra-4.0-B2CD88DD-CD43-41E1-AC67-692E1D870936]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17524-cassandra-4.0-B2CD88DD-CD43-41E1-AC67-692E1D870936]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1634/]|
|trunk|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17524-trunk-B2CD88DD-CD43-41E1-AC67-692E1D870936]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17524-trunk-B2CD88DD-CD43-41E1-AC67-692E1D870936]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1635/]|
> Schema mutations may not be completed on drain
> --
>
> Key: CASSANDRA-17524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17524
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.1, 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The drain logic (invoked explicitly with nodetool or from the JVM
> shutdown hook) closes down executor stages that can create mutations (counter,
> view, mutation) before closing down the commitlog. The gossip
> stage also commits schema mutations, and should be treated the same way.
> The messaging service is shut down as part of drain, so there should be
> no new Gossip messages received, however any messages still queued
> in the executor could still run after the commitlog allocator is shut down as
> part of drain, causing the gossip stage thread to hang indefinitely waiting
> for a new segment that never arrives.
> Here is an example from an in-JVM dtest, showing an update to the peers table
> as it shuts down.
> {code:java}
> park:-1, Unsafe (jdk.internal.misc)
> park:323, LockSupport (java.util.concurrent.locks)
> await:289, WaitQueue$Standard$AbstractSignal
> (org.apache.cassandra.utils.concurrent)
> await:282, WaitQueue$Standard$AbstractSignal
> (org.apache.cassandra.utils.concurrent)
> awaitUninterruptibly:186, Awaitable$Defaults
> (org.apache.cassandra.utils.concurrent)
> awaitUninterruptibly:259, Awaitable$AbstractAwaitable
> (org.apache.cassandra.utils.concurrent)
> awaitAvailableSegment:283, AbstractCommitLogSegmentManager
> (org.apache.cassandra.db.commitlog)
> advanceAllocatingFrom:257, AbstractCommitLogSegmentManager
> (org.apache.cassandra.db.commitlog)
> allocate:55, CommitLogSegmentManagerStandard
> (org.apache.cassandra.db.commitlog)
> add:282, CommitLog (org.apache.cassandra.db.commitlog)
> beginWrite:50, CassandraKeyspaceWriteHandler (org.apache.cassandra.db)
> applyInternal:622, Keyspace (org.apache.cassandra.db)
> apply:506, Keyspace (org.apache.cassandra.db)
> apply:215, Mutation (org.apache.cassandra.db)
> apply:220, Mutation (org.apache.cassandra.db)
> apply:229, Mutation (org.apache.cassandra.db)
> executeInternalWithoutCondition:644, ModificationStatement
> (org.apache.cassandra.cql3.statements)
> executeLocally:635, ModificationStatement
> (org.apache.cassandra.cql3.statements)
> executeInternal:431, QueryProcessor (org.apache.cassandra.cql3)
> updateTokens:804, SystemKeyspace (org.apache.cassandra.db)
> updateTokenMetadata:2941, StorageService (org.apache.cassandra.service)
> handleStateNormal:3057, StorageService (org.apache.cassandra.service)
> onChange:2498, StorageService (org.apache.cassandra.service)
> markAsShutdown:607, Gossiper (org.apache.cassandra.gms)
> doVerb:39, GossipShutdownVerbHandler (org.apache.cassandra.gms)
> lambda$new$0:78,
[jira] [Commented] (CASSANDRA-17566) Fix flaky test - org.apache.cassandra.distributed.test.repair.ForceRepairTest.force
[
https://issues.apache.org/jira/browse/CASSANDRA-17566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528283#comment-17528283
]
Brandon Williams commented on CASSANDRA-17566:
--
I haven't been able to reproduce this exact error, but it looks like it could
be a timeout, and timeouts I can reproduce with this test on a machine with
plenty of resources. I went back to when this test was committed, and this
behavior has been there since inception:
{noformat}
[junit-timeout] Testcase:
org.apache.cassandra.distributed.test.repair.ForceRepairTest:forceWithDifference:
Caused an ERROR
[junit-timeout] Timeout occurred. Please note the time in the report does not
reflect the time until the timeout.
[junit-timeout] junit.framework.AssertionFailedError: Timeout occurred. Please
note the time in the report does not reflect the time until the timeout.
[junit-timeout] at java.util.Vector.forEach(Vector.java:1277)
[junit-timeout] at java.util.Vector.forEach(Vector.java:1277)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test
org.apache.cassandra.distributed.test.repair.ForceRepairTest FAILED (timeout)
{noformat}
I added some logging around the [args loop], which shows that sometimes there's
a delay in the ]nodetool failure]:
{noformat}
INFO [main] 2022-04-26 10:41:32,673 beginning --full
INFO [main] 2022-04-26 10:41:32,686 failure finished
INFO [main] 2022-04-26 10:41:32,723 success finished
INFO [main] 2022-04-26 10:41:32,724 finished --full
INFO [main] 2022-04-26 10:41:32,724 beginning --preview
INFO [main] 2022-04-26 10:46:32,734 failure finished
INFO [main] 2022-04-26 10:46:32,794 success finished
INFO [main] 2022-04-26 10:46:32,796 finished --preview
INFO [main] 2022-04-26 10:46:32,796 beginning --validate
INFO [main] 2022-04-26 10:51:32,803 failure finished
INFO [main] 2022-04-26 10:51:32,840 success finished
INFO [main] 2022-04-26 10:51:32,848 finished --validate
{noformat}
which is interestingly always 5 minutes. Here is node1's relevant log for the
preview at 10:41:32,724:
{noformat}
DEBUG [node1_Repair#6:1] node1 2022-04-26 10:41:32,726 [preview repair
#5906ca00-c577-11ec-b392-2548bbd24495] session task executor shut down
gracefully
INFO [node1_Repair-Task:1] node1 2022-04-26 10:41:32,732 Starting repair
command #7 (590b0fc0-c577-11ec-b392-2548bbd24495), repairing keyspace
distributed_test_keyspace with repair options (parallelism: parallel, primary
range: false, incremental: true, job threads: 1, ColumnFamilies: [],
dataCenters: [], hosts: [], previewKind: UNREPAIRED, # of ranges: 3, pull
repair: false, force repair: false, optimise streams: false, ignore
unreplicated keyspaces: false, repairPaxos: false, paxosOnly: false)
ERROR [node1_Repair-Task:1] node1 2022-04-26 10:41:32,733 Repair
590b0fc0-c577-11ec-b392-2548bbd24495 failed:
java.lang.RuntimeException: Endpoint not alive: /127.0.0.2:7012
at
org.apache.cassandra.service.ActiveRepairService.failRepair(ActiveRepairService.java:726)
at
org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:652)
at
org.apache.cassandra.repair.RepairRunnable.prepare(RepairRunnable.java:401)
at
org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:280)
at
org.apache.cassandra.repair.RepairRunnable.run(RepairRunnable.java:249)
at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
INFO [node1_Repair-Task:1] node1 2022-04-26 10:41:32,733 [preview repair
#590b0fc0-c577-11ec-b392-2548bbd24495]Repair command #7 finished with error
{noformat}
which indicates it should have returned the failure at 10:41:32,733, but this
doesn't happen for 5 minutes, and the only thing in node1's log is:
{noformat}
INFO [node1_Messaging-EventLoop-3-1] node1 2022-04-26 10:42:01,657
/127.0.0.1:7012->/127.0.0.2:7012-URGENT_MESSAGES-[no-channel] failed to connect
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused:
/127.0.0.2:7012
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at
[jira] [Comment Edited] (CASSANDRA-17582) Add missing information about whether to drop sstables or not when dropping schema objects
[ https://issues.apache.org/jira/browse/CASSANDRA-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528145#comment-17528145 ] Jacek Lewandowski edited comment on CASSANDRA-17582 at 4/26/22 3:54 PM: https://github.com/apache/cassandra/pull/1591 https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/215/workflows/032d9736-69e7-46e3-a61c-d63c87df3699 https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/215/workflows/c43af657-f59b-480c-b108-091d6afe4dc1 was (Author: jlewandowski): https://github.com/apache/cassandra/pull/1591 https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/215/workflows/032d9736-69e7-46e3-a61c-d63c87df3699 > Add missing information about whether to drop sstables or not when dropping > schema objects > -- > > Key: CASSANDRA-17582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17582 > Project: Cassandra > Issue Type: Task > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.x > > > This is the missed piece in SchemaChangeListener - when the implementation of > SchemaUpdateHandler decides to say drop a table but keep sstables, that > information about not-dropping sstables is not propagated to the > SchemaChangeListener -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528250#comment-17528250
]
Marcus Eriksson edited comment on CASSANDRA-17453 at 4/26/22 3:33 PM:
--
bumping the timeouts seem to fix this
100x run:
https://app.circleci.com/pipelines/github/krummas/cassandra/802/workflows/4ff6be03-bcfc-4aa8-8532-a7e1d340f2c9/jobs/6298
https://github.com/krummas/cassandra/commit/b30628db07021437ed48bf32e86ef5b7115b1609
was (Author: krummas):
bumping the timeouts seem to fix this
https://app.circleci.com/pipelines/github/krummas/cassandra/802/workflows/4ff6be03-bcfc-4aa8-8532-a7e1d340f2c9/jobs/6298
https://github.com/krummas/cassandra/commit/b30628db07021437ed48bf32e86ef5b7115b1609
> flaky in jvm CasCriticalSectionTest.criticalSectionTest
> ---
>
> Key: CASSANDRA-17453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17453
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> From CI, there are variations of this error:
> {code:java}
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 0 of 3 required responses after 0 contention retries at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
> org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17453) flaky in jvm CasCriticalSectionTest.criticalSectionTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17453:
Test and Documentation Plan: repeated cci run
Status: Patch Available (was: Open)
bumping the timeouts seem to fix this
https://app.circleci.com/pipelines/github/krummas/cassandra/802/workflows/4ff6be03-bcfc-4aa8-8532-a7e1d340f2c9/jobs/6298
https://github.com/krummas/cassandra/commit/b30628db07021437ed48bf32e86ef5b7115b1609
> flaky in jvm CasCriticalSectionTest.criticalSectionTest
> ---
>
> Key: CASSANDRA-17453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17453
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> From CI, there are variations of this error:
> {code:java}
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 0 of 3 required responses after 0 contention retries at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at
> org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16843) List snapshots of dropped tables
[
https://issues.apache.org/jira/browse/CASSANDRA-16843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528209#comment-17528209
]
Paulo Motta commented on CASSANDRA-16843:
-
Submitted CI with intermediate patch to gather initial results:
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1631/
> List snapshots of dropped tables
>
>
> Key: CASSANDRA-16843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16843
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: James Brown
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Auto snapshots from dropped tables don't seem to show up in {{nodetool
> listsnapshots}} (even though they do get cleared by {{nodetool
> clearsnapshot}}). This makes them kind of annoying to clean up, since you
> need to muck about in the data directory to find them.
> Erick on the mailing list said that this seems to be an oversight and that
> clearsnapshot was fixed by
> [CASSANDRA-6418|https://issues.apache.org/jira/browse/CASSANDRA-6418].
> I reproduced this both on 3.11.11 and 4.0.0.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17582) Add missing information about whether to drop sstables or not when dropping schema objects
[ https://issues.apache.org/jira/browse/CASSANDRA-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528145#comment-17528145 ] Jacek Lewandowski edited comment on CASSANDRA-17582 at 4/26/22 2:06 PM: https://github.com/apache/cassandra/pull/1591 https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/215/workflows/032d9736-69e7-46e3-a61c-d63c87df3699 was (Author: jlewandowski): https://github.com/apache/cassandra/pull/1591 > Add missing information about whether to drop sstables or not when dropping > schema objects > -- > > Key: CASSANDRA-17582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17582 > Project: Cassandra > Issue Type: Task > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.x > > > This is the missed piece in SchemaChangeListener - when the implementation of > SchemaUpdateHandler decides to say drop a table but keep sstables, that > information about not-dropping sstables is not propagated to the > SchemaChangeListener -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17556) jackson-databind 2.13.2 is vulnerable to CVE-2020-36518
[ https://issues.apache.org/jira/browse/CASSANDRA-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528186#comment-17528186 ] Berenguer Blasi commented on CASSANDRA-17556: - The usages I've found are auxiliary for logging with the CQL JSON support being the only one worth mentioning. I'm trying to think of more things we could do or check but nothing is coming up so far. > jackson-databind 2.13.2 is vulnerable to CVE-2020-36518 > --- > > Key: CASSANDRA-17556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17556 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.13, 4.1, 4.0.4 > > > Seems like it's technically possible to cause a DoS with nested json. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17556) jackson-databind 2.13.2 is vulnerable to CVE-2020-36518
[ https://issues.apache.org/jira/browse/CASSANDRA-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528169#comment-17528169 ] Ekaterina Dimitrova commented on CASSANDRA-17556: - My only question really was - is there anything we need to know around the usages or test and to remind of the old issue on the hot path. That’s it > jackson-databind 2.13.2 is vulnerable to CVE-2020-36518 > --- > > Key: CASSANDRA-17556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17556 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.13, 4.1, 4.0.4 > > > Seems like it's technically possible to cause a DoS with nested json. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-16310:
Source Control Link:
https://github.com/apache/cassandra/commit/545809616c92a91e4c39d1eedfa65800f25a2a93
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
And committed with the nits fixed, thanks!
tests:
https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F16310=all
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.1
>
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Track top partitions by size and tombstone count
This is an automated email from the ASF dual-hosted git repository.
marcuse pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 545809616c Track top partitions by size and tombstone count
545809616c is described below
commit 545809616c92a91e4c39d1eedfa65800f25a2a93
Author: Marcus Eriksson
AuthorDate: Thu Dec 3 11:29:38 2020 +0100
Track top partitions by size and tombstone count
Patch by marcuse; reviewed by David Capwell and Yifan Cai for
CASSANDRA-16310
---
NEWS.txt | 4 +
src/java/org/apache/cassandra/config/Config.java | 6 +
.../cassandra/config/DatabaseDescriptor.java | 45 +++
.../org/apache/cassandra/db/ColumnFamilyStore.java | 43 ++-
.../cassandra/db/ColumnFamilyStoreMBean.java | 5 +
.../org/apache/cassandra/db/SystemKeyspace.java| 66 +++-
.../db/compaction/CompactionIterator.java | 13 +-
.../cassandra/db/compaction/CompactionManager.java | 6 +-
.../db/repair/CassandraTableRepairManager.java | 5 +-
.../db/repair/CassandraValidationIterator.java | 9 +-
.../cassandra/metrics/TopPartitionTracker.java | 408 +
.../cassandra/repair/TableRepairManager.java | 3 +-
.../apache/cassandra/repair/ValidationManager.java | 32 +-
.../org/apache/cassandra/repair/Validator.java | 12 +-
.../apache/cassandra/service/StorageService.java | 54 +++
.../cassandra/service/StorageServiceMBean.java | 9 +
.../cassandra/tools/nodetool/stats/StatsTable.java | 5 +
.../tools/nodetool/stats/TableStatsHolder.java | 27 ++
.../tools/nodetool/stats/TableStatsPrinter.java| 18 +
.../distributed/test/TopPartitionsTest.java| 317
.../cassandra/db/TopPartitionTrackerTest.java | 334 +
.../org/apache/cassandra/repair/ValidatorTest.java | 2 +-
22 files changed, 1403 insertions(+), 20 deletions(-)
diff --git a/NEWS.txt b/NEWS.txt
index fd31e06c93..72c95e00c4 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -99,6 +99,10 @@ New features
any writes to the CDC-enabled tables will be blocked when reaching to
the limit for CDC data on disk, which is the
existing and the default behavior. Setting to false, the writes to the
CDC-enabled tables will be accepted and
the oldest CDC data on disk will be deleted to ensure the size
constraint.
+- Top partitions based on partition size or tombstone count are now
tracked per table. These partitions are stored
+ in a new system.top_partitions table and exposed via JMX and nodetool
tablestats. The partitions are tracked
+ during full or validation repairs but not incremental ones since those
don't include all sstables and the partition
+ size/tombstone count would not be correct.
- New native functions to convert unix time values into C* native types:
toDate(bigint), toTimestamp(bigint),
mintimeuuid(bigint) and maxtimeuuid(bigint)
- Support for multiple permission in a single GRANT/REVOKE/LIST statement
has been added. It allows to
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index e0961ed945..2f339418b1 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -1015,6 +1015,12 @@ public class Config
*/
public volatile int paxos_repair_parallelism = -1;
+public volatile int max_top_size_partition_count = 10;
+public volatile int max_top_tombstone_partition_count = 10;
+public volatile DataStorageSpec min_tracked_partition_size_bytes =
DataStorageSpec.inMebibytes(1);
+public volatile long min_tracked_partition_tombstone_count = 5000;
+public volatile boolean top_partitions_enabled = true;
+
public static Supplier getOverrideLoadConfig()
{
return overrideLoadConfig;
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index c1fee6e5c8..0ce787fe32 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -4194,4 +4194,49 @@ public class DatabaseDescriptor
conf.repair_state_size = size;
}
}
+
+public static boolean topPartitionsEnabled()
+{
+return conf.top_partitions_enabled;
+}
+
+public static int getMaxTopSizePartitionCount()
+{
+return conf.max_top_size_partition_count;
+}
+
+public static void setMaxTopSizePartitionCount(int value)
+{
+conf.max_top_size_partition_count = value;
+}
+
+public static int getMaxTopTombstonePartitionCount()
+{
+return conf.max_top_tombstone_partition_count;
+}
+
+public static void
[jira] [Updated] (CASSANDRA-17582) Add missing information about whether to drop sstables or not when dropping schema objects
[ https://issues.apache.org/jira/browse/CASSANDRA-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17582: - Fix Version/s: 4.x > Add missing information about whether to drop sstables or not when dropping > schema objects > -- > > Key: CASSANDRA-17582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17582 > Project: Cassandra > Issue Type: Task > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.x > > > This is the missed piece in SchemaChangeListener - when the implementation of > SchemaUpdateHandler decides to say drop a table but keep sstables, that > information about not-dropping sstables is not propagated to the > SchemaChangeListener -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17582) Add missing information about whether to drop sstables or not when dropping schema objects
[ https://issues.apache.org/jira/browse/CASSANDRA-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-17582: -- Change Category: Operability Complexity: Low Hanging Fruit Component/s: Local/SSTable Status: Open (was: Triage Needed) https://github.com/apache/cassandra/pull/1591 > Add missing information about whether to drop sstables or not when dropping > schema objects > -- > > Key: CASSANDRA-17582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17582 > Project: Cassandra > Issue Type: Task > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > This is the missed piece in SchemaChangeListener - when the implementation of > SchemaUpdateHandler decides to say drop a table but keep sstables, that > information about not-dropping sstables is not propagated to the > SchemaChangeListener -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17582) Add missing information about whether to drop sstables or not when dropping schema objects
[ https://issues.apache.org/jira/browse/CASSANDRA-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-17582: -- Test and Documentation Plan: run regression and the new test Status: Patch Available (was: Open) > Add missing information about whether to drop sstables or not when dropping > schema objects > -- > > Key: CASSANDRA-17582 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17582 > Project: Cassandra > Issue Type: Task > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > This is the missed piece in SchemaChangeListener - when the implementation of > SchemaUpdateHandler decides to say drop a table but keep sstables, that > information about not-dropping sstables is not propagated to the > SchemaChangeListener -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17582) Add missing information about whether to drop sstables or not when dropping schema objects
Jacek Lewandowski created CASSANDRA-17582: - Summary: Add missing information about whether to drop sstables or not when dropping schema objects Key: CASSANDRA-17582 URL: https://issues.apache.org/jira/browse/CASSANDRA-17582 Project: Cassandra Issue Type: Task Reporter: Jacek Lewandowski Assignee: Jacek Lewandowski This is the missed piece in SchemaChangeListener - when the implementation of SchemaUpdateHandler decides to say drop a table but keep sstables, that information about not-dropping sstables is not propagated to the SchemaChangeListener -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17556) jackson-databind 2.13.2 is vulnerable to CVE-2020-36518
[ https://issues.apache.org/jira/browse/CASSANDRA-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528140#comment-17528140 ] Berenguer Blasi commented on CASSANDRA-17556: - I'm +1 on the upgrade as well. But happy to hear more opinions if there are any. > jackson-databind 2.13.2 is vulnerable to CVE-2020-36518 > --- > > Key: CASSANDRA-17556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17556 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.13, 4.1, 4.0.4 > > > Seems like it's technically possible to cause a DoS with nested json. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16456: - Reviewers: Brandon Williams, Dinesh Joshi, Paulo Motta, Stefan Miklosovic (was: Dinesh Joshi, Paulo Motta, Stefan Miklosovic) > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528134#comment-17528134 ] Stefan Miklosovic commented on CASSANDRA-16456: --- Hi [~bhouser] , I think you got it. I have tested it in and out manually as well and I can not find anything wrong with that. Works as intended. there were few errors on formatting I ve fixed as part of my branch here, for easier navigation I squahed it all: [https://github.com/instaclustr/cassandra/commits/CASSANDRA-16456-squashed] it needs to have this in cassandra-dtests: [https://github.com/apache/cassandra-dtest/pull/188] Green build of above branches is here: [https://app.circleci.com/pipelines/github/instaclustr/cassandra/949/workflows/dcc5533f-676c-401c-893e-191092727aee] I ll do the last round of tests with our custom Kerberos server plugin, should be done today by 10pm CEST. We might improve the docs a bit and/or do it in the freeze anyway. [~brandon.williams] would you please take a look as well? > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17581) Failed to retrieve RMIServer stub: Malformed IPv6 address at index 7
[
https://issues.apache.org/jira/browse/CASSANDRA-17581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jermy Li updated CASSANDRA-17581:
-
Description:
Error when {{{color:#0747a6}new NodeProbe("127.0.0.1", 7199){color}}} with
{color:#de350b}JDK 1.8.0_332{color}:
{code:java}
java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.InvalidNameException: Malformed IPv6 address at index 7:
rmi://[127.0.0.1]:7199
Root exception is java.lang.IllegalArgumentException: Malformed IPv6 address
at index 7: rmi://[127.0.0.1]:7199 {code}
Here is the error stack trace:
{code:java}
2022-04-24 07:22:40 [grizzly-http-server-2] [INFO] c.b.h.b.s.c.CassandraMetrics
- Probe to cassandra node: '127.0.0.1:7199'
2022-04-24 07:22:40 [grizzly-http-server-2] [WARN] c.b.h.b.s.c.CassandraMetrics
- Unable to get metrics from host '127.0.0.1':
java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.InvalidNameException: Malformed IPv6 address at index 7:
rmi://[127.0.0.1]:7199 [Root exception is java.lang.IllegalArgumentException:
Malformed IPv6 address at index 7: rmi://[127.0.0.1]:7199]
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:369)
~[?:1.8.0_332]
at
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
~[?:1.8.0_332]
at org.apache.cassandra.tools.NodeProbe.connect(NodeProbe.java:191)
~[cassandra-all-3.10.jar:3.10]
at org.apache.cassandra.tools.NodeProbe.(NodeProbe.java:158)
~[cassandra-all-3.10.jar:3.10]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.newNodeProbe(CassandraMetrics.java:308)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.getMetricsByHost(CassandraMetrics.java:100)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.executeAllHosts(CassandraMetrics.java:299)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.metrics(CassandraMetrics.java:86)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraStore.lambda$registerMetaHandlers$0(CassandraStore.java:99)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.MetaDispatcher.dispatchMetaHandler(MetaDispatcher.java:45)
~[hugegraph-core-0.13.0.jar:0.13.0.0]
at
com.baidu.hugegraph.backend.store.AbstractBackendStore.metadata(AbstractBackendStore.java:53)
~[hugegraph-core-0.13.0.jar:0.13.0.0]
at
com.baidu.hugegraph.backend.tx.AbstractTransaction.metadata(AbstractTransaction.java:109)
~[hugegraph-core-0.13.0.jar:0.13.0.0]
at
com.baidu.hugegraph.StandardHugeGraph.metadata(StandardHugeGraph.java:975)
~[hugegraph-core-0.13.0.jar:0.13.0.0]
at
com.baidu.hugegraph.auth.HugeGraphAuthProxy.metadata(HugeGraphAuthProxy.java:669)
~[hugegraph-api-0.13.0.jar:0.67.0.0]
at com.baidu.hugegraph.api.metrics.MetricsAPI.backend(MetricsAPI.java:87)
~[hugegraph-api-0.13.0.jar:0.67.0.0]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[?:1.8.0_332]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:1.8.0_332]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_332]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_332]
at
org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:205)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
~[jersey-server-2.25.1.jar:?]
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
~[jersey-server-2.25.1.jar:?]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
~[jersey-common-2.25.1.jar:?]
at
[jira] [Commented] (CASSANDRA-17456) Test Failures: write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
[
https://issues.apache.org/jira/browse/CASSANDRA-17456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528122#comment-17528122
]
Andres de la Peña commented on CASSANDRA-17456:
---
CI for the last changes:
||Patch||CircleCI||
|[trunk|https://github.com/adelapena/cassandra/commit/f2bb81f9d26ca0281990861c9b72ba0809c7723c]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1506/workflows/bda95759-cf93-4900-bb56-b4be8edb8083]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1506/workflows/c3de011c-7a7e-4514-b377-c52cbf144b24]|
> Test Failures:
> write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
> ---
>
> Key: CASSANDRA-17456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17456
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1002/testReport/dtest-offheap.write_failures_test/TestMultiDCWriteFailures/test_oversized_mutation/
> {code:java}
> Error Message
> AssertionError: assert 0 == 8 + where 8 = JolokiaAgent.read_attribute of 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count') +where > =
> .read_attribute +
> and 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> Stacktrace
> self =
> def test_oversized_mutation(self):
> """
> Test that multi-DC write failures return operation failed rather
> than a timeout.
> @jira_ticket CASSANDRA-16334.
> """
>
> cluster = self.cluster
> cluster.populate([2, 2])
> cluster.set_configuration_options(values={'max_mutation_size_in_kb':
> 128})
> cluster.start()
>
> node1 = cluster.nodelist()[0]
> session = self.patient_exclusive_cql_connection(node1)
>
> session.execute("CREATE KEYSPACE k WITH replication = {'class':
> 'NetworkTopologyStrategy', 'dc1': 2, 'dc2': 2}")
> session.execute("CREATE TABLE k.t (key int PRIMARY KEY, val blob)")
>
> payload = '1' * 1024 * 256
> query = "INSERT INTO k.t (key, val) VALUES (1,
> textAsBlob('{}'))".format(payload)
>
> assert_write_failure(session, query, ConsistencyLevel.LOCAL_ONE)
> assert_write_failure(session, query, ConsistencyLevel.ONE)
>
> # verify that no hints are created
> with JolokiaAgent(node1) as jmx:
> > assert 0 == jmx.read_attribute(make_mbean('metrics',
> > type='Storage', name='TotalHints'), 'Count')
> E AssertionError: assert 0 == 8
> E+ where 8 = 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count')
> E+where > =
> .read_attribute
> E+and
> 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> write_failures_test.py:277: AssertionError
> REST API
> CloudBees CI Client Controller 2.319.3.4-rolling
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17581) Failed to retrieve RMIServer stub: Malformed IPv6 address at index 7
[
https://issues.apache.org/jira/browse/CASSANDRA-17581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528119#comment-17528119
]
Jermy Li edited comment on CASSANDRA-17581 at 4/26/22 12:03 PM:
Thanks for your reply.
The reason may be caused by upgrading the JDK version to JDK 8.0.332, here is
some environment information:
Cassandra version:
* apache-cassandra-3.10
* [http://archive.apache.org/dist/cassandra]
Java environment:
* JDK 8.0.332+9
* Java 8.0.332+9 (Zulu):
[https://cdn.azul.com/zulu/bin/zulu8.62.0.19-ca-jdk8.0.332-linux_x64.tar.gz]
Operating system environment:
* Environment: ubuntu-20.04
* Version: 20220410.2
* Image Release:
[https://github.com/actions/virtual-environments/releases/tag/ubuntu20%2F20220410.2]
For more details see:
*
[https://github.com/apache/incubator-hugegraph/runs/6146493904?check_suite_focus=true]
was (Author: JIRAUSER284940):
Thanks for your reply.
The reason may be caused by upgrading the JDK version to JDK 8.0.332, here is
some environment information:
Cassandra version:
* apache-cassandra-3.10
* [http://archive.apache.org/dist/cassandra]
Java environment:
* JDK 8.0.332+9
* Java 8.0.332+9 (Zulu):
[https://cdn.azul.com/zulu/bin/zulu8.62.0.19-ca-jdk8.0.332-linux_x64.tar.gz]
Operating system environment:
* Environment: ubuntu-20.04
* Version: 20220410.2
* Image Release:
[https://github.com/actions/virtual-environments/releases/tag/ubuntu20%2F20220410.2]
For more details see:
*
[https://github.com/apache/incubator-hugegraph/runs/6146493904?check_suite_focus=true]
> Failed to retrieve RMIServer stub: Malformed IPv6 address at index 7
>
>
> Key: CASSANDRA-17581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17581
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Jermy Li
>Priority: Normal
>
> Error when `{{{}new NodeProbe("127.0.0.1", 7199)`{}}} with jdk 1.8.0_332:
>
> {code:java}
> java.io.IOException: Failed to retrieve RMIServer stub:
> javax.naming.InvalidNameException: Malformed IPv6 address at index 7:
> rmi://[127.0.0.1]:7199
> Root exception is java.lang.IllegalArgumentException: Malformed IPv6 address
> at index 7: rmi://[127.0.0.1]:7199 {code}
>
> Here is the error stack trace:
> {code:java}
> 2022-04-24 07:22:40 [grizzly-http-server-2] [INFO]
> c.b.h.b.s.c.CassandraMetrics - Probe to cassandra node: '127.0.0.1:7199'
> 2022-04-24 07:22:40 [grizzly-http-server-2] [WARN]
> c.b.h.b.s.c.CassandraMetrics - Unable to get metrics from host '127.0.0.1':
> java.io.IOException: Failed to retrieve RMIServer stub:
> javax.naming.InvalidNameException: Malformed IPv6 address at index 7:
> rmi://[127.0.0.1]:7199 [Root exception is java.lang.IllegalArgumentException:
> Malformed IPv6 address at index 7: rmi://[127.0.0.1]:7199]
> at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:369)
> ~[?:1.8.0_332]
> at
> javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> ~[?:1.8.0_332]
> at org.apache.cassandra.tools.NodeProbe.connect(NodeProbe.java:191)
> ~[cassandra-all-3.10.jar:3.10]
> at org.apache.cassandra.tools.NodeProbe.(NodeProbe.java:158)
> ~[cassandra-all-3.10.jar:3.10]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.newNodeProbe(CassandraMetrics.java:308)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.getMetricsByHost(CassandraMetrics.java:100)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.executeAllHosts(CassandraMetrics.java:299)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.metrics(CassandraMetrics.java:86)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraStore.lambda$registerMetaHandlers$0(CassandraStore.java:99)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.MetaDispatcher.dispatchMetaHandler(MetaDispatcher.java:45)
> ~[hugegraph-core-0.13.0.jar:0.13.0.0]
> at
> com.baidu.hugegraph.backend.store.AbstractBackendStore.metadata(AbstractBackendStore.java:53)
> ~[hugegraph-core-0.13.0.jar:0.13.0.0]
> at
> com.baidu.hugegraph.backend.tx.AbstractTransaction.metadata(AbstractTransaction.java:109)
> ~[hugegraph-core-0.13.0.jar:0.13.0.0]
> at
> com.baidu.hugegraph.StandardHugeGraph.metadata(StandardHugeGraph.java:975)
> ~[hugegraph-core-0.13.0.jar:0.13.0.0]
> at
> com.baidu.hugegraph.auth.HugeGraphAuthProxy.metadata(HugeGraphAuthProxy.java:669)
> ~[hugegraph-api-0.13.0.jar:0.67.0.0]
> at
[jira] [Commented] (CASSANDRA-17581) Failed to retrieve RMIServer stub: Malformed IPv6 address at index 7
[
https://issues.apache.org/jira/browse/CASSANDRA-17581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528119#comment-17528119
]
Jermy Li commented on CASSANDRA-17581:
--
Thanks for your reply.
The reason may be caused by upgrading the JDK version to JDK 8.0.332, here is
some environment information:
Cassandra version:
* apache-cassandra-3.10
* [http://archive.apache.org/dist/cassandra]
Java environment:
* JDK 8.0.332+9
* Java 8.0.332+9 (Zulu):
[https://cdn.azul.com/zulu/bin/zulu8.62.0.19-ca-jdk8.0.332-linux_x64.tar.gz]
Operating system environment:
* Environment: ubuntu-20.04
* Version: 20220410.2
* Image Release:
[https://github.com/actions/virtual-environments/releases/tag/ubuntu20%2F20220410.2]
For more details see:
*
[https://github.com/apache/incubator-hugegraph/runs/6146493904?check_suite_focus=true]
> Failed to retrieve RMIServer stub: Malformed IPv6 address at index 7
>
>
> Key: CASSANDRA-17581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17581
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Jermy Li
>Priority: Normal
>
> Error when `{{{}new NodeProbe("127.0.0.1", 7199)`{}}} with jdk 1.8.0_332:
>
> {code:java}
> java.io.IOException: Failed to retrieve RMIServer stub:
> javax.naming.InvalidNameException: Malformed IPv6 address at index 7:
> rmi://[127.0.0.1]:7199
> Root exception is java.lang.IllegalArgumentException: Malformed IPv6 address
> at index 7: rmi://[127.0.0.1]:7199 {code}
>
> Here is the error stack trace:
> {code:java}
> 2022-04-24 07:22:40 [grizzly-http-server-2] [INFO]
> c.b.h.b.s.c.CassandraMetrics - Probe to cassandra node: '127.0.0.1:7199'
> 2022-04-24 07:22:40 [grizzly-http-server-2] [WARN]
> c.b.h.b.s.c.CassandraMetrics - Unable to get metrics from host '127.0.0.1':
> java.io.IOException: Failed to retrieve RMIServer stub:
> javax.naming.InvalidNameException: Malformed IPv6 address at index 7:
> rmi://[127.0.0.1]:7199 [Root exception is java.lang.IllegalArgumentException:
> Malformed IPv6 address at index 7: rmi://[127.0.0.1]:7199]
> at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:369)
> ~[?:1.8.0_332]
> at
> javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> ~[?:1.8.0_332]
> at org.apache.cassandra.tools.NodeProbe.connect(NodeProbe.java:191)
> ~[cassandra-all-3.10.jar:3.10]
> at org.apache.cassandra.tools.NodeProbe.(NodeProbe.java:158)
> ~[cassandra-all-3.10.jar:3.10]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.newNodeProbe(CassandraMetrics.java:308)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.getMetricsByHost(CassandraMetrics.java:100)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.executeAllHosts(CassandraMetrics.java:299)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.metrics(CassandraMetrics.java:86)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraStore.lambda$registerMetaHandlers$0(CassandraStore.java:99)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.MetaDispatcher.dispatchMetaHandler(MetaDispatcher.java:45)
> ~[hugegraph-core-0.13.0.jar:0.13.0.0]
> at
> com.baidu.hugegraph.backend.store.AbstractBackendStore.metadata(AbstractBackendStore.java:53)
> ~[hugegraph-core-0.13.0.jar:0.13.0.0]
> at
> com.baidu.hugegraph.backend.tx.AbstractTransaction.metadata(AbstractTransaction.java:109)
> ~[hugegraph-core-0.13.0.jar:0.13.0.0]
> at
> com.baidu.hugegraph.StandardHugeGraph.metadata(StandardHugeGraph.java:975)
> ~[hugegraph-core-0.13.0.jar:0.13.0.0]
> at
> com.baidu.hugegraph.auth.HugeGraphAuthProxy.metadata(HugeGraphAuthProxy.java:669)
> ~[hugegraph-api-0.13.0.jar:0.67.0.0]
> at com.baidu.hugegraph.api.metrics.MetricsAPI.backend(MetricsAPI.java:87)
> ~[hugegraph-api-0.13.0.jar:0.67.0.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:1.8.0_332]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:1.8.0_332]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_332]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_332]
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> ~[jersey-server-2.25.1.jar:?]
> at
>
[jira] [Commented] (CASSANDRA-17581) Failed to retrieve RMIServer stub: Malformed IPv6 address at index 7
[
https://issues.apache.org/jira/browse/CASSANDRA-17581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528110#comment-17528110
]
Brandon Williams commented on CASSANDRA-17581:
--
Can you provide details of your version and environment, and steps to
reproduce? At first glance it looks like something is adding brackets around
the ipv4 localhost address.
> Failed to retrieve RMIServer stub: Malformed IPv6 address at index 7
>
>
> Key: CASSANDRA-17581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17581
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Jermy Li
>Priority: Normal
>
> Error when `{{{}new NodeProbe("127.0.0.1", 7199)`{}}} with jdk 1.8.0_332:
>
> {code:java}
> java.io.IOException: Failed to retrieve RMIServer stub:
> javax.naming.InvalidNameException: Malformed IPv6 address at index 7:
> rmi://[127.0.0.1]:7199
> Root exception is java.lang.IllegalArgumentException: Malformed IPv6 address
> at index 7: rmi://[127.0.0.1]:7199 {code}
>
>
> Here is the error stack trace:
> {code:java}
> 2022-04-24 07:22:40 [grizzly-http-server-2] [INFO]
> c.b.h.b.s.c.CassandraMetrics - Probe to cassandra node: '127.0.0.1:7199'
> 2022-04-24 07:22:40 [grizzly-http-server-2] [WARN]
> c.b.h.b.s.c.CassandraMetrics - Unable to get metrics from host '127.0.0.1':
> java.io.IOException: Failed to retrieve RMIServer stub:
> javax.naming.InvalidNameException: Malformed IPv6 address at index 7:
> rmi://[127.0.0.1]:7199 [Root exception is java.lang.IllegalArgumentException:
> Malformed IPv6 address at index 7: rmi://[127.0.0.1]:7199]
> at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:369)
> ~[?:1.8.0_332]
> at
> javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> ~[?:1.8.0_332]
> at org.apache.cassandra.tools.NodeProbe.connect(NodeProbe.java:191)
> ~[cassandra-all-3.10.jar:3.10]
> at org.apache.cassandra.tools.NodeProbe.(NodeProbe.java:158)
> ~[cassandra-all-3.10.jar:3.10]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.newNodeProbe(CassandraMetrics.java:308)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.getMetricsByHost(CassandraMetrics.java:100)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.executeAllHosts(CassandraMetrics.java:299)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.metrics(CassandraMetrics.java:86)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.cassandra.CassandraStore.lambda$registerMetaHandlers$0(CassandraStore.java:99)
> ~[hugegraph-cassandra-0.13.0.jar:?]
> at
> com.baidu.hugegraph.backend.store.MetaDispatcher.dispatchMetaHandler(MetaDispatcher.java:45)
> ~[hugegraph-core-0.13.0.jar:0.13.0.0]
> at
> com.baidu.hugegraph.backend.store.AbstractBackendStore.metadata(AbstractBackendStore.java:53)
> ~[hugegraph-core-0.13.0.jar:0.13.0.0]
> at
> com.baidu.hugegraph.backend.tx.AbstractTransaction.metadata(AbstractTransaction.java:109)
> ~[hugegraph-core-0.13.0.jar:0.13.0.0]
> at
> com.baidu.hugegraph.StandardHugeGraph.metadata(StandardHugeGraph.java:975)
> ~[hugegraph-core-0.13.0.jar:0.13.0.0]
> at
> com.baidu.hugegraph.auth.HugeGraphAuthProxy.metadata(HugeGraphAuthProxy.java:669)
> ~[hugegraph-api-0.13.0.jar:0.67.0.0]
> at com.baidu.hugegraph.api.metrics.MetricsAPI.backend(MetricsAPI.java:87)
> ~[hugegraph-api-0.13.0.jar:0.67.0.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:1.8.0_332]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:1.8.0_332]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_332]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_332]
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> ~[jersey-server-2.25.1.jar:?]
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> ~[jersey-server-2.25.1.jar:?]
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
> ~[jersey-server-2.25.1.jar:?]
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:205)
> ~[jersey-server-2.25.1.jar:?]
> at
>
[jira] [Updated] (CASSANDRA-17581) Failed to retrieve RMIServer stub: Malformed IPv6 address at index 7
[
https://issues.apache.org/jira/browse/CASSANDRA-17581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jermy Li updated CASSANDRA-17581:
-
Description:
Error when `{{{}new NodeProbe("127.0.0.1", 7199)`{}}} with jdk 1.8.0_332:
{code:java}
java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.InvalidNameException: Malformed IPv6 address at index 7:
rmi://[127.0.0.1]:7199
Root exception is java.lang.IllegalArgumentException: Malformed IPv6 address
at index 7: rmi://[127.0.0.1]:7199 {code}
Here is the error stack trace:
{code:java}
2022-04-24 07:22:40 [grizzly-http-server-2] [INFO] c.b.h.b.s.c.CassandraMetrics
- Probe to cassandra node: '127.0.0.1:7199'
2022-04-24 07:22:40 [grizzly-http-server-2] [WARN] c.b.h.b.s.c.CassandraMetrics
- Unable to get metrics from host '127.0.0.1':
java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.InvalidNameException: Malformed IPv6 address at index 7:
rmi://[127.0.0.1]:7199 [Root exception is java.lang.IllegalArgumentException:
Malformed IPv6 address at index 7: rmi://[127.0.0.1]:7199]
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:369)
~[?:1.8.0_332]
at
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
~[?:1.8.0_332]
at org.apache.cassandra.tools.NodeProbe.connect(NodeProbe.java:191)
~[cassandra-all-3.10.jar:3.10]
at org.apache.cassandra.tools.NodeProbe.(NodeProbe.java:158)
~[cassandra-all-3.10.jar:3.10]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.newNodeProbe(CassandraMetrics.java:308)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.getMetricsByHost(CassandraMetrics.java:100)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.executeAllHosts(CassandraMetrics.java:299)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.metrics(CassandraMetrics.java:86)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraStore.lambda$registerMetaHandlers$0(CassandraStore.java:99)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.MetaDispatcher.dispatchMetaHandler(MetaDispatcher.java:45)
~[hugegraph-core-0.13.0.jar:0.13.0.0]
at
com.baidu.hugegraph.backend.store.AbstractBackendStore.metadata(AbstractBackendStore.java:53)
~[hugegraph-core-0.13.0.jar:0.13.0.0]
at
com.baidu.hugegraph.backend.tx.AbstractTransaction.metadata(AbstractTransaction.java:109)
~[hugegraph-core-0.13.0.jar:0.13.0.0]
at
com.baidu.hugegraph.StandardHugeGraph.metadata(StandardHugeGraph.java:975)
~[hugegraph-core-0.13.0.jar:0.13.0.0]
at
com.baidu.hugegraph.auth.HugeGraphAuthProxy.metadata(HugeGraphAuthProxy.java:669)
~[hugegraph-api-0.13.0.jar:0.67.0.0]
at com.baidu.hugegraph.api.metrics.MetricsAPI.backend(MetricsAPI.java:87)
~[hugegraph-api-0.13.0.jar:0.67.0.0]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[?:1.8.0_332]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:1.8.0_332]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_332]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_332]
at
org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:205)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
~[jersey-server-2.25.1.jar:?]
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
~[jersey-server-2.25.1.jar:?]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
~[jersey-common-2.25.1.jar:?]
at
[jira] [Created] (CASSANDRA-17581) Failed to retrieve RMIServer stub: Malformed IPv6 address at index 7
Jermy Li created CASSANDRA-17581:
Summary: Failed to retrieve RMIServer stub: Malformed IPv6 address
at index 7
Key: CASSANDRA-17581
URL: https://issues.apache.org/jira/browse/CASSANDRA-17581
Project: Cassandra
Issue Type: Bug
Components: Tool/nodetool
Reporter: Jermy Li
Error when `{{{}new NodeProbe("127.0.0.1", 7199)`{}}} with jdk 1.8.0_332:
{code:java}
java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.InvalidNameException: Malformed IPv6 address at index 7:
rmi://[127.0.0.1]:7199
Root exception is java.lang.IllegalArgumentException: Malformed IPv6 address
at index 7: rmi://[127.0.0.1]:7199 {code}
Here is the error stack trace:
{code:java}
2022-04-24 07:22:40 [grizzly-http-server-2] [INFO] c.b.h.b.s.c.CassandraMetrics
- Probe to cassandra node: '127.0.0.1:7199'
2022-04-24 07:22:40 [grizzly-http-server-2] [WARN] c.b.h.b.s.c.CassandraMetrics
- Unable to get metrics from host '127.0.0.1':
java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.InvalidNameException: Malformed IPv6 address at index 7:
rmi://[127.0.0.1]:7199 [Root exception is java.lang.IllegalArgumentException:
Malformed IPv6 address at index 7: rmi://[127.0.0.1]:7199]
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:369)
~[?:1.8.0_332]
at
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
~[?:1.8.0_332]
at org.apache.cassandra.tools.NodeProbe.connect(NodeProbe.java:191)
~[cassandra-all-3.10.jar:3.10]
at org.apache.cassandra.tools.NodeProbe.(NodeProbe.java:158)
~[cassandra-all-3.10.jar:3.10]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.newNodeProbe(CassandraMetrics.java:308)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.getMetricsByHost(CassandraMetrics.java:100)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.executeAllHosts(CassandraMetrics.java:299)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraMetrics.metrics(CassandraMetrics.java:86)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.cassandra.CassandraStore.lambda$registerMetaHandlers$0(CassandraStore.java:99)
~[hugegraph-cassandra-0.13.0.jar:?]
at
com.baidu.hugegraph.backend.store.MetaDispatcher.dispatchMetaHandler(MetaDispatcher.java:45)
~[hugegraph-core-0.13.0.jar:0.13.0.0]
at
com.baidu.hugegraph.backend.store.AbstractBackendStore.metadata(AbstractBackendStore.java:53)
~[hugegraph-core-0.13.0.jar:0.13.0.0]
at
com.baidu.hugegraph.backend.tx.AbstractTransaction.metadata(AbstractTransaction.java:109)
~[hugegraph-core-0.13.0.jar:0.13.0.0]
at
com.baidu.hugegraph.StandardHugeGraph.metadata(StandardHugeGraph.java:975)
~[hugegraph-core-0.13.0.jar:0.13.0.0]
at
com.baidu.hugegraph.auth.HugeGraphAuthProxy.metadata(HugeGraphAuthProxy.java:669)
~[hugegraph-api-0.13.0.jar:0.67.0.0]
at com.baidu.hugegraph.api.metrics.MetricsAPI.backend(MetricsAPI.java:87)
~[hugegraph-api-0.13.0.jar:0.67.0.0]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[?:1.8.0_332]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:1.8.0_332]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_332]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_332]
at
org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:205)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
~[jersey-server-2.25.1.jar:?]
at
org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
~[jersey-server-2.25.1.jar:?]
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
[jira] [Commented] (CASSANDRA-17180) Implement startup check to prevent Cassandra start to spread zombie data
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528103#comment-17528103 ] Stefan Miklosovic commented on CASSANDRA-17180: --- I was thinking about enablement by default and I do not want to enable it by default yet. Let's just live with this for a while and gather more feedback from the field first. What I am saying is that let's mature it first a bit before crossing that bridge. > Implement startup check to prevent Cassandra start to spread zombie data > > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 11h 20m > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17556) jackson-databind 2.13.2 is vulnerable to CVE-2020-36518
[ https://issues.apache.org/jira/browse/CASSANDRA-17556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528091#comment-17528091 ] Brandon Williams commented on CASSANDRA-17556: -- I don't think so. We cannot release with OWASP failing, so there are only two paths here: upgrade, or determine that this isn't a problem and add a suppression. The latter is a lot simpler for when the component is something we clearly don't use, like Netty's HTTP implementations, where here I think there would always be a shadow of doubt. So in my view, upgrading is the likely future. > jackson-databind 2.13.2 is vulnerable to CVE-2020-36518 > --- > > Key: CASSANDRA-17556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17556 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.13, 4.1, 4.0.4 > > > Seems like it's technically possible to cause a DoS with nested json. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16765) Update Cassandra build CI script for new website
[ https://issues.apache.org/jira/browse/CASSANDRA-16765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16765: --- Status: Ready to Commit (was: Review In Progress) > Update Cassandra build CI script for new website > > > Key: CASSANDRA-16765 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16765 > Project: Cassandra > Issue Type: Task > Components: Build, CI, Documentation/Website >Reporter: Anthony Grasso >Assignee: Michael Semb Wever >Priority: Normal > > Update the apache/cassandra-build repository has [.groovy job > script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy] > to use the new tooling to build the website. > The apache/cassandra-build repository has [.groovy job > script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy]. > It [builds and deploys the > website|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L1255-L1268] > to cassandra-website staging when the cassandra-website is updated. > We need to change the commands in the .groovy script to at least rebuild the > site when a change happens in the cassandra-website repository. > It would be also good to build the docs when a change happens to doc/source > directory in the cassandra repository. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16765) Update Cassandra build CI script for new website
[ https://issues.apache.org/jira/browse/CASSANDRA-16765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528078#comment-17528078 ] Anthony Grasso commented on CASSANDRA-16765: +1 > Update Cassandra build CI script for new website > > > Key: CASSANDRA-16765 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16765 > Project: Cassandra > Issue Type: Task > Components: Build, CI, Documentation/Website >Reporter: Anthony Grasso >Assignee: Michael Semb Wever >Priority: Normal > > Update the apache/cassandra-build repository has [.groovy job > script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy] > to use the new tooling to build the website. > The apache/cassandra-build repository has [.groovy job > script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy]. > It [builds and deploys the > website|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L1255-L1268] > to cassandra-website staging when the cassandra-website is updated. > We need to change the commands in the .groovy script to at least rebuild the > site when a change happens in the cassandra-website repository. > It would be also good to build the docs when a change happens to doc/source > directory in the cassandra repository. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17374) cassandra-website run.sh needs to move and prep files for content/ folder
[ https://issues.apache.org/jira/browse/CASSANDRA-17374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528077#comment-17528077 ] Anthony Grasso commented on CASSANDRA-17374: Thanks [~mck] . Patch added in commit [1de171b|https://github.com/apache/cassandra-website/commit/1de171b910983628e1b7e19dbeac0a3bb09dbab0] > cassandra-website run.sh needs to move and prep files for content/ folder > - > > Key: CASSANDRA-17374 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17374 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Anthony Grasso >Priority: Normal > Fix For: NA > > > See manual steps still required here: > https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:mck/16765#diff-1f760d89dfb81ea05a11d862007a4e4e586b38aac7ae87f62c5b2e86571809c0R1273-R1291 > -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17374) cassandra-website run.sh needs to move and prep files for content/ folder
[ https://issues.apache.org/jira/browse/CASSANDRA-17374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Grasso updated CASSANDRA-17374: --- Fix Version/s: NA Since Version: NA Source Control Link: [1de171b|https://github.com/apache/cassandra-website/commit/1de171b910983628e1b7e19dbeac0a3bb09dbab0] Resolution: Fixed Status: Resolved (was: Ready to Commit) > cassandra-website run.sh needs to move and prep files for content/ folder > - > > Key: CASSANDRA-17374 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17374 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Anthony Grasso >Priority: Normal > Fix For: NA > > > See manual steps still required here: > https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:mck/16765#diff-1f760d89dfb81ea05a11d862007a4e4e586b38aac7ae87f62c5b2e86571809c0R1273-R1291 > -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-16310:
Fix Version/s: 4.1
(was: 4.x)
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.1
>
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
