[jira] [Commented] (CASSANDRA-16203) Rack Aware Topology Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402000#comment-17402000 ] Paulo Motta commented on CASSANDRA-16203: - Even if a CEP is not strictly required, it would be great to have CEPs for pluggable components being shipped in the default release, mostly for architectural documentation purposes. :-) #throwingideas > Rack Aware Topology Strategy > > > Key: CASSANDRA-16203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16203 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Cameron Zemek >Assignee: Cameron Zemek >Priority: Normal > Fix For: 4.x > > Attachments: rackaware.patch > > > If replication factor > racks then NetworkTopologyStrategy assigns the extras > in ring order. This means losing a rack can result in the loss of quorum. I > have implemented a similar topology strategy that evenly distributes replicas > across racks. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16721) Repaired data tracking on a read coordinator is susceptible to races between local and remote requests
[
https://issues.apache.org/jira/browse/CASSANDRA-16721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16721:
Status: Patch Available (was: In Progress)
> Repaired data tracking on a read coordinator is susceptible to races between
> local and remote requests
> --
>
> Key: CASSANDRA-16721
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16721
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Sam Tunnicliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At read time on a coordinator which is also a replica, the local and remote
> reads can race such that the remote responses are received while the local
> read is executing. If the remote responses are mismatching, triggering a
> {{DigestMismatchException}} and subsequent round of full data reads and read
> repair, the local runnable may find the {{isTrackingRepairedStatus}} flag
> flipped mid-execution. If this happens after a certain point in execution,
> it would mean
> that the RepairedDataInfo instance in use is the singleton null object
> {{RepairedDataInfo.NULL_REPAIRED_DATA_INFO}}. If this happens, it can lead to
> an NPE when calling {{RepairedDataInfo::extend}} when the local results are
> iterated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16721) Repaired data tracking on a read coordinator is susceptible to races between local and remote requests
[
https://issues.apache.org/jira/browse/CASSANDRA-16721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401932#comment-17401932
]
Caleb Rackliffe commented on CASSANDRA-16721:
-
[~samt] Alright, I think this is back in a reviewable state if you'd like to
take a look.
||Branch||Circle CI ||
|[4.0|https://github.com/apache/cassandra/pull/1160]|[J8 and
J11|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-16721-4.0]|
> Repaired data tracking on a read coordinator is susceptible to races between
> local and remote requests
> --
>
> Key: CASSANDRA-16721
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16721
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Sam Tunnicliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At read time on a coordinator which is also a replica, the local and remote
> reads can race such that the remote responses are received while the local
> read is executing. If the remote responses are mismatching, triggering a
> {{DigestMismatchException}} and subsequent round of full data reads and read
> repair, the local runnable may find the {{isTrackingRepairedStatus}} flag
> flipped mid-execution. If this happens after a certain point in execution,
> it would mean
> that the RepairedDataInfo instance in use is the singleton null object
> {{RepairedDataInfo.NULL_REPAIRED_DATA_INFO}}. If this happens, it can lead to
> an NPE when calling {{RepairedDataInfo::extend}} when the local results are
> iterated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16203) Rack Aware Topology Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401880#comment-17401880 ] Sumanth Pasupuleti commented on CASSANDRA-16203: I was just curious if we needed a CEP, but I do agree, given that the strategy is pluggable, we should be fine without a CEP. > Rack Aware Topology Strategy > > > Key: CASSANDRA-16203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16203 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Cameron Zemek >Assignee: Cameron Zemek >Priority: Normal > Fix For: 4.x > > Attachments: rackaware.patch > > > If replication factor > racks then NetworkTopologyStrategy assigns the extras > in ring order. This means losing a rack can result in the loss of quorum. I > have implemented a similar topology strategy that evenly distributes replicas > across racks. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16838) DOC - Broken link to contribution on community page
[
https://issues.apache.org/jira/browse/CASSANDRA-16838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16838:
---
Fix Version/s: (was: 4.0.x)
4.0.1
Source Control Link:
https://github.com/apache/cassandra-website/commit/18e52d17b1571a14a0b80ce9b9ec2af55feeca42
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Came out from asciidoc generated deploy in
[18e52d17b1571a14a0b80ce9b9ec2af55feeca42|https://github.com/apache/cassandra-website/commit/18e52d17b1571a14a0b80ce9b9ec2af55feeca42],
as part of CASSANDRA-16829.
> DOC - Broken link to contribution on community page
> ---
>
> Key: CASSANDRA-16838
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16838
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ruslan Fomkin
>Priority: Normal
> Fix For: 4.0.1
>
>
> Becoming a contributor in [How to
> Contribute|https://cassandra.apache.org/_/community.html#how-to-contribute]
> section contains link under {{contribute to Cassandra}}, which leads to
> cannot find the server and the link is
> [https://doc/latest/development/index.html]
>
> The issue is probably due to extra / in
>
[jira] [Updated] (CASSANDRA-16838) DOC - Broken link to contribution on community page
[
https://issues.apache.org/jira/browse/CASSANDRA-16838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16838:
---
Status: Ready to Commit (was: Review In Progress)
> DOC - Broken link to contribution on community page
> ---
>
> Key: CASSANDRA-16838
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16838
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ruslan Fomkin
>Priority: Normal
> Fix For: 4.0.x
>
>
> Becoming a contributor in [How to
> Contribute|https://cassandra.apache.org/_/community.html#how-to-contribute]
> section contains link under {{contribute to Cassandra}}, which leads to
> cannot find the server and the link is
> [https://doc/latest/development/index.html]
>
> The issue is probably due to extra / in
>
[jira] [Updated] (CASSANDRA-16838) DOC - Broken link to contribution on community page
[
https://issues.apache.org/jira/browse/CASSANDRA-16838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16838:
---
Reviewers: Michael Semb Wever
Status: Review In Progress (was: Patch Available)
> DOC - Broken link to contribution on community page
> ---
>
> Key: CASSANDRA-16838
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16838
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ruslan Fomkin
>Priority: Normal
> Fix For: 4.0.x
>
>
> Becoming a contributor in [How to
> Contribute|https://cassandra.apache.org/_/community.html#how-to-contribute]
> section contains link under {{contribute to Cassandra}}, which leads to
> cannot find the server and the link is
> [https://doc/latest/development/index.html]
>
> The issue is probably due to extra / in
>
[jira] [Updated] (CASSANDRA-16838) DOC - Broken link to contribution on community page
[
https://issues.apache.org/jira/browse/CASSANDRA-16838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16838:
---
Test and Documentation Plan: website staging
Status: Patch Available (was: Open)
> DOC - Broken link to contribution on community page
> ---
>
> Key: CASSANDRA-16838
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16838
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ruslan Fomkin
>Priority: Normal
> Fix For: 4.0.x
>
>
> Becoming a contributor in [How to
> Contribute|https://cassandra.apache.org/_/community.html#how-to-contribute]
> section contains link under {{contribute to Cassandra}}, which leads to
> cannot find the server and the link is
> [https://doc/latest/development/index.html]
>
> The issue is probably due to extra / in
>
[jira] [Commented] (CASSANDRA-16838) DOC - Broken link to contribution on community page
[
https://issues.apache.org/jira/browse/CASSANDRA-16838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401841#comment-17401841
]
Michael Semb Wever commented on CASSANDRA-16838:
Yes, the work is now committed to the asciidoc files in [~paul-travers-todd]'s
branch.
That work will properly land in trunk via CASSANDRA-16762
Closing this ticket out as done.
> DOC - Broken link to contribution on community page
> ---
>
> Key: CASSANDRA-16838
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16838
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ruslan Fomkin
>Priority: Normal
> Fix For: 4.0.x
>
>
> Becoming a contributor in [How to
> Contribute|https://cassandra.apache.org/_/community.html#how-to-contribute]
> section contains link under {{contribute to Cassandra}}, which leads to
> cannot find the server and the link is
> [https://doc/latest/development/index.html]
>
> The issue is probably due to extra / in
>
[jira] [Created] (CASSANDRA-16870) Secure HTTPS link to the research paper in the website landing page
Karuppiah Natarajan created CASSANDRA-16870: --- Summary: Secure HTTPS link to the research paper in the website landing page Key: CASSANDRA-16870 URL: https://issues.apache.org/jira/browse/CASSANDRA-16870 Project: Cassandra Issue Type: Bug Reporter: Karuppiah Natarajan Assignee: Karuppiah Natarajan Attachments: extra-details-about-security-risk.png, security-risk-warning.png In [https://cassandra.apache.org/_/index.html] , under the Performant section, there's a link to a research paper - [http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf] - "Solving Big Data Challenges for Enterprise Application Performance Management". But this link is a HTTP link. On clicking this, my browser shows me a security warning. This is how it looks like on Firefox - !security-risk-warning.png|width=450,height=75! and some more details - !extra-details-about-security-risk.png|width=351,height=259! I noticed that the same research paper has an alternative HTTPS URL. I think that could be used instead - [https://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf] I would love to make this small fix in the docs -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16838) DOC - Broken link to contribution on community page
[
https://issues.apache.org/jira/browse/CASSANDRA-16838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401828#comment-17401828
]
Brandon Williams commented on CASSANDRA-16838:
--
That is what was said. The ticket remains open for inclusion into other
branches.
> DOC - Broken link to contribution on community page
> ---
>
> Key: CASSANDRA-16838
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16838
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ruslan Fomkin
>Priority: Normal
> Fix For: 4.0.x
>
>
> Becoming a contributor in [How to
> Contribute|https://cassandra.apache.org/_/community.html#how-to-contribute]
> section contains link under {{contribute to Cassandra}}, which leads to
> cannot find the server and the link is
> [https://doc/latest/development/index.html]
>
> The issue is probably due to extra / in
>
[jira] [Commented] (CASSANDRA-16838) DOC - Broken link to contribution on community page
[
https://issues.apache.org/jira/browse/CASSANDRA-16838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401821#comment-17401821
]
Karuppiah Natarajan commented on CASSANDRA-16838:
-
Looks like this is fixed now? I can see that the "[contribute to
Cassandra"|https://cassandra.apache.org/doc/latest/development/index.html] link
under [https://cassandra.apache.org/_/community.html#how-to-contribute] now
points to [https://cassandra.apache.org/_/development/index.html]
> DOC - Broken link to contribution on community page
> ---
>
> Key: CASSANDRA-16838
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16838
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ruslan Fomkin
>Priority: Normal
> Fix For: 4.0.x
>
>
> Becoming a contributor in [How to
> Contribute|https://cassandra.apache.org/_/community.html#how-to-contribute]
> section contains link under {{contribute to Cassandra}}, which leads to
> cannot find the server and the link is
> [https://doc/latest/development/index.html]
>
> The issue is probably due to extra / in
>
[jira] [Updated] (CASSANDRA-16869) Reduce the amount of logging on "expected" repair exceptions
[ https://issues.apache.org/jira/browse/CASSANDRA-16869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-16869: -- Test and Documentation Plan: New in-jvm dtests added to check handling of repair errors. No documentation change needed. Status: Patch Available (was: Open) > Reduce the amount of logging on "expected" repair exceptions > > > Key: CASSANDRA-16869 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16869 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.0.1 > > > Many of the repair errors we throw in the logs are redundant. For example, if > one node has an unreadable sstable, we should log that at ERROR, but then the > failing repairs due to that unreadable sstable should be at WARN, making it > easier to find and debug the actual problem. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16869) Reduce the amount of logging on "expected" repair exceptions
[ https://issues.apache.org/jira/browse/CASSANDRA-16869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401786#comment-17401786 ] Josh McKenzie commented on CASSANDRA-16869: --- Tests are in flight after tidying up a couple failures. ||Item||Link|| |j8 test|[link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/49/workflows/edbc5e1c-87f5-4a67-89d6-34520b337326]| |j11 test|[link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/49/workflows/891ad9d2-1375-4c17-b8fc-e2a7a9c69b50]| |branch|[link|https://github.com/apache/cassandra/compare/cassandra-4.0...josh-mckenzie:repair_log_exceptions?expand=1]| > Reduce the amount of logging on "expected" repair exceptions > > > Key: CASSANDRA-16869 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16869 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Many of the repair errors we throw in the logs are redundant. For example, if > one node has an unreadable sstable, we should log that at ERROR, but then the > failing repairs due to that unreadable sstable should be at WARN, making it > easier to find and debug the actual problem. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16869) Reduce the amount of logging on "expected" repair exceptions
[ https://issues.apache.org/jira/browse/CASSANDRA-16869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-16869: -- Change Category: Operability Complexity: Normal Fix Version/s: 4.0.1 Status: Open (was: Triage Needed) > Reduce the amount of logging on "expected" repair exceptions > > > Key: CASSANDRA-16869 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16869 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.0.1 > > > Many of the repair errors we throw in the logs are redundant. For example, if > one node has an unreadable sstable, we should log that at ERROR, but then the > failing repairs due to that unreadable sstable should be at WARN, making it > easier to find and debug the actual problem. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16869) Reduce the amount of logging on "expected" repair exceptions
Josh McKenzie created CASSANDRA-16869: - Summary: Reduce the amount of logging on "expected" repair exceptions Key: CASSANDRA-16869 URL: https://issues.apache.org/jira/browse/CASSANDRA-16869 Project: Cassandra Issue Type: Improvement Components: Consistency/Repair Reporter: Josh McKenzie Assignee: Josh McKenzie Many of the repair errors we throw in the logs are redundant. For example, if one node has an unreadable sstable, we should log that at ERROR, but then the failing repairs due to that unreadable sstable should be at WARN, making it easier to find and debug the actual problem. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16859) allow blocking IPs from updating metrics about traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-16859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16859: Status: Review In Progress (was: Patch Available) > allow blocking IPs from updating metrics about traffic > -- > > Key: CASSANDRA-16859 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16859 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1 > > Time Spent: 3h > Remaining Estimate: 0h > > It is common that network scans happen for some companies, and when these > scans happen they will send packets to the Cassandra ports which do not match > our protocol; when this happens we fail and increment metrics to show this. > To avoid these scans polluting our metrics, we should allow users to block > their own IP subnets from updating these metrics. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14344) Support filtering using IN restrictions
[
https://issues.apache.org/jira/browse/CASSANDRA-14344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14344:
---
Status: Needs Reviewer (was: Review In Progress)
> Support filtering using IN restrictions
> ---
>
> Key: CASSANDRA-14344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14344
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
>Reporter: Dikang Gu
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 14344-trunk-2.txt, 14344-trunk-3.patch,
> 14344-trunk-inexpression-approach-2.txt,
> 14344-trunk-inexpression-approach.txt, 14344-trunk.txt
>
>
> Support IN filter query like this:
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+++---
> 1 | 1 | 1 | 1
> 1 | 2 | 1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow filtering;
> *{color:#ff}InvalidRequest: Error from server: code=2200 [Invalid query]
> message="IN restrictions are not supported on indexed columns"{color}*
> cqlsh:ks1>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14344) Support filtering using IN restrictions
[
https://issues.apache.org/jira/browse/CASSANDRA-14344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401731#comment-17401731
]
Benjamin Lerer commented on CASSANDRA-14344:
[~n.v.harikrishna] I rebased your patch and modified it a bit to allow {{IN}}
filtering on all types of columns (partition key, clustering, regular and
static columns) not only on clustering columns. I also added support for
multi-column {{IN}} restrictions with a single column. I hope it is fine with
you.
|| Branch || CircleCi ||
| [trunk|https://github.com/apache/cassandra/pull/1159] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/189/workflows/7735aea2-e12b-436e-9280-bf41d5501589],
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/189/workflows/63daa4fc-e553-45f1-93bf-db5223c8b806]|
> Support filtering using IN restrictions
> ---
>
> Key: CASSANDRA-14344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14344
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
>Reporter: Dikang Gu
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 14344-trunk-2.txt, 14344-trunk-3.patch,
> 14344-trunk-inexpression-approach-2.txt,
> 14344-trunk-inexpression-approach.txt, 14344-trunk.txt
>
>
> Support IN filter query like this:
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+++---
> 1 | 1 | 1 | 1
> 1 | 2 | 1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow filtering;
> *{color:#ff}InvalidRequest: Error from server: code=2200 [Invalid query]
> message="IN restrictions are not supported on indexed columns"{color}*
> cqlsh:ks1>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16663) Request-Based Native Transport Rate-Limiting
[ https://issues.apache.org/jira/browse/CASSANDRA-16663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16663: Source Control Link: https://github.com/apache/cassandra/commit/d220d24994400d4342f5281f1a51514a6ae8c2fd Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed to trunk as https://github.com/apache/cassandra/commit/d220d24994400d4342f5281f1a51514a6ae8c2fd > Request-Based Native Transport Rate-Limiting > > > Key: CASSANDRA-16663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16663 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.x > > Time Spent: 15h > Remaining Estimate: 0h > > Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support > for a runtime-configurable, per-coordinator limit on the number of bytes > allocated for concurrent requests over the native protocol. It supports > channel back-pressure by default, and optionally supports throwing > OverloadedException if that is requested in the relevant connection’s STARTUP > message. > This can be an effective tool to prevent the coordinator from running out of > memory, but it may not correspond to how expensive a queries are or provide a > direct conceptual mapping to how users think about request capacity. I > propose adding the option of request-based (or perhaps more correctly > message-based) back-pressure, coexisting with (and reusing the logic that > supports) the current bytes-based back-pressure. > _We can roll this forward in phases_, where the server’s cost accounting > becomes more accurate, we segment limits by operation type/keyspace/etc., and > the client/driver reacts more intelligently to (especially non-back-pressure) > overload, _but something minimally viable could look like this_: > 1.) Reuse most of the existing logic in Limits, et al. to support a simple > per-coordinator limit only on native transport requests per second. Under > this limit will be CQL reads and writes, but also auth requests, prepare > requests, and batches. This is obviously simplistic, and it does not account > for the variation in cost between individual queries, but even a fixed cost > model should be useful in aggregate. > * If the client specifies THROW_ON_OVERLOAD in its STARTUP message at > connection time, a breach of the per-node limit will result in an > OverloadedException being propagated to the client, and the server will > discard the request. > * If THROW_ON_OVERLOAD is not specified, the server will stop consuming > messages from the channel/socket, which should back-pressure the client, > while the message continues to be processed. > 2.) This limit is infinite by default (or simply disabled), and can be > enabled via the YAML config or JMX at runtime. (It might be cleaner to have a > no-op rate limiter that's used when the feature is disabled entirely.) > 3.) The current value of the limit is available via JMX, and metrics around > coordinator operations/second are already available to compare against it. > 4.) Any interaction with existing byte-based limits will intersect. (i.e. A > breach of any limit, bytes or request-based, will actuate back-pressure or > OverloadedExceptions.) > In this first pass, explicitly out of scope would be any work on the > client/driver side. > In terms of validation/testing, our biggest concern with anything that adds > overhead on a very hot path is performance. In particular, we want to fully > understand how the client and server perform along two axes constituting 4 > scenarios. Those are a.) whether or not we are breaching the request limit > and b.) whether the server is throwing on overload at the behest of the > client. Having said that, query execution should dwarf the cost of limit > accounting. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16663) Request-Based Native Transport Rate-Limiting
[ https://issues.apache.org/jira/browse/CASSANDRA-16663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16663: Status: Ready to Commit (was: Testing) > Request-Based Native Transport Rate-Limiting > > > Key: CASSANDRA-16663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16663 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.x > > Time Spent: 14h 40m > Remaining Estimate: 0h > > Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support > for a runtime-configurable, per-coordinator limit on the number of bytes > allocated for concurrent requests over the native protocol. It supports > channel back-pressure by default, and optionally supports throwing > OverloadedException if that is requested in the relevant connection’s STARTUP > message. > This can be an effective tool to prevent the coordinator from running out of > memory, but it may not correspond to how expensive a queries are or provide a > direct conceptual mapping to how users think about request capacity. I > propose adding the option of request-based (or perhaps more correctly > message-based) back-pressure, coexisting with (and reusing the logic that > supports) the current bytes-based back-pressure. > _We can roll this forward in phases_, where the server’s cost accounting > becomes more accurate, we segment limits by operation type/keyspace/etc., and > the client/driver reacts more intelligently to (especially non-back-pressure) > overload, _but something minimally viable could look like this_: > 1.) Reuse most of the existing logic in Limits, et al. to support a simple > per-coordinator limit only on native transport requests per second. Under > this limit will be CQL reads and writes, but also auth requests, prepare > requests, and batches. This is obviously simplistic, and it does not account > for the variation in cost between individual queries, but even a fixed cost > model should be useful in aggregate. > * If the client specifies THROW_ON_OVERLOAD in its STARTUP message at > connection time, a breach of the per-node limit will result in an > OverloadedException being propagated to the client, and the server will > discard the request. > * If THROW_ON_OVERLOAD is not specified, the server will stop consuming > messages from the channel/socket, which should back-pressure the client, > while the message continues to be processed. > 2.) This limit is infinite by default (or simply disabled), and can be > enabled via the YAML config or JMX at runtime. (It might be cleaner to have a > no-op rate limiter that's used when the feature is disabled entirely.) > 3.) The current value of the limit is available via JMX, and metrics around > coordinator operations/second are already available to compare against it. > 4.) Any interaction with existing byte-based limits will intersect. (i.e. A > breach of any limit, bytes or request-based, will actuate back-pressure or > OverloadedExceptions.) > In this first pass, explicitly out of scope would be any work on the > client/driver side. > In terms of validation/testing, our biggest concern with anything that adds > overhead on a very hot path is performance. In particular, we want to fully > understand how the client and server perform along two axes constituting 4 > scenarios. Those are a.) whether or not we are breaching the request limit > and b.) whether the server is throwing on overload at the behest of the > client. Having said that, query execution should dwarf the cost of limit > accounting. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Request-Based Native Transport Rate-Limiting
This is an automated email from the ASF dual-hosted git repository.
maedhroz 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 d220d24 Request-Based Native Transport Rate-Limiting
d220d24 is described below
commit d220d24994400d4342f5281f1a51514a6ae8c2fd
Author: Caleb Rackliffe
AuthorDate: Thu Aug 19 10:55:58 2021 -0500
Request-Based Native Transport Rate-Limiting
patch by Caleb Rackliffe; reviewed by Benedict Elliott Smith and Josh
McKenzie for CASSANDRA-16663
---
CHANGES.txt| 1 +
src/java/org/apache/cassandra/config/Config.java | 4 +-
.../cassandra/config/DatabaseDescriptor.java | 27 ++
.../cassandra/net/AbstractMessageHandler.java | 21 +-
.../org/apache/cassandra/net/FrameDecoder.java | 13 +-
.../cassandra/net/InboundMessageHandler.java | 2 -
.../org/apache/cassandra/net/ResourceLimits.java | 4 +-
.../apache/cassandra/service/StorageService.java | 24 ++
.../cassandra/service/StorageServiceMBean.java | 6 +-
.../cassandra/transport/CQLMessageHandler.java | 254 +
.../cassandra/transport/ClientResourceLimits.java | 41 ++-
.../org/apache/cassandra/transport/Dispatcher.java | 37 ++-
.../cassandra/transport/ExceptionHandlers.java | 44 +--
.../transport/InitialConnectionHandler.java| 3 +-
.../apache/cassandra/transport/PreV5Handlers.java | 186 -
.../apache/cassandra/transport/SimpleClient.java | 51 ++--
.../utils/concurrent/NonBlockingRateLimiter.java | 188 +
.../apache/cassandra/transport/BurnTestUtil.java | 9 +
.../cassandra/transport/SimpleClientPerfTest.java | 81 --
test/unit/org/apache/cassandra/cql3/CQLTester.java | 35 ++-
.../apache/cassandra/net/ResourceLimitsTest.java | 2 -
.../cassandra/transport/CQLConnectionTest.java | 11 +-
.../transport/ClientResourceLimitsTest.java| 101 +++
.../cassandra/transport/RateLimitingTest.java | 309 +
.../concurrent/NonBlockingRateLimiterTest.java | 121
25 files changed, 1320 insertions(+), 255 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 5ae32a5..275ebc7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Request-Based Native Transport Rate-Limiting (CASSANDRA-16663)
* Implement nodetool getauditlog command (CASSANDRA-16725)
* Clean up repair code (CASSANDRA-13720)
* Background schedule to clean up orphaned hints files (CASSANDRA-16815)
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index 9a01db6..f7edda0 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -34,8 +34,8 @@ import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.apache.cassandra.audit.AuditLogOptions;
-import org.apache.cassandra.fql.FullQueryLoggerOptions;
import org.apache.cassandra.db.ConsistencyLevel;
+import org.apache.cassandra.fql.FullQueryLoggerOptions;
/**
* A class that contains configuration properties for the cassandra node it
runs within.
@@ -193,6 +193,8 @@ public class Config
public volatile boolean native_transport_allow_older_protocols = true;
public volatile long
native_transport_max_concurrent_requests_in_bytes_per_ip = -1L;
public volatile long native_transport_max_concurrent_requests_in_bytes =
-1L;
+public volatile boolean native_transport_rate_limiting_enabled = false;
+public volatile int native_transport_max_requests_per_second = 100;
public int native_transport_receive_queue_capacity_in_bytes = 1 << 20; //
1MiB
@Deprecated
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index f2122b1..722e63d 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -540,6 +540,11 @@ public class DatabaseDescriptor
{
conf.native_transport_max_concurrent_requests_in_bytes_per_ip =
Runtime.getRuntime().maxMemory() / 40;
}
+
+if (conf.native_transport_rate_limiting_enabled)
+logger.info("Native transport rate-limiting enabled at {}
requests/second.", conf.native_transport_max_requests_per_second);
+else
+logger.info("Native transport rate-limiting disabled.");
if (conf.commitlog_total_space_in_mb == null)
{
@@ -2324,6 +2329,28 @@ public class DatabaseDescriptor
conf.native_transport_max_concurrent_requests_in_bytes =
maxConcurrentRequestsInBytes;
}
+public static int getNativeTransportMaxRequestsPerSecond()
+{
+return conf.native_transport_max_requests_per_second;
+}
+
+
[jira] [Comment Edited] (CASSANDRA-16789) Add TTL support to nodetool snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401572#comment-17401572
]
Abuli Palagashvili edited comment on CASSANDRA-16789 at 8/19/21, 2:24 PM:
--
[Main PR|https://github.com/apache/cassandra/pull/1046]
[Website|https://github.com/apache/cassandra-website/pull/69]
[CI
run|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1043/]
was (Author: fibersel):
[Main PR|https://github.com/apache/cassandra/pull/1046]
[Website|https://github.com/apache/cassandra-website/pull/69]
> Add TTL support to nodetool snapshots
> -
>
> Key: CASSANDRA-16789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16789
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> Add new parameter {{--ttl}} to {{nodetool snapshot}} command. This parameter
> can be specified in human readable duration (ie. 30mins, 1h, 300d) and should
> not be lower than 1 minute.
> The expiration date should be added to the snapshot manifest in ISO format.
> A periodic thread should efficiently scan snapshots and automatically clear
> those past expiration date. The periodicity of the scan thread should be 1
> minute by default but be overridable via a system property.
> The command {{nodetool listsnapshots}} should display the expiration date
> when the snapshot contains a TTL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14564) Adding regular column to COMPACT tables without clustering columns should trigger an InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-14564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401678#comment-17401678
]
Stefan Miklosovic commented on CASSANDRA-14564:
---
Thanks Benjamin, that is easy to fix. I will get back to you rather shortly.
> Adding regular column to COMPACT tables without clustering columns should
> trigger an InvalidRequestException
> -
>
> Key: CASSANDRA-14564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14564
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Laxmikant Upadhyay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> I have upgraded my system from cassandra 2.1.16 to 3.11.2. We had some tables
> with COMPACT STORAGE enabled. We see some weird behaviour of cassandra
> while adding a column into it.
> Cassandra does not give any error while altering however the added column is
> invisible.
> Same behaviour when we create a new table with compact storage and try to
> alter it. Below is the commands ran in sequence:
>
> {code:java}
> x@cqlsh:xuser> CREATE TABLE xuser.employee(emp_id int PRIMARY KEY,emp_name
> text, emp_city text, emp_sal varint, emp_phone varint ) WITH COMPACT STORAGE;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';{code}
> Now altering the table by adding a new column:
>
> {code:java}
> x@cqlsh:xuser> alter table employee add profile text;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> notice that above desc table result does not have newly added column profile.
> However when i try to add it again it gives column already exist;
> {code:java}
> x@cqlsh:xuser> alter table employee add profile text;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid
> column name profile because it conflicts with an existing column"
> x@cqlsh:xuser> select emp_name,profile from employee;
> emp_name | profile
> --+-
> (0 rows)
> x@cqlsh:xuser>
> {code}
> Inserting also behaves strange:
> {code:java}
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone
> , emp_sal ,profile) VALUES ( 1, 'ggn', 'john', 123456, 5, 'SE');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Some
> clustering keys are missing: column1"
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone
> , emp_sal ,profile,column1) VALUES ( 1, 'ggn', 'john', 123456, 5,
> 'SE',null);
> x@cqlsh:xuser> select * from employee;
> emp_id | emp_city | emp_name | emp_phone | emp_sal
> +--+--+---+-
> (0 rows)
> {code}
> *How to solve that ticket*
> ([~blerer])--
>
> Adding regular columns to non-dense compact tables should be forbidden as it
> is the case for other column types. To do that {{AlterTableStatement}}
[jira] [Updated] (CASSANDRA-16789) Add TTL support to nodetool snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-16789:
Test and Documentation Plan: Website PR
Status: Patch Available (was: In Progress)
> Add TTL support to nodetool snapshots
> -
>
> Key: CASSANDRA-16789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16789
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> Add new parameter {{--ttl}} to {{nodetool snapshot}} command. This parameter
> can be specified in human readable duration (ie. 30mins, 1h, 300d) and should
> not be lower than 1 minute.
> The expiration date should be added to the snapshot manifest in ISO format.
> A periodic thread should efficiently scan snapshots and automatically clear
> those past expiration date. The periodicity of the scan thread should be 1
> minute by default but be overridable via a system property.
> The command {{nodetool listsnapshots}} should display the expiration date
> when the snapshot contains a TTL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14564) Adding regular column to COMPACT tables without clustering columns should trigger an InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-14564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14564:
---
Reviewers: Benjamin Lerer
Status: Review In Progress (was: Needs Reviewer)
> Adding regular column to COMPACT tables without clustering columns should
> trigger an InvalidRequestException
> -
>
> Key: CASSANDRA-14564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14564
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Laxmikant Upadhyay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> I have upgraded my system from cassandra 2.1.16 to 3.11.2. We had some tables
> with COMPACT STORAGE enabled. We see some weird behaviour of cassandra
> while adding a column into it.
> Cassandra does not give any error while altering however the added column is
> invisible.
> Same behaviour when we create a new table with compact storage and try to
> alter it. Below is the commands ran in sequence:
>
> {code:java}
> x@cqlsh:xuser> CREATE TABLE xuser.employee(emp_id int PRIMARY KEY,emp_name
> text, emp_city text, emp_sal varint, emp_phone varint ) WITH COMPACT STORAGE;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';{code}
> Now altering the table by adding a new column:
>
> {code:java}
> x@cqlsh:xuser> alter table employee add profile text;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> notice that above desc table result does not have newly added column profile.
> However when i try to add it again it gives column already exist;
> {code:java}
> x@cqlsh:xuser> alter table employee add profile text;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid
> column name profile because it conflicts with an existing column"
> x@cqlsh:xuser> select emp_name,profile from employee;
> emp_name | profile
> --+-
> (0 rows)
> x@cqlsh:xuser>
> {code}
> Inserting also behaves strange:
> {code:java}
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone
> , emp_sal ,profile) VALUES ( 1, 'ggn', 'john', 123456, 5, 'SE');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Some
> clustering keys are missing: column1"
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone
> , emp_sal ,profile,column1) VALUES ( 1, 'ggn', 'john', 123456, 5,
> 'SE',null);
> x@cqlsh:xuser> select * from employee;
> emp_id | emp_city | emp_name | emp_phone | emp_sal
> +--+--+---+-
> (0 rows)
> {code}
> *How to solve that ticket*
> ([~blerer])--
>
> Adding regular columns to non-dense compact tables should be forbidden as it
> is the case for other column types. To do that {{AlterTableStatement}} should
> be modified to fire an
[jira] [Commented] (CASSANDRA-14564) Adding regular column to COMPACT tables without clustering columns should trigger an InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-14564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401662#comment-17401662
]
Benjamin Lerer commented on CASSANDRA-14564:
Hi [~stefan.miklosovic],
Thanks for taking over the patch and sorry for the delay of my response. A
{{dense}} table is a compact table without clustering columns (see
[here|https://github.com/instaclustr/cassandra/blob/ce7b54a37a2aca7fe2da2f04a425a5c282574443/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java#L277]).
By consequence, you can simply replace {{if (meta.isDense()) by {{if
(meta.isCompactTable())}}.
> Adding regular column to COMPACT tables without clustering columns should
> trigger an InvalidRequestException
> -
>
> Key: CASSANDRA-14564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14564
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Laxmikant Upadhyay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> I have upgraded my system from cassandra 2.1.16 to 3.11.2. We had some tables
> with COMPACT STORAGE enabled. We see some weird behaviour of cassandra
> while adding a column into it.
> Cassandra does not give any error while altering however the added column is
> invisible.
> Same behaviour when we create a new table with compact storage and try to
> alter it. Below is the commands ran in sequence:
>
> {code:java}
> x@cqlsh:xuser> CREATE TABLE xuser.employee(emp_id int PRIMARY KEY,emp_name
> text, emp_city text, emp_sal varint, emp_phone varint ) WITH COMPACT STORAGE;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';{code}
> Now altering the table by adding a new column:
>
> {code:java}
> x@cqlsh:xuser> alter table employee add profile text;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> notice that above desc table result does not have newly added column profile.
> However when i try to add it again it gives column already exist;
> {code:java}
> x@cqlsh:xuser> alter table employee add profile text;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid
> column name profile because it conflicts with an existing column"
> x@cqlsh:xuser> select emp_name,profile from employee;
> emp_name | profile
> --+-
> (0 rows)
> x@cqlsh:xuser>
> {code}
> Inserting also behaves strange:
> {code:java}
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone
> , emp_sal ,profile) VALUES ( 1, 'ggn', 'john', 123456, 5, 'SE');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Some
> clustering keys are missing: column1"
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone
> , emp_sal ,profile,column1) VALUES ( 1, 'ggn', 'john', 123456, 5,
> 'SE',null);
> x@cqlsh:xuser> select * from employee;
> emp_id | emp_city | emp_name | emp_phone | emp_sal
>
[jira] [Updated] (CASSANDRA-16789) Add TTL support to nodetool snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-16789:
Resolution: (was: Done)
Status: Open (was: Resolved)
> Add TTL support to nodetool snapshots
> -
>
> Key: CASSANDRA-16789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16789
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> Add new parameter {{--ttl}} to {{nodetool snapshot}} command. This parameter
> can be specified in human readable duration (ie. 30mins, 1h, 300d) and should
> not be lower than 1 minute.
> The expiration date should be added to the snapshot manifest in ISO format.
> A periodic thread should efficiently scan snapshots and automatically clear
> those past expiration date. The periodicity of the scan thread should be 1
> minute by default but be overridable via a system property.
> The command {{nodetool listsnapshots}} should display the expiration date
> when the snapshot contains a TTL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16868) Secondary indexes on primary key columns can miss some writes
[
https://issues.apache.org/jira/browse/CASSANDRA-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401656#comment-17401656
]
Andres de la Peña commented on CASSANDRA-16868:
---
||PR||CI||
|[3.0|https://github.com/apache/cassandra/pull/1155]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/783/workflows/954778ef-199d-451b-adeb-cd4c03e0d922]|
|[3.11|https://github.com/apache/cassandra/pull/1157]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/784/workflows/abcc7cef-3cdb-419d-940c-df745f8fa66f]|
|[4.0|https://github.com/apache/cassandra/pull/1156]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/785/workflows/299ead54-3f33-4dca-a2a0-851cb33c7755]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/785/workflows/38cc77a3-9a76-4392-98c7-1bccb04bcd33]|
|[trunk|https://github.com/apache/cassandra/pull/1158]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/786/workflows/cce0fcd3-fb70-444a-9965-7cf015e8a9b8]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/786/workflows/b218de99-b598-4f2d-bbf1-c8c21476e6f8]|
> Secondary indexes on primary key columns can miss some writes
> -
>
> Key: CASSANDRA-16868
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16868
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Secondary indexes on primary key columns can miss some writes. For example,
> an update after a deletion won't create an index entry:
> {code:java}
> CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
> CREATE INDEX ON t(ck);
> INSERT INTO t(pk, ck, v) VALUES (1, 2, 3); -- creates an index entry (right)
> DELETE FROM t WHERE pk = 1 AND ck = 2; -- deletes the previous index entry
> (right)
> UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create a new index
> entry (wrong)
> SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
> {code}
> This happens because the update uses the {{LivenssInfo}} of the previously
> deleted row (see
> [here|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L439]).
> The same happens when updating an expired row:
> {code:java}
> CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
> CREATE INDEX ON t(ck);
> UPDATE t USING TTL 1 SET v = 3 WHERE pk = 1 AND ck = 2; -- creates a
> non-expiring index entry (right)
> -- wait for the expiration of the above row
> SELECT * FROM t WHERE ck = 2; -- deletes the index entry (right)
> UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create an index entry
> (wrong)
> SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
> {code}
> I think that the fix for this is just using the
> {{getPrimaryKeyIndexLiveness}} in {{updateRow}}, as it's used in
> {{insertRow}}.
> Another related problem is that {{getPrimaryKeyIndexLiveness}} uses [the most
> recent TTL in the columns contained on the indexed row
> fragment|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L519]
> as the TTL of the index entry, producing an expiring index entry that
> ignores the columns without TTL that are already present in flushed sstables.
> So we can find this other error when setting a TTL over flushed indexed data:
> {code:java}
> CREATE TABLE t(k1 int, k2 int, v int, PRIMARY KEY ((k1, k2)));
> CREATE INDEX idx ON t(k1);
> INSERT INTO t (k1, k2, v) VALUES (1, 2, 3);
> -- flush
> UPDATE t USING TTL 1 SET v=0 WHERE k1=1 AND k2=2; -- creates an index entry
> with TTL (wrong)
> -- wait for TTL expiration
> SELECT TTL(v) FROM t WHERE k1=1; -- doesn't find the row (wrong)
> {code}
> The straightforward fix is just ignoring the TTL of the columns for indexes
> on primary key components, so we don't produce expiring index entries in that
> case. The index entries will be eventually deleted during index reads, when
> we are sure that they are not pointing to any live data.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16867) DOC - Documentation page for Hints has a broken table
[ https://issues.apache.org/jira/browse/CASSANDRA-16867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16867: - Change Category: Semantic Complexity: Low Hanging Fruit Assignee: Erick Ramirez Status: Open (was: Triage Needed) > DOC - Documentation page for Hints has a broken table > - > > Key: CASSANDRA-16867 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16867 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Andy Moore >Assignee: Erick Ramirez >Priority: Low > > The Cassandra Documentation page for Hints: > [https://cassandra.apache.org/doc/latest/cassandra/operating/hints.html] > has a problem with Table 1: Settings for Hints. > On the second row of the table, part of the Description column, the example, > has "wrapped" into the next Cell in the second row, in the Default Value > column. > > This has then resulted in all the following cells from the third row onwards > being bumped along one Cell. > > The Setting Column contains the value of the Default Value Column from the > previous row > The Description Column contains the value of the Setting Column > The Default Value Column contains the value of the Description Column -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16867) DOC - Documentation page for Hints has a broken table
[ https://issues.apache.org/jira/browse/CASSANDRA-16867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16867: - Priority: Low (was: High) > DOC - Documentation page for Hints has a broken table > - > > Key: CASSANDRA-16867 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16867 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Andy Moore >Priority: Low > > The Cassandra Documentation page for Hints: > [https://cassandra.apache.org/doc/latest/cassandra/operating/hints.html] > has a problem with Table 1: Settings for Hints. > On the second row of the table, part of the Description column, the example, > has "wrapped" into the next Cell in the second row, in the Default Value > column. > > This has then resulted in all the following cells from the third row onwards > being bumped along one Cell. > > The Setting Column contains the value of the Default Value Column from the > previous row > The Description Column contains the value of the Setting Column > The Default Value Column contains the value of the Description Column -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16868) Secondary indexes on primary key columns can miss some writes
[
https://issues.apache.org/jira/browse/CASSANDRA-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16868:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable
Corruption / Loss(12986)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 4.x
4.0.x
3.11.x
3.0.x
Severity: Normal
Status: Open (was: Triage Needed)
> Secondary indexes on primary key columns can miss some writes
> -
>
> Key: CASSANDRA-16868
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16868
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Secondary indexes on primary key columns can miss some writes. For example,
> an update after a deletion won't create an index entry:
> {code:java}
> CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
> CREATE INDEX ON t(ck);
> INSERT INTO t(pk, ck, v) VALUES (1, 2, 3); -- creates an index entry (right)
> DELETE FROM t WHERE pk = 1 AND ck = 2; -- deletes the previous index entry
> (right)
> UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create a new index
> entry (wrong)
> SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
> {code}
> This happens because the update uses the {{LivenssInfo}} of the previously
> deleted row (see
> [here|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L439]).
> The same happens when updating an expired row:
> {code:java}
> CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
> CREATE INDEX ON t(ck);
> UPDATE t USING TTL 1 SET v = 3 WHERE pk = 1 AND ck = 2; -- creates a
> non-expiring index entry (right)
> -- wait for the expiration of the above row
> SELECT * FROM t WHERE ck = 2; -- deletes the index entry (right)
> UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create an index entry
> (wrong)
> SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
> {code}
> I think that the fix for this is just using the
> {{getPrimaryKeyIndexLiveness}} in {{updateRow}}, as it's used in
> {{insertRow}}.
> Another related problem is that {{getPrimaryKeyIndexLiveness}} uses [the most
> recent TTL in the columns contained on the indexed row
> fragment|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L519]
> as the TTL of the index entry, producing an expiring index entry that
> ignores the columns without TTL that are already present in flushed sstables.
> So we can find this other error when setting a TTL over flushed indexed data:
> {code:java}
> CREATE TABLE t(k1 int, k2 int, v int, PRIMARY KEY ((k1, k2)));
> CREATE INDEX idx ON t(k1);
> INSERT INTO t (k1, k2, v) VALUES (1, 2, 3);
> -- flush
> UPDATE t USING TTL 1 SET v=0 WHERE k1=1 AND k2=2; -- creates an index entry
> with TTL (wrong)
> -- wait for TTL expiration
> SELECT TTL(v) FROM t WHERE k1=1; -- doesn't find the row (wrong)
> {code}
> The straightforward fix is just ignoring the TTL of the columns for indexes
> on primary key components, so we don't produce expiring index entries in that
> case. The index entries will be eventually deleted during index reads, when
> we are sure that they are not pointing to any live data.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16868) Secondary indexes on primary key columns can miss some writes
[
https://issues.apache.org/jira/browse/CASSANDRA-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16868:
--
Test and Documentation Plan: The PR contains unit tests for the problematic
use cases
Status: Patch Available (was: Open)
> Secondary indexes on primary key columns can miss some writes
> -
>
> Key: CASSANDRA-16868
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16868
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Secondary indexes on primary key columns can miss some writes. For example,
> an update after a deletion won't create an index entry:
> {code:java}
> CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
> CREATE INDEX ON t(ck);
> INSERT INTO t(pk, ck, v) VALUES (1, 2, 3); -- creates an index entry (right)
> DELETE FROM t WHERE pk = 1 AND ck = 2; -- deletes the previous index entry
> (right)
> UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create a new index
> entry (wrong)
> SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
> {code}
> This happens because the update uses the {{LivenssInfo}} of the previously
> deleted row (see
> [here|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L439]).
> The same happens when updating an expired row:
> {code:java}
> CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
> CREATE INDEX ON t(ck);
> UPDATE t USING TTL 1 SET v = 3 WHERE pk = 1 AND ck = 2; -- creates a
> non-expiring index entry (right)
> -- wait for the expiration of the above row
> SELECT * FROM t WHERE ck = 2; -- deletes the index entry (right)
> UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create an index entry
> (wrong)
> SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
> {code}
> I think that the fix for this is just using the
> {{getPrimaryKeyIndexLiveness}} in {{updateRow}}, as it's used in
> {{insertRow}}.
> Another related problem is that {{getPrimaryKeyIndexLiveness}} uses [the most
> recent TTL in the columns contained on the indexed row
> fragment|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L519]
> as the TTL of the index entry, producing an expiring index entry that
> ignores the columns without TTL that are already present in flushed sstables.
> So we can find this other error when setting a TTL over flushed indexed data:
> {code:java}
> CREATE TABLE t(k1 int, k2 int, v int, PRIMARY KEY ((k1, k2)));
> CREATE INDEX idx ON t(k1);
> INSERT INTO t (k1, k2, v) VALUES (1, 2, 3);
> -- flush
> UPDATE t USING TTL 1 SET v=0 WHERE k1=1 AND k2=2; -- creates an index entry
> with TTL (wrong)
> -- wait for TTL expiration
> SELECT TTL(v) FROM t WHERE k1=1; -- doesn't find the row (wrong)
> {code}
> The straightforward fix is just ignoring the TTL of the columns for indexes
> on primary key components, so we don't produce expiring index entries in that
> case. The index entries will be eventually deleted during index reads, when
> we are sure that they are not pointing to any live data.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16868) Secondary indexes on primary key columns can miss some writes
Andres de la Peña created CASSANDRA-16868:
-
Summary: Secondary indexes on primary key columns can miss some
writes
Key: CASSANDRA-16868
URL: https://issues.apache.org/jira/browse/CASSANDRA-16868
Project: Cassandra
Issue Type: Bug
Components: Feature/2i Index
Reporter: Andres de la Peña
Assignee: Andres de la Peña
Secondary indexes on primary key columns can miss some writes. For example, an
update after a deletion won't create an index entry:
{code:java}
CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
CREATE INDEX ON t(ck);
INSERT INTO t(pk, ck, v) VALUES (1, 2, 3); -- creates an index entry (right)
DELETE FROM t WHERE pk = 1 AND ck = 2; -- deletes the previous index entry
(right)
UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create a new index entry
(wrong)
SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
{code}
This happens because the update uses the {{LivenssInfo}} of the previously
deleted row (see
[here|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L439]).
The same happens when updating an expired row:
{code:java}
CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
CREATE INDEX ON t(ck);
UPDATE t USING TTL 1 SET v = 3 WHERE pk = 1 AND ck = 2; -- creates a
non-expiring index entry (right)
-- wait for the expiration of the above row
SELECT * FROM t WHERE ck = 2; -- deletes the index entry (right)
UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create an index entry
(wrong)
SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
{code}
I think that the fix for this is just using the {{getPrimaryKeyIndexLiveness}}
in {{updateRow}}, as it's used in {{insertRow}}.
Another related problem is that {{getPrimaryKeyIndexLiveness}} uses [the most
recent TTL in the columns contained on the indexed row
fragment|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L519]
as the TTL of the index entry, producing an expiring index entry that ignores
the columns without TTL that are already present in flushed sstables. So we can
find this other error when setting a TTL over flushed indexed data:
{code:java}
CREATE TABLE t(k1 int, k2 int, v int, PRIMARY KEY ((k1, k2)));
CREATE INDEX idx ON t(k1);
INSERT INTO t (k1, k2, v) VALUES (1, 2, 3);
-- flush
UPDATE t USING TTL 1 SET v=0 WHERE k1=1 AND k2=2; -- creates an index entry
with TTL (wrong)
-- wait for TTL expiration
SELECT TTL(v) FROM t WHERE k1=1; -- doesn't find the row (wrong)
{code}
The straightforward fix is just ignoring the TTL of the columns for indexes on
primary key components, so we don't produce expiring index entries in that
case. The index entries will be eventually deleted during index reads, when we
are sure that they are not pointing to any live data.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16867) DOC - Documentation page for Hints has a broken table
Andy Moore created CASSANDRA-16867: -- Summary: DOC - Documentation page for Hints has a broken table Key: CASSANDRA-16867 URL: https://issues.apache.org/jira/browse/CASSANDRA-16867 Project: Cassandra Issue Type: Task Components: Documentation/Website Reporter: Andy Moore The Cassandra Documentation page for Hints: [https://cassandra.apache.org/doc/latest/cassandra/operating/hints.html] has a problem with Table 1: Settings for Hints. On the second row of the table, part of the Description column, the example, has "wrapped" into the next Cell in the second row, in the Default Value column. This has then resulted in all the following cells from the third row onwards being bumped along one Cell. The Setting Column contains the value of the Default Value Column from the previous row The Description Column contains the value of the Setting Column The Default Value Column contains the value of the Description Column -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16867) DOC - Documentation page for Hints has a broken table
[ https://issues.apache.org/jira/browse/CASSANDRA-16867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Moore updated CASSANDRA-16867: --- Priority: High (was: Normal) > DOC - Documentation page for Hints has a broken table > - > > Key: CASSANDRA-16867 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16867 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Andy Moore >Priority: High > > The Cassandra Documentation page for Hints: > [https://cassandra.apache.org/doc/latest/cassandra/operating/hints.html] > has a problem with Table 1: Settings for Hints. > On the second row of the table, part of the Description column, the example, > has "wrapped" into the next Cell in the second row, in the Default Value > column. > > This has then resulted in all the following cells from the third row onwards > being bumped along one Cell. > > The Setting Column contains the value of the Default Value Column from the > previous row > The Description Column contains the value of the Setting Column > The Default Value Column contains the value of the Description Column -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13874) nodetool setcachecapacity behaves oddly when cache disabled
[ https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401568#comment-17401568 ] Berenguer Blasi edited comment on CASSANDRA-13874 at 8/19/21, 10:28 AM: I reworded the message a bit [here|https://github.com/apache/cassandra/pull/1154] and fired CI. [~vane] do you fancy trying out 4.0 and trunk PRs? Edit: [CI|https://app.circleci.com/pipelines/github/bereng/cassandra?branch=CASSANDRA-13874-3.11] LGTM. I will be OOO next week in case you ping was (Author: bereng): I reworded the message a bit [here|https://github.com/apache/cassandra/pull/1154] and fired CI. [~vane] do you fancy trying out 4.0 and trunk PRs? > nodetool setcachecapacity behaves oddly when cache disabled > --- > > Key: CASSANDRA-13874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13874 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Local/Config >Reporter: Jon Haddad >Assignee: Michal Szczepanski >Priority: Low > Labels: lhf, user-experience > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: 13874-trunk.txt > > > If a node has row cache disabled, trying to turn it on via setcachecapacity > doesn't issue an error, and doesn't turn it on, it just silently doesn't work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16725) Implement nodetool getauditlog command
[ https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16725: -- Source Control Link: https://github.com/apache/cassandra/commit/b286639eea11b5f6ee709711d00d36aa029bc114 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Implement nodetool getauditlog command > -- > > Key: CASSANDRA-16725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16725 > Project: Cassandra > Issue Type: New Feature > Components: Tool/auditlogging >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 15h 20m > Remaining Estimate: 0h > > There is getfullquerylog already, there is not any reason why getauditlog > should not be there too. A user can not retrieve runtime configuration of > Audit log, it might be only enabled and disabled via jmx but its state can > not be queried in runtime. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (0581820 -> b286639)
This is an automated email from the ASF dual-hosted git repository.
smiklosovic pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git.
from 0581820 Merge branch 'cassandra-4.0' into trunk
add b286639 implement getauditlog command
No new revisions were added by this update.
Summary of changes:
CHANGES.txt| 1 +
.../org/apache/cassandra/audit/AuditLogFilter.java | 15 +-
.../apache/cassandra/audit/AuditLogManager.java| 73 --
...ntryCategory.java => AuditLogManagerMBean.java} | 14 +-
.../apache/cassandra/audit/AuditLogOptions.java| 251 -
.../audit/AuditLogOptionsCompositeData.java| 232 +++
.../org/apache/cassandra/audit/BinAuditLogger.java | 10 +-
.../config/CassandraRelevantProperties.java| 11 +
.../cassandra/config/DatabaseDescriptor.java | 2 +-
.../apache/cassandra/service/StorageService.java | 63 --
.../cassandra/service/StorageServiceMBean.java | 18 +-
src/java/org/apache/cassandra/tools/NodeProbe.java | 26 ++-
src/java/org/apache/cassandra/tools/NodeTool.java | 1 +
.../cassandra/tools/nodetool/EnableAuditLog.java | 32 ++-
.../{GetFullQueryLog.java => GetAuditLog.java} | 22 +-
.../cassandra/tools/nodetool/GetFullQueryLog.java | 2 +-
.../org/apache/cassandra/utils/FBUtilities.java| 18 +-
.../apache/cassandra/audit/AuditLogFilterTest.java | 16 ++
.../cassandra/audit/AuditLogOptionsTest.java | 56 +
.../config/DatabaseDescriptorRefTest.java | 2 +
.../service/StorageServiceServerTest.java | 2 +-
.../cassandra/tools/nodetool/GetAuditLogTest.java | 155 +
22 files changed, 927 insertions(+), 95 deletions(-)
copy src/java/org/apache/cassandra/audit/{AuditLogEntryCategory.java =>
AuditLogManagerMBean.java} (80%)
create mode 100644
src/java/org/apache/cassandra/audit/AuditLogOptionsCompositeData.java
copy src/java/org/apache/cassandra/tools/nodetool/{GetFullQueryLog.java =>
GetAuditLog.java} (63%)
create mode 100644
test/unit/org/apache/cassandra/audit/AuditLogOptionsTest.java
create mode 100644
test/unit/org/apache/cassandra/tools/nodetool/GetAuditLogTest.java
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16789) Add TTL support to nodetool snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abuli Palagashvili updated CASSANDRA-16789:
---
Resolution: Done
Status: Resolved (was: Triage Needed)
> Add TTL support to nodetool snapshots
> -
>
> Key: CASSANDRA-16789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16789
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> Add new parameter {{--ttl}} to {{nodetool snapshot}} command. This parameter
> can be specified in human readable duration (ie. 30mins, 1h, 300d) and should
> not be lower than 1 minute.
> The expiration date should be added to the snapshot manifest in ISO format.
> A periodic thread should efficiently scan snapshots and automatically clear
> those past expiration date. The periodicity of the scan thread should be 1
> minute by default but be overridable via a system property.
> The command {{nodetool listsnapshots}} should display the expiration date
> when the snapshot contains a TTL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16621) Replace spinAsserts code with Awaitility code
[ https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401508#comment-17401508 ] Berenguer Blasi edited comment on CASSANDRA-16621 at 8/19/21, 9:30 AM: --- I just thought we didn't run we didn't run compression, long, etc junits. Let me run a jenkins ci first to be on the safe side. Also next week I am OOO so I might commit when I am back preferably unless Andres beats me to it. Edit: compression & long tests lgtm on circle. But stress and other I'll wait for jenkins to be up again, it's down for maintenance now. was (Author: bereng): I just thought we didn't run we didn't run compression, long, etc junits. Let me run a jenkins ci first to be on the safe side. Also next week I am OOO so I might commit when I am back preferably unless Andres beats me to it. > Replace spinAsserts code with Awaitility code > - > > Key: CASSANDRA-16621 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16621 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Jogesh Anand >Priority: Normal > Labels: low-hanging-fruit > Fix For: 4.0.x > > > Currently spinAsserts does a similar thing to Awaitility which is being used > more and more. We have now 2 ways of doing the same thing so it would be good > to consolidate -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16789) Add TTL support to nodetool snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401572#comment-17401572
]
Abuli Palagashvili commented on CASSANDRA-16789:
[Main PR|https://github.com/apache/cassandra/pull/1046]
[Website|https://github.com/apache/cassandra-website/pull/69]
> Add TTL support to nodetool snapshots
> -
>
> Key: CASSANDRA-16789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16789
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> Add new parameter {{--ttl}} to {{nodetool snapshot}} command. This parameter
> can be specified in human readable duration (ie. 30mins, 1h, 300d) and should
> not be lower than 1 minute.
> The expiration date should be added to the snapshot manifest in ISO format.
> A periodic thread should efficiently scan snapshots and automatically clear
> those past expiration date. The periodicity of the scan thread should be 1
> minute by default but be overridable via a system property.
> The command {{nodetool listsnapshots}} should display the expiration date
> when the snapshot contains a TTL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16789) Add TTL support to nodetool snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401570#comment-17401570
]
Abuli Palagashvili commented on CASSANDRA-16789:
Patch is almost ready.We've added new entities {{TableSnapshot}} and
{{SnapshotManifest}}.Now all information about snapshots (including creation
and expiration times) is stored into this objects.We've also added
{{SnapshotManager}} class for tracking, indexing and removing of expiring
snapshots.We made it a part of {{StorageService}}.Cleanup process is
implemented as regularly run task.Cassandra operator can specify period between
launches.We've also added columns {{CreatedAt}} and {{ExpiresAt}} columns to
{{listsnapshots}} nodetool command output.
> Add TTL support to nodetool snapshots
> -
>
> Key: CASSANDRA-16789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16789
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> Add new parameter {{--ttl}} to {{nodetool snapshot}} command. This parameter
> can be specified in human readable duration (ie. 30mins, 1h, 300d) and should
> not be lower than 1 minute.
> The expiration date should be added to the snapshot manifest in ISO format.
> A periodic thread should efficiently scan snapshots and automatically clear
> those past expiration date. The periodicity of the scan thread should be 1
> minute by default but be overridable via a system property.
> The command {{nodetool listsnapshots}} should display the expiration date
> when the snapshot contains a TTL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13874) nodetool setcachecapacity behaves oddly when cache disabled
[ https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401568#comment-17401568 ] Berenguer Blasi commented on CASSANDRA-13874: - I reworded the message a bit [here|https://github.com/apache/cassandra/pull/1154] and fired CI. [~vane] do you fancy trying out 4.0 and trunk PRs? > nodetool setcachecapacity behaves oddly when cache disabled > --- > > Key: CASSANDRA-13874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13874 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Local/Config >Reporter: Jon Haddad >Assignee: Michal Szczepanski >Priority: Low > Labels: lhf, user-experience > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: 13874-trunk.txt > > > If a node has row cache disabled, trying to turn it on via setcachecapacity > doesn't issue an error, and doesn't turn it on, it just silently doesn't work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13874) nodetool setcachecapacity behaves oddly when cache disabled
[ https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-13874: Summary: nodetool setcachecapacity behaves oddly when cache disabled (was: nodetool setcachecapacity behaves oddly when cache size = 0) > nodetool setcachecapacity behaves oddly when cache disabled > --- > > Key: CASSANDRA-13874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13874 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Local/Config >Reporter: Jon Haddad >Assignee: Michal Szczepanski >Priority: Low > Labels: lhf, user-experience > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: 13874-trunk.txt > > > If a node has row cache disabled, trying to turn it on via setcachecapacity > doesn't issue an error, and doesn't turn it on, it just silently doesn't work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13874) nodetool setcachecapacity behaves oddly when cache size = 0
[ https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-13874: Reviewers: Berenguer Blasi, Jon Haddad (was: Jon Haddad) > nodetool setcachecapacity behaves oddly when cache size = 0 > --- > > Key: CASSANDRA-13874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13874 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Local/Config >Reporter: Jon Haddad >Assignee: Michal Szczepanski >Priority: Low > Labels: lhf, user-experience > Attachments: 13874-trunk.txt > > > If a node has row cache disabled, trying to turn it on via setcachecapacity > doesn't issue an error, and doesn't turn it on, it just silently doesn't work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13874) nodetool setcachecapacity behaves oddly when cache size = 0
[ https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-13874: Fix Version/s: 4.x 4.0.x 3.11.x > nodetool setcachecapacity behaves oddly when cache size = 0 > --- > > Key: CASSANDRA-13874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13874 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Local/Config >Reporter: Jon Haddad >Assignee: Michal Szczepanski >Priority: Low > Labels: lhf, user-experience > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: 13874-trunk.txt > > > If a node has row cache disabled, trying to turn it on via setcachecapacity > doesn't issue an error, and doesn't turn it on, it just silently doesn't work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16621) Replace spinAsserts code with Awaitility code
[ https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401508#comment-17401508 ] Berenguer Blasi commented on CASSANDRA-16621: - I just thought we didn't run we didn't run compression, long, etc junits. Let me run a jenkins ci first to be on the safe side. Also next week I am OOO so I might commit when I am back preferably unless Andres beats me to it. > Replace spinAsserts code with Awaitility code > - > > Key: CASSANDRA-16621 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16621 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Jogesh Anand >Priority: Normal > Labels: low-hanging-fruit > Fix For: 4.0.x > > > Currently spinAsserts does a similar thing to Awaitility which is being used > more and more. We have now 2 ways of doing the same thing so it would be good > to consolidate -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16863) Ignore repair requests in mixed mode
[
https://issues.apache.org/jira/browse/CASSANDRA-16863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16863:
Test and Documentation Plan: See PR
Status: Patch Available (was: In Progress)
> Ignore repair requests in mixed mode
>
>
> Key: CASSANDRA-16863
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16863
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x
>
>
> Repairs in mixed mode are not supported. On 4.0 we have CASSANDRA-13944 but
> <4.0 there is nothing preventing NPE and other scares in the logs. These
> cause unnecessary noise to operators.
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at
> org.apache.cassandra.service.ActiveRepairService.getParentRepairSession(ActiveRepairService.java:423)
> at
> org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:93)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
