[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722002#comment-17722002
]
Manish Ghildiyal commented on CASSANDRA-18305:
--
*compaction throughput 13.2 MBps / 16 MBps (82.5%)*
I guess 16 MBps here is the value mentioned in cassandra.yaml.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (b1519766 -> 846508d8)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard b1519766 generate docs for 8b85ed85 new 846508d8 generate docs for 8b85ed85 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (b1519766) \ N -- N -- N refs/heads/asf-staging (846508d8) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (b391473b -> b1519766)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard b391473b generate docs for 8b85ed85 new b1519766 generate docs for 8b85ed85 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (b391473b) \ N -- N -- N refs/heads/asf-staging (b1519766) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18511) Add support for JMX in the in-jvm dtest framework
[ https://issues.apache.org/jira/browse/CASSANDRA-18511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721975#comment-17721975 ] Doug Rohrer commented on CASSANDRA-18511: - NOTE: To actually commit & release this, we'll need to raise a vote to release the next iteration of the in-jvm dtest api as well, and get the non-snapshot build published. > Add support for JMX in the in-jvm dtest framework > - > > Key: CASSANDRA-18511 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18511 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Doug Rohrer >Assignee: Doug Rohrer >Priority: Normal > Labels: pull-request-available > Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > In many cases, it would be useful to be able to enable JMX endpoints within > the in-jvm dtest framework, including the existing JMX Getter test, which > used to simply spin up a JMX registry and then leave it running. There are > quite a few JMX-related functions that don’t have tests today, and some > external usages of the in-jvm dtest framework could also benefit from > exposing JMX like we did Native before. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18511) Add support for JMX in the in-jvm dtest framework
[ https://issues.apache.org/jira/browse/CASSANDRA-18511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721359#comment-17721359 ] Doug Rohrer edited comment on CASSANDRA-18511 at 5/12/23 1:51 AM: -- in-jvm-dtest change: [https://github.com/apache/cassandra-in-jvm-dtest-api/pull/34] -Once we have a snapshot build of the API I'll post PRs for trunk/4.1/4.0/3.11- Trunk patch: [https://github.com/apache/cassandra/pull/2318] 4.1: [https://github.com/apache/cassandra/pull/2328] 4.0: [https://github.com/apache/cassandra/pull/2326] 3.11: [https://github.com/apache/cassandra/pull/2322] Circle CI builds: Trunk: [java8_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/61/workflows/d66e58c2-e4b8-4be5-aab6-67dca04acda1] [java11_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/61/workflows/252cfa8b-8dd2-48ca-91e2-35a238bb9afb] 4.1: [java8_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/62/workflows/db90513b-b962-4068-97e1-3f86204213ca] [java11_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/62/workflows/fe854086-6762-4d1d-8a54-fe7f3bb85e5e] 4.0: [java8_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/60/workflows/fca92510-aa38-486a-9a65-600662817991] [java11_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/60/workflows/99ba34a6-f3df-4e4b-9dbe-cdd3a0b86a6c] 3.11 [java8_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/59/workflows/b3b5a8d7-a515-49cf-813e-2c2dd08aceb9] (One unrelated failed in-jvm-dtest that I've seen a few times so far: testReprepareMixedVersionWithoutReset) was (Author: drohrer): in-jvm-dtest change: [https://github.com/apache/cassandra-in-jvm-dtest-api/pull/34] -Once we have a snapshot build of the API I'll post PRs for trunk/4.1/4.0/3.11- Trunk patch: [https://github.com/apache/cassandra/pull/2318] 4.0: [https://github.com/apache/cassandra/pull/2326] 3.11: [https://github.com/apache/cassandra/pull/2322] > Add support for JMX in the in-jvm dtest framework > - > > Key: CASSANDRA-18511 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18511 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Doug Rohrer >Assignee: Doug Rohrer >Priority: Normal > Labels: pull-request-available > Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > In many cases, it would be useful to be able to enable JMX endpoints within > the in-jvm dtest framework, including the existing JMX Getter test, which > used to simply spin up a JMX registry and then leave it running. There are > quite a few JMX-related functions that don’t have tests today, and some > external usages of the in-jvm dtest framework could also benefit from > exposing JMX like we did Native before. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18401) Investigate preloading ccm repositories in the docker image
[ https://issues.apache.org/jira/browse/CASSANDRA-18401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721939#comment-17721939 ] Ekaterina Dimitrova commented on CASSANDRA-18401: - >From CASSANDRA-18472: [3.0|https://app.circleci.com/pipelines/github/driftx/cassandra/1000/workflows/6a1490e5-0328-4d9a-b051-99be2d3490c5], [3.11|https://app.circleci.com/pipelines/github/driftx/cassandra/999/workflows/756643b4-2cae-4d81-8be9-0af81cc2f9dd], 4.0 - [j8|https://app.circleci.com/pipelines/github/driftx/cassandra/980/workflows/d35e83b3-e59e-41ee-af08-e1324271037f] and [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/980/workflows/836841a0-ebd3-4cef-a123-14c21b424174] 4.1 - [j8|https://app.circleci.com/pipelines/github/driftx/cassandra/979/workflows/a2d0a0c7-5ca3-4877-ae36-6d5c4a2434d9] and [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/979/workflows/298c67a3-0c43-4e7d-9f2d-bd148c868a2b] trunk - [j8|https://app.circleci.com/pipelines/github/driftx/cassandra/984/workflows/be07089a-3f8a-431f-81ea-85abca5ab868] and [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/984/workflows/93b4ac7f-45e6-4311-a5a4-e6bf28e9f130] I also started JDK11+17 workflow [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18401-trunk-17] I also pushed again the following jobs after rebase as they had some issues in your runs which I suspect being only infra related but just in case: - 4.0 j8_cqlsh_dtests_py311_vnode - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2349/workflows/da7b54a5-daa5-47c1-88f4-ace84d2d83e4 - 4.1 j8_dtests_vnode - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2348/workflows/855ad7f3-248d-48b5-bff6-982ddecf84d2 I will check it tomorrow morning and upon no new surprises, I will push to docker hub > Investigate preloading ccm repositories in the docker image > --- > > Key: CASSANDRA-18401 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18401 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > In CASSANDRA-18391 it was discovered that to skip some upgrade tests, the ccm > repository first needed to be populated with older versions. While that case > was solved, it may still be beneficial to preload the ccm repositories in the > docker image so they don't need to be fetched at all. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18479) Add basic text tokenisation and analysis
[ https://issues.apache.org/jira/browse/CASSANDRA-18479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18479: Reviewers: Caleb Rackliffe > Add basic text tokenisation and analysis > > > Key: CASSANDRA-18479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18479 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Mike Adamson >Priority: Normal > > [CASSANDRA-16092|https://issues.apache.org/jira/browse/CASSANDRA-16092] > removed support for any text analysis or tokenisation. > SAI currently supports the following analyzers: > * normalize - text normalization using NFC normalization > * case_sensitive - allow control over the case sensitivity of an index > * ascii - allow ascii folding of text -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18479) Add basic text tokenisation and analysis
[
https://issues.apache.org/jira/browse/CASSANDRA-18479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721937#comment-17721937
]
Caleb Rackliffe commented on CASSANDRA-18479:
-
I've created a new {{cep-7-sai}}
[branch|https://github.com/apache/cassandra/tree/cep-7-sai] in the ASF repo.
You should be able to switch your target branch w/o any issues, as it should be
identical to my {{CASSANDRA-16052}} branch. A trunk rebase will be necessary
soon, but that can proceed after the trie-indexed SSTables stuff merges to
trunk.
> Add basic text tokenisation and analysis
>
>
> Key: CASSANDRA-18479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18479
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Mike Adamson
>Priority: Normal
>
> [CASSANDRA-16092|https://issues.apache.org/jira/browse/CASSANDRA-16092]
> removed support for any text analysis or tokenisation.
> SAI currently supports the following analyzers:
> * normalize - text normalization using NFC normalization
> * case_sensitive - allow control over the case sensitivity of an index
> * ascii - allow ascii folding of text
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18401) Investigate preloading ccm repositories in the docker image
[ https://issues.apache.org/jira/browse/CASSANDRA-18401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18401: Fix Version/s: 4.1.x > Investigate preloading ccm repositories in the docker image > --- > > Key: CASSANDRA-18401 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18401 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > In CASSANDRA-18391 it was discovered that to skip some upgrade tests, the ccm > repository first needed to be populated with older versions. While that case > was solved, it may still be beneficial to preload the ccm repositories in the > docker image so they don't need to be fetched at all. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16052) CEP-7 Storage Attached Indexes (Phase 1)
[
https://issues.apache.org/jira/browse/CASSANDRA-16052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721933#comment-17721933
]
Caleb Rackliffe commented on CASSANDRA-16052:
-
I've created a new {{cep-7-sai}}
[branch|https://github.com/apache/cassandra/tree/cep-7-sai] in the ASF repo.
You should be able to switch your target branch w/o any issues, as it should be
identical to my {{CASSANDRA-16052}} branch. A trunk rebase will be necessary
soon, but that can proceed after the trie-indexed SSTables stuff merges to
trunk.
There is also a new pull request based on trunk
[here|https://github.com/apache/cassandra/pull/2327].
> CEP-7 Storage Attached Indexes (Phase 1)
>
>
> Key: CASSANDRA-16052
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16052
> Project: Cassandra
> Issue Type: Epic
> Components: Feature/2i Index, Feature/SAI
>Reporter: Zhao Yang
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: SAI
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> [CEP|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-7%3A+Storage+Attached+Index]
> - A new index implementation, called Storage
> Attached Index(SAI), based on the advancement made by SASI.
> * disk usage by sharing of common data between multiple column indexes on
> the same table and better compression of on-disk structures.
> * numeric range query performance with modified KDTree and collection type
> support.
> * compaction performance and stability for larger data set.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18067) On-disk numeric index
[
https://issues.apache.org/jira/browse/CASSANDRA-18067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721931#comment-17721931
]
Caleb Rackliffe commented on CASSANDRA-18067:
-
I've created a new {{cep-7-sai}}
[branch|https://github.com/apache/cassandra/tree/cep-7-sai] in the ASF repo.
You should be able to switch your target branch w/o any issues, as it should be
identical to my {{CASSANDRA-16052}} branch. A trunk rebase will be necessary
soon, but that can proceed after the trie-indexed SSTables stuff merges to
trunk.
> On-disk numeric index
> -
>
> Key: CASSANDRA-18067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18067
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/SAI
>Reporter: Mike Adamson
>Assignee: Mike Adamson
>Priority: Normal
> Labels: SAI
> Fix For: NA
>
>
> An on-disk numeric index for all datatypes not supported by the on-disk
> literal index (CASSANDRA-18062)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18217) Allow CQL queries on multiple indexes without ALLOW FILTERING
[
https://issues.apache.org/jira/browse/CASSANDRA-18217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721930#comment-17721930
]
Caleb Rackliffe commented on CASSANDRA-18217:
-
I've created a new {{cep-7-sai}}
[branch|https://github.com/apache/cassandra/tree/cep-7-sai] in the ASF repo.
You should be able to switch your target branch w/o any issues, as it should be
identical to my {{CASSANDRA-16052}} branch. A trunk rebase will be necessary
soon, but that can proceed after the trie-indexed SSTables stuff merges to
trunk.
> Allow CQL queries on multiple indexes without ALLOW FILTERING
> -
>
> Key: CASSANDRA-18217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18217
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Mike Adamson
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: SAI
>
> The Index Group index was added by
> [CASSANDRA-16092|https://issues.apache.org/jira/browse/CASSANDRA-16092] to
> allow indexes to be grouped and have more than one index expression in a
> query. This did not make any changes to StatementRestrictions so CQL queries
> using multiple index expression still need to add ALLOW FILTERING to the
> query to be valid.
> This restriction should be removed such that any number of index expressions
> can be used on a CQL query without needing ALLOW FILTERING.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cep-7-sai created (now b45f47d709)
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a change to branch cep-7-sai in repository https://gitbox.apache.org/repos/asf/cassandra.git at b45f47d709 Literal on-disk index and index write path (#9) No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18521) Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
[
https://issues.apache.org/jira/browse/CASSANDRA-18521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18521:
Change Category: Code Clarity
Complexity: Normal
Fix Version/s: NA
Status: Open (was: Triage Needed)
> Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
>
>
> Key: CASSANDRA-18521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18521
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: NA
>
>
> It has been
> [mentioned|https://github.com/maedhroz/cassandra/pull/11#discussion_r1190166765]
> in CASSANDRA-18217 that {{CQLTester#waitForIndex}} and
> {{SAITester#waitForIndexQueryable}} can be unified into a single method.
> The same discussion mentions that it's easy to forget to call those methods
> after calling {{CQLTester#createIndex}}. So that method can be renamed to
> {{createIndexAsync}}, and we can create a new method that creates the index
> and waits for it ({{createIndexSync}}, {{createIndexAndWaitForQueryable}}, or
> something like that).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18401) Investigate preloading ccm repositories in the docker image
[ https://issues.apache.org/jira/browse/CASSANDRA-18401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721929#comment-17721929 ] Brandon Williams commented on CASSANDRA-18401: -- bq. Is there a CI run with the new image available? This was already committed so the runs on CASSANDRA-18472 should be it. > Investigate preloading ccm repositories in the docker image > --- > > Key: CASSANDRA-18401 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18401 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 5.x > > > In CASSANDRA-18391 it was discovered that to skip some upgrade tests, the ccm > repository first needed to be populated with older versions. While that case > was solved, it may still be beneficial to preload the ccm repositories in the > docker image so they don't need to be fetched at all. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18217) Allow CQL queries on multiple indexes without ALLOW FILTERING
[ https://issues.apache.org/jira/browse/CASSANDRA-18217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721928#comment-17721928 ] Caleb Rackliffe commented on CASSANDRA-18217: - [~adelapena] Indeed, that is long overdue. I'm going to start on that shortly... > Allow CQL queries on multiple indexes without ALLOW FILTERING > - > > Key: CASSANDRA-18217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18217 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Andres de la Peña >Priority: Normal > Labels: SAI > > The Index Group index was added by > [CASSANDRA-16092|https://issues.apache.org/jira/browse/CASSANDRA-16092] to > allow indexes to be grouped and have more than one index expression in a > query. This did not make any changes to StatementRestrictions so CQL queries > using multiple index expression still need to add ALLOW FILTERING to the > query to be valid. > This restriction should be removed such that any number of index expressions > can be used on a CQL query without needing ALLOW FILTERING. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18217) Allow CQL queries on multiple indexes without ALLOW FILTERING
[ https://issues.apache.org/jira/browse/CASSANDRA-18217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721926#comment-17721926 ] Andres de la Peña commented on CASSANDRA-18217: --- [~maedhroz] perhaps this is a good moment to move the feature branch to the ASF repo, like in the [cep-15-accord|https://github.com/apache/cassandra/tree/cep-15-accord] and [cep-21-tcm|https://github.com/apache/cassandra/tree/cep-21-tcm] branches, so everyone can push patches when they are ready to commit? > Allow CQL queries on multiple indexes without ALLOW FILTERING > - > > Key: CASSANDRA-18217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18217 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Andres de la Peña >Priority: Normal > Labels: SAI > > The Index Group index was added by > [CASSANDRA-16092|https://issues.apache.org/jira/browse/CASSANDRA-16092] to > allow indexes to be grouped and have more than one index expression in a > query. This did not make any changes to StatementRestrictions so CQL queries > using multiple index expression still need to add ALLOW FILTERING to the > query to be valid. > This restriction should be removed such that any number of index expressions > can be used on a CQL query without needing ALLOW FILTERING. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18511) Add support for JMX in the in-jvm dtest framework
[ https://issues.apache.org/jira/browse/CASSANDRA-18511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721359#comment-17721359 ] Doug Rohrer edited comment on CASSANDRA-18511 at 5/11/23 9:18 PM: -- in-jvm-dtest change: [https://github.com/apache/cassandra-in-jvm-dtest-api/pull/34] -Once we have a snapshot build of the API I'll post PRs for trunk/4.1/4.0/3.11- Trunk patch: [https://github.com/apache/cassandra/pull/2318] 4.0: [https://github.com/apache/cassandra/pull/2326] 3.11: [https://github.com/apache/cassandra/pull/2322] was (Author: drohrer): in-jvm-dtest change: [https://github.com/apache/cassandra-in-jvm-dtest-api/pull/34] -Once we have a snapshot build of the API I'll post PRs for trunk/4.1/4.0/3.11- Trunk patch: [https://github.com/apache/cassandra/pull/2318] (working on backports) > Add support for JMX in the in-jvm dtest framework > - > > Key: CASSANDRA-18511 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18511 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Doug Rohrer >Assignee: Doug Rohrer >Priority: Normal > Labels: pull-request-available > Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0 > > Time Spent: 2h > Remaining Estimate: 0h > > In many cases, it would be useful to be able to enable JMX endpoints within > the in-jvm dtest framework, including the existing JMX Getter test, which > used to simply spin up a JMX registry and then leave it running. There are > quite a few JMX-related functions that don’t have tests today, and some > external usages of the in-jvm dtest framework could also benefit from > exposing JMX like we did Native before. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18519) CEP-15: (C*) Add notion of CommandsForRanges and make this durable in C*
[ https://issues.apache.org/jira/browse/CASSANDRA-18519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721916#comment-17721916 ] David Capwell commented on CASSANDRA-18519: --- Update: I have the following working 1) when we see a range command, update its state into a IntervalTree at the end of the operation* 2) when we create a AccordCommandStore load the range commands from the commands table; block all processing until this is done Next: * In loader, when we see a range command, walk the CommandsForKeys table to find all keys to include in the context. * Update the mapReduce functions to work with range commands using the interval map * Testing on the Cassandra side Notes: * our range include/exclude may not match the interval tree; need to validate this... so there maybe issues with specific keys due to this... but core logic is there > CEP-15: (C*) Add notion of CommandsForRanges and make this durable in C* > > > Key: CASSANDRA-18519 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18519 > Project: Cassandra > Issue Type: Task > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > > To add support for range transactions in C* we need to make sure > 1) their state is durable and can be recovered on restart > 2) have some way to find all CommandsForKey that are contained in the range > transaction range > 3) have some way to find all CommandsForRange that intersect this range > To do this, I propose the following > 1) Create a new commands_for_range table that stores: (store, range) -> > list — this is byId, not sure if repair needs > byExecuteId as well > 2) For C*, store a in-memory mapping of Range -> List, and on-boot > repopulate this cache. This then can be used to construct the > CommandsForRange needed by the transaction. This makes an assumption that > many ranges will not exist, at least for the time being. > 3) Change commands_for_keys to use LocalPartitioner, and order the table by > (store, key) > 4) When C* sees a range transaction, find all keys that are contained by the > range by running the logical query "SELECT key FROM commands_for_keys WHERE > key BETWEEN range.start AND range.end". Implementation has to make sure to > handle many keys (may need to partition the range to increase parallel > access, and may need to page through the table to see all keys (aka multiple > ReadCommands)). Once all keys are found, then must load into the > CommandsForKeys cache > For #4, https://github.com/apache/cassandra-accord/pull/27 maybe able to > optimize the logic to lazy load only what is actually needed rather than load > the whole world -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18401) Investigate preloading ccm repositories in the docker image
[ https://issues.apache.org/jira/browse/CASSANDRA-18401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721897#comment-17721897 ] Ekaterina Dimitrova commented on CASSANDRA-18401: - Is there a CI run with the new image available? Would be nice also to push the new image also with the new JDK 17 CircleCI config, just in case > Investigate preloading ccm repositories in the docker image > --- > > Key: CASSANDRA-18401 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18401 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 5.x > > > In CASSANDRA-18391 it was discovered that to skip some upgrade tests, the ccm > repository first needed to be populated with older versions. While that case > was solved, it may still be beneficial to preload the ccm repositories in the > docker image so they don't need to be fetched at all. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17687) Remove "--frames" option when generating javadoc
[ https://issues.apache.org/jira/browse/CASSANDRA-17687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721893#comment-17721893 ] Ekaterina Dimitrova commented on CASSANDRA-17687: - CASSANDRA-18467 is about generate-idea-files and IntelliJ IDEA, this one is about the java doc. Maybe you meant - CASSANDRA-18255? > Remove "--frames" option when generating javadoc > > > Key: CASSANDRA-17687 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17687 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Zili Chen >Assignee: Zili Chen >Priority: Normal > Fix For: 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > JDK17 doesn't support this option and it seems not quite necessary. For > forward compatibility I propose we can remove this option. > Related JDK issue: [https://bugs.openjdk.org/browse/JDK-8215599] > I volunteer to prepare a patch if this is in a good direction. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18398) CEP-25: Trie-indexed SSTable format
[
https://issues.apache.org/jira/browse/CASSANDRA-18398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721889#comment-17721889
]
Caleb Rackliffe commented on CASSANDRA-18398:
-
I was looking at something else, and stumbled across the documentation for
{{column_index_size}} in {{cassandra.yaml}}...
{noformat}
# Granularity of the collation index of rows within a partition.
# Increase if your rows are large, or if you have a very large
# number of rows per partition. The competing goals are these:
#
# - a smaller granularity means more index entries are generated
# and looking up rows withing the partition by collation column
# is faster
# - but, Cassandra will keep the collation index in memory for hot
# rows (as part of the key cache), so a larger granularity means
# you can cache more hot rows
# Min unit: KiB
column_index_size: 64KiB
{noformat}
Given at least the key cache bits of this inline documentation are not relevant
for the {{bti}} format, should we make some minor changes there?
> CEP-25: Trie-indexed SSTable format
> ---
>
> Key: CASSANDRA-18398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18398
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 37h
> Remaining Estimate: 0h
>
> Implementation of Big Trie-Indexed (BTI) SSTable format, per
> [CEP-25|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14319) nodetool rebuild from DC lets you pass invalid datacenters
[
https://issues.apache.org/jira/browse/CASSANDRA-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14319:
--
Status: In Progress (was: Patch Available)
> nodetool rebuild from DC lets you pass invalid datacenters
> ---
>
> Key: CASSANDRA-14319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14319
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: CASSANDRA-14319-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you pass an invalid datacenter to nodetool rebuild, you'll get an error
> like this:
> {code}
> Unable to find sufficient sources for streaming range
> (3074457345618258602,-9223372036854775808] in keyspace system_distributed
> {code}
> Unfortunately, this is a rabbit hole of frustration if you are using caps for
> your DC names and you pass in a lowercase DC name, or you just typo the DC.
> Let's do the following:
> # Check the DC name that's passed in against the list of DCs we know about
> # If we don't find it, let's output a reasonable error, and list all the DCs
> someone could put in.
> # Ideally we indicate which keyspaces are set to replicate to this DC and
> which aren't
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] branch trunk updated: Add support for JMX
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git
The following commit(s) were added to refs/heads/trunk by this push:
new acaabaf Add support for JMX
acaabaf is described below
commit acaabaf87928442c9d8a8741deac11b5a590f1d8
Author: Doug Rohrer
AuthorDate: Tue May 9 11:21:54 2023 -0400
Add support for JMX
Additionally, adds some code to help clean up the InstanceClassLoader
more efficiently and may be helpful for future features, even though it
is not necessary for this set of changes.
---
.../apache/cassandra/distributed/api/Feature.java | 2 +-
.../cassandra/distributed/api/IInstanceConfig.java | 2 +
.../distributed/shared/InstanceClassLoader.java| 61 +-
3 files changed, 63 insertions(+), 2 deletions(-)
diff --git a/src/main/java/org/apache/cassandra/distributed/api/Feature.java
b/src/main/java/org/apache/cassandra/distributed/api/Feature.java
index 6ba4a43..ad53355 100644
--- a/src/main/java/org/apache/cassandra/distributed/api/Feature.java
+++ b/src/main/java/org/apache/cassandra/distributed/api/Feature.java
@@ -20,5 +20,5 @@ package org.apache.cassandra.distributed.api;
public enum Feature
{
-NETWORK, GOSSIP, NATIVE_PROTOCOL, BLANK_GOSSIP
+NETWORK, GOSSIP, NATIVE_PROTOCOL, BLANK_GOSSIP, JMX
}
diff --git
a/src/main/java/org/apache/cassandra/distributed/api/IInstanceConfig.java
b/src/main/java/org/apache/cassandra/distributed/api/IInstanceConfig.java
index f88e761..36c741a 100644
--- a/src/main/java/org/apache/cassandra/distributed/api/IInstanceConfig.java
+++ b/src/main/java/org/apache/cassandra/distributed/api/IInstanceConfig.java
@@ -47,6 +47,8 @@ public interface IInstanceConfig
String localDatacenter();
+int jmxPort();
+
/**
* write the specified parameters to the Config object; we do not specify
Config as the type to support a Config
* from any ClassLoader; the implementation must not directly access any
fields of the Object, or cast it, but
diff --git
a/src/main/java/org/apache/cassandra/distributed/shared/InstanceClassLoader.java
b/src/main/java/org/apache/cassandra/distributed/shared/InstanceClassLoader.java
index 7420f5e..e41b6cc 100644
---
a/src/main/java/org/apache/cassandra/distributed/shared/InstanceClassLoader.java
+++
b/src/main/java/org/apache/cassandra/distributed/shared/InstanceClassLoader.java
@@ -22,6 +22,8 @@ import org.apache.cassandra.distributed.api.IClassTransformer;
import java.io.IOException;
import java.io.InputStream;
+import java.lang.reflect.Field;
+import java.lang.reflect.Method;
import java.net.JarURLConnection;
import java.net.URL;
import java.net.URLClassLoader;
@@ -29,7 +31,8 @@ import java.net.URLConnection;
import java.security.CodeSigner;
import java.security.CodeSource;
import java.util.Arrays;
-import java.util.function.BiFunction;
+import java.util.List;
+import java.util.Map;
import java.util.function.Predicate;
import java.util.jar.Manifest;
@@ -217,5 +220,61 @@ public class InstanceClassLoader extends URLClassLoader
{
isClosed = true;
super.close();
+try
+{
+// The JVM really wants to prevent Class instances from being GCed
until the
+// classloader which loaded them is GCed. It therefore maintains a
list
+// of Class instances for the sole purpose of providing a GC root
for them.
+// Here, we actually want the class instances to be GCed even if
this classloader
+// somehow gets stuck with a GC root, so we clear the class list
via reflection.
+// The current features implemented technically work without this,
but the Garbage
+// Collector works more efficiently with it here, and it may
provide value to new
+// feature developers.
+Field f = getField(ClassLoader.class, "classes");
+f.setAccessible(true);
+List> classes = (List>) f.get(this);
+classes.clear();
+// Same problem with packages - without clearing this,
+// the instance classloader can't unload
+f = getField(ClassLoader.class, "packages");
+f.setAccessible(true);
+Map packageMap = (Map) f.get(this);
+packageMap.clear();
+}
+catch (Throwable e)
+{
+throw new RuntimeException(e);
+}
+}
+
+public static Field getField(Class clazz, String fieldName) throws
NoSuchFieldException
+{
+// below code works before Java 12
+try
+{
+return clazz.getDeclaredField(fieldName);
+}
+catch (NoSuchFieldException e)
+{
+// this is mitigation for JDK 17
(https://bugs.openjdk.org/browse/JDK-8210522)
+try
+{
+Method
[jira] [Commented] (CASSANDRA-18507) Partial compaction can resurrect deleted data
[
https://issues.apache.org/jira/browse/CASSANDRA-18507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721848#comment-17721848
]
Marcus Eriksson commented on CASSANDRA-18507:
-
j8/j11 runs;
https://app.circleci.com/pipelines/github/krummas/cassandra?branch=CASSANDRA-18507-4.0
https://app.circleci.com/pipelines/github/krummas/cassandra?branch=CASSANDRA-18507-4.1
> Partial compaction can resurrect deleted data
> -
>
> Key: CASSANDRA-18507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18507
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Tobias Lindaaker
>Assignee: Tobias Lindaaker
>Priority: Normal
>
> If there isn't enough disk space available to compact all existing sstables,
> Cassandra will attempt to perform a partial compaction by removing sstables
> from the set of candidate sstables to be compacted, starting with the largest
> one. It is possible that the sstable removed from the set of sstables to
> compact contains data for which there are tombstones in another (more recent)
> sstable. Since the overlaps between sstables is computed when the
> {{CompactionController}} is created, and the {{CompactionController}} is
> created before the removal of any sstables from the set of sstables to be
> compacted this computed overlap will be outdated when checking which sstables
> are covered by certain tombstones. This leads to the faulty conclusion that
> the tombstones can be pruned during the compaction, causing the data to be
> resurrected.
> The issue is present in Cassandra 4.0 and 4.1. Cassandra 3.11 creates the
> {{CompactionController}} after the set of sstables to compact has been
> reduced, and is thus not affected. {{trunk}} does not appear to support
> partial compactions at all, but instead refuses to compact when the disk is
> full.
> This regression appears to have been introduced by CASSANDRA-13068.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721839#comment-17721839
]
Benjamin Lerer edited comment on CASSANDRA-17918 at 5/11/23 4:07 PM:
-
Sorry, I am late but adding my +1 for the record. Thanks [~smiklosovic]
was (Author: blerer):
Sorry, I am late but adding my +1 for the record.
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.10, 4.1.2, 5.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> SchemaElement.toCqlString}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721839#comment-17721839
]
Benjamin Lerer commented on CASSANDRA-17918:
Sorry, I am late but adding my +1 for the record.
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.10, 4.1.2, 5.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> SchemaElement.toCqlString}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16501) CMS is deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-16501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721837#comment-17721837
]
Ekaterina Dimitrova commented on CASSANDRA-16501:
-
Agreed, we still have to update build.xml though for the tests but I believe
that is CASSANDRA-18263
> CMS is deprecated
> -
>
> Key: CASSANDRA-16501
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16501
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Brandon Williams
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> When running under Java 11, you will see:
> {quote}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> {quote}
> Per the JEP: http://openjdk.java.net/jeps/291 " The G1 garbage collector is
> intended, in the long term, to be a replacement for most uses of CMS."
> We don't need to act on this immediately at the time of writing this ticket,
> but it is something that will eventually happen so we should get ahead of it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18263) Update gc settings in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-18263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18263: Epic Link: CASSANDRA-16895 > Update gc settings in build.xml > --- > > Key: CASSANDRA-18263 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18263 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > As part of CASSANDRA-18027 we switched trunk to default to G1GC. We need to > update also our test settings in build.xml to test with what we default to in > trunk > CC [~mck] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18436) Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally failing with JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18436:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova
Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Status: Review In Progress (was: Patch Available)
> Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally
> failing with JDK17
> -
>
> Key: CASSANDRA-18436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18436
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
>
>
> All of them failed with the below stack trace for the same assertion failing:
> {code:java}
> junit.framework.AssertionFailedError: at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:90) at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)
> at
> org.apache.cassandra.cql3.EmptyValuesTest.testEmptyDecimal(EmptyValuesTest.java:192)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
> Unfortunately I do not have a link to the CI run as this was seen last in
> private infra and not in CircleCI. Maybe we want to check with the
> multiplexer for flakiness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18436) Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally failing with JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18436:
Test and Documentation Plan:
||Branch||CI||
|[trunk|https://github.com/djatnieks/cassandra/tree/CASSANDRA-18436-trunk]|[java17|https://app.circleci.com/pipelines/github/djatnieks/cassandra/5/workflows/7678e370-43d6-4a94-a50b-ed30c72257f0]|
The test was also run in a loop
[here|https://app.circleci.com/pipelines/github/djatnieks/cassandra/6/workflows/31f3aa2f-4806-420e-83d1-22e2bebcc670/jobs/594/tests]
It seems there was an issue with CI setup before as the test does not fail
anymore. Suggested patch is just to add a few more assertions to improve the
test
was:
||Branch||CI||
|[trunk|https://github.com/djatnieks/cassandra/tree/CASSANDRA-18436-trunk]|[java17|https://app.circleci.com/pipelines/github/djatnieks/cassandra/5/workflows/7678e370-43d6-4a94-a50b-ed30c72257f0]|
> Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally
> failing with JDK17
> -
>
> Key: CASSANDRA-18436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18436
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
>
>
> All of them failed with the below stack trace for the same assertion failing:
> {code:java}
> junit.framework.AssertionFailedError: at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:90) at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)
> at
> org.apache.cassandra.cql3.EmptyValuesTest.testEmptyDecimal(EmptyValuesTest.java:192)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
> Unfortunately I do not have a link to the CI run as this was seen last in
> private infra and not in CircleCI. Maybe we want to check with the
> multiplexer for flakiness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18436) Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally failing with JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18436:
Test and Documentation Plan:
||Branch||CI||
|[trunk|https://github.com/djatnieks/cassandra/tree/CASSANDRA-18436-trunk]|[java17|https://app.circleci.com/pipelines/github/djatnieks/cassandra/5/workflows/7678e370-43d6-4a94-a50b-ed30c72257f0]|
Status: Patch Available (was: In Progress)
> Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally
> failing with JDK17
> -
>
> Key: CASSANDRA-18436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18436
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
>
>
> All of them failed with the below stack trace for the same assertion failing:
> {code:java}
> junit.framework.AssertionFailedError: at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:90) at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)
> at
> org.apache.cassandra.cql3.EmptyValuesTest.testEmptyDecimal(EmptyValuesTest.java:192)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
> Unfortunately I do not have a link to the CI run as this was seen last in
> private infra and not in CircleCI. Maybe we want to check with the
> multiplexer for flakiness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18436) Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally failing with JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721832#comment-17721832
]
Ekaterina Dimitrova commented on CASSANDRA-18436:
-
{quote}It looks like these pipeline builds timed out due to lack of resources
in the free tier...
{quote}
Unfortunately, yes, two of the containers exceeded context deadline.
But the good news are that
[here|https://app.circleci.com/pipelines/github/djatnieks/cassandra/6/workflows/31f3aa2f-4806-420e-83d1-22e2bebcc670/jobs/594/tests]
the other 2 containers, that finished the builds successfully, completed 3500
repetitions which seems to me to be fairly good amount of successful runs.
I suggest we close this ticket as an improvement, by just adding the assertions
[~djatnieks] suggested
[here|https://github.com/djatnieks/cassandra/commit/de637047e5c0601c40dfad8ab73e41e5b9b124d0]
but nothing to fix so far.
I suspect the failures we saw before were from times when we were still fixing
outstanding issues in the CI setup. Unfortunately, I do not have that setup
still available to check the logs but we can always reopen this ticket/open a
new one if something changes in the future. I am fairly confident we can close
this one.
[~mck], [~adelapena], [~Bereng] anyone of you up for a review?
> Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally
> failing with JDK17
> -
>
> Key: CASSANDRA-18436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18436
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
>
>
> All of them failed with the below stack trace for the same assertion failing:
> {code:java}
> junit.framework.AssertionFailedError: at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:90) at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)
> at
> org.apache.cassandra.cql3.EmptyValuesTest.testEmptyDecimal(EmptyValuesTest.java:192)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
> Unfortunately I do not have a link to the CI run as this was seen last in
> private infra and not in CircleCI. Maybe we want to check with the
> multiplexer for flakiness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18467) Update generate-idea-files for J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18467: Reviewers: Ekaterina Dimitrova, Michael Semb Wever Status: Review In Progress (was: Patch Available) > Update generate-idea-files for J17 > -- > > Key: CASSANDRA-18467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18467 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Jakub Zytka >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > There was a discussion in CASSANDRA-18258 how to update generate-idea-files. > The final agreement was to create one target to cover both Java 11 and Java > 17. > It will be good to figure out CASSANDRA-18263 and reshuffle arguments and > tasks based on what we decide to use as gc in testing for both Java 11 and > Java 17. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18467) Update generate-idea-files for J17
[
https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721827#comment-17721827
]
Ekaterina Dimitrova commented on CASSANDRA-18467:
-
{quote}I considered adding the removal to {{realclean}} but opted otherwise, as
I believe project configuration is more general/abstract than actually cleaning.
During testing we fixed (manually) a problem [~e.dimitrova] was seeing: jdk
"11" in intellij, although advertised as 11.0.2, was pointing to installation
with java 17. I haven't spent time on figuring out why that was and assumed
this is an environmental issue (as jdk installations is a global configuration
in intellij, not tied to the project)
{quote}
Agreed
{quote}A potential problem is that people may use different workflows with
intellij, which we haven't tested.
{quote}
I would like to suggest a quick note on the mailing list and so people can test
and give feedback before we commit it. [~jakubzytka] , do you mind to send an
email to @dev, please?
> Update generate-idea-files for J17
> --
>
> Key: CASSANDRA-18467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18467
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Jakub Zytka
>Priority: Low
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There was a discussion in CASSANDRA-18258 how to update generate-idea-files.
> The final agreement was to create one target to cover both Java 11 and Java
> 17.
> It will be good to figure out CASSANDRA-18263 and reshuffle arguments and
> tasks based on what we decide to use as gc in testing for both Java 11 and
> Java 17.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18507) Partial compaction can resurrect deleted data
[
https://issues.apache.org/jira/browse/CASSANDRA-18507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721821#comment-17721821
]
Ekaterina Dimitrova edited comment on CASSANDRA-18507 at 5/11/23 3:06 PM:
--
Hey everyone,
I also have a Mac available so decided to test on my end too. I can confirm
that I pulled [https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.1]
and [https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.0]. Then:
{code:java}
ant realclean
ant jar
{code}
ant test -Dtest.name=PartialCompactionsTest -Duse.jdk11=true
Everything finished successfully for me.
To be on the safe side I also tested with JDK 8. I ran this with both branches.
I tried on Mac Book pro from 2018, MAC OS 12.06
{code:java}
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
{code}
and
{code:java}
java version "1.8.0_231"
Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)
{code}
[~marcuse], can you push to run also the JDK 11 workflow In CI, please? I
noticed you started only JDK8 workflow.
{quote} I do think we will want this test for trunk just to make sure this
regression doesn't come back.
{quote}
That sounds like a great idea to me.
was (Author: e.dimitrova):
Hey everyone,
I also have a Mac available so decided to test on my end too. I can confirm
that I pulled [https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.1]
and [https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.0]. Then:
{code:java}
ant realclean
ant jar
{code}
ant test -Dtest.name=PartialCompactionsTest -Duse.jdk11=true
Everything finished successfully for me.
To be on the safe side I also tested with JDK 8. I ran this with both branches.
I tried on Mac Book pro from 2018, MAC OS 12.06
{code:java}
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
{code}
and
{code:java}
java version "1.8.0_231"
Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)
{code}
[~marcuse], can you push to run also the JDK 11 workflow In CI, please? I
noticed you started only JDK8 workflow.
{quote} I do think we will want this test for trunk just to make sure this
regression doesn't come back.
{quote}
That sounds like a great idea to me.
> Partial compaction can resurrect deleted data
> -
>
> Key: CASSANDRA-18507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18507
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Tobias Lindaaker
>Assignee: Tobias Lindaaker
>Priority: Normal
>
> If there isn't enough disk space available to compact all existing sstables,
> Cassandra will attempt to perform a partial compaction by removing sstables
> from the set of candidate sstables to be compacted, starting with the largest
> one. It is possible that the sstable removed from the set of sstables to
> compact contains data for which there are tombstones in another (more recent)
> sstable. Since the overlaps between sstables is computed when the
> {{CompactionController}} is created, and the {{CompactionController}} is
> created before the removal of any sstables from the set of sstables to be
> compacted this computed overlap will be outdated when checking which sstables
> are covered by certain tombstones. This leads to the faulty conclusion that
> the tombstones can be pruned during the compaction, causing the data to be
> resurrected.
> The issue is present in Cassandra 4.0 and 4.1. Cassandra 3.11 creates the
> {{CompactionController}} after the set of sstables to compact has been
> reduced, and is thus not affected. {{trunk}} does not appear to support
> partial compactions at all, but instead refuses to compact when the disk is
> full.
> This regression appears to have been introduced by CASSANDRA-13068.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18507) Partial compaction can resurrect deleted data
[
https://issues.apache.org/jira/browse/CASSANDRA-18507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721821#comment-17721821
]
Ekaterina Dimitrova commented on CASSANDRA-18507:
-
Hey everyone,
I also have a Mac available so decided to test on my end too. I can confirm
that I pulled [https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.1]
and [https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.0]. Then:
{code:java}
ant realclean
ant jar
{code}
ant test -Dtest.name=PartialCompactionsTest -Duse.jdk11=true
Everything finished successfully for me.
To be on the safe side I also tested with JDK 8. I ran this with both branches.
I tried on Mac Book pro from 2018, MAC OS 12.06
{code:java}
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
{code}
and
{code:java}
java version "1.8.0_231"
Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)
{code}
[~marcuse], can you push to run also the JDK 11 workflow In CI, please? I
noticed you started only JDK8 workflow.
{quote} I do think we will want this test for trunk just to make sure this
regression doesn't come back.
{quote}
That sounds like a great idea to me.
> Partial compaction can resurrect deleted data
> -
>
> Key: CASSANDRA-18507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18507
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Tobias Lindaaker
>Assignee: Tobias Lindaaker
>Priority: Normal
>
> If there isn't enough disk space available to compact all existing sstables,
> Cassandra will attempt to perform a partial compaction by removing sstables
> from the set of candidate sstables to be compacted, starting with the largest
> one. It is possible that the sstable removed from the set of sstables to
> compact contains data for which there are tombstones in another (more recent)
> sstable. Since the overlaps between sstables is computed when the
> {{CompactionController}} is created, and the {{CompactionController}} is
> created before the removal of any sstables from the set of sstables to be
> compacted this computed overlap will be outdated when checking which sstables
> are covered by certain tombstones. This leads to the faulty conclusion that
> the tombstones can be pruned during the compaction, causing the data to be
> resurrected.
> The issue is present in Cassandra 4.0 and 4.1. Cassandra 3.11 creates the
> {{CompactionController}} after the set of sstables to compact has been
> reduced, and is thus not affected. {{trunk}} does not appear to support
> partial compactions at all, but instead refuses to compact when the disk is
> full.
> This regression appears to have been introduced by CASSANDRA-13068.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14319) nodetool rebuild from DC lets you pass invalid datacenters
[
https://issues.apache.org/jira/browse/CASSANDRA-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720437#comment-17720437
]
Stefan Miklosovic edited comment on CASSANDRA-14319 at 5/11/23 2:58 PM:
trunk [https://github.com/apache/cassandra/pull/2309]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/c0b0e974-fdb1-4410-a180-fc8890c9a7e5]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/4fc8308c-3f07-4b41-9ad3-3a20a547c0e9]
4.1 [https://github.com/apache/cassandra/pull/2323]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2191/workflows/47f1d14c-e781-46d5-b68e-ff74a20fd8d1]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2191/workflows/e9dd84d7-5958-4297-949d-e7a2c0de31a6]
4.0 [https://github.com/apache/cassandra/pull/2324]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2192/workflows/ef27fb13-21b2-4e3d-8bea-52dfa5fe9ab1]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2192/workflows/707a5302-fda0-41b8-8c9e-710897022562]
3.11 [https://github.com/apache/cassandra/pull/2325]
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2193/workflows/126c4214-46f3-4dd0-8156-d2bf58f375e1
was (Author: smiklosovic):
trunk https://github.com/apache/cassandra/pull/2309
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/c0b0e974-fdb1-4410-a180-fc8890c9a7e5
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/4fc8308c-3f07-4b41-9ad3-3a20a547c0e9
4.1 https://github.com/apache/cassandra/pull/2323
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2191/workflows/47f1d14c-e781-46d5-b68e-ff74a20fd8d1
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2191/workflows/e9dd84d7-5958-4297-949d-e7a2c0de31a6
4.0 https://github.com/apache/cassandra/pull/2324
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2192/workflows/ef27fb13-21b2-4e3d-8bea-52dfa5fe9ab1
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2192/workflows/707a5302-fda0-41b8-8c9e-710897022562
> nodetool rebuild from DC lets you pass invalid datacenters
> ---
>
> Key: CASSANDRA-14319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14319
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: CASSANDRA-14319-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you pass an invalid datacenter to nodetool rebuild, you'll get an error
> like this:
> {code}
> Unable to find sufficient sources for streaming range
> (3074457345618258602,-9223372036854775808] in keyspace system_distributed
> {code}
> Unfortunately, this is a rabbit hole of frustration if you are using caps for
> your DC names and you pass in a lowercase DC name, or you just typo the DC.
> Let's do the following:
> # Check the DC name that's passed in against the list of DCs we know about
> # If we don't find it, let's output a reasonable error, and list all the DCs
> someone could put in.
> # Ideally we indicate which keyspaces are set to replicate to this DC and
> which aren't
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14319) nodetool rebuild from DC lets you pass invalid datacenters
[
https://issues.apache.org/jira/browse/CASSANDRA-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720437#comment-17720437
]
Stefan Miklosovic edited comment on CASSANDRA-14319 at 5/11/23 2:43 PM:
trunk https://github.com/apache/cassandra/pull/2309
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/c0b0e974-fdb1-4410-a180-fc8890c9a7e5
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/4fc8308c-3f07-4b41-9ad3-3a20a547c0e9
4.1 https://github.com/apache/cassandra/pull/2323
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2191/workflows/47f1d14c-e781-46d5-b68e-ff74a20fd8d1
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2191/workflows/e9dd84d7-5958-4297-949d-e7a2c0de31a6
4.0 https://github.com/apache/cassandra/pull/2324
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2192/workflows/ef27fb13-21b2-4e3d-8bea-52dfa5fe9ab1
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2192/workflows/707a5302-fda0-41b8-8c9e-710897022562
was (Author: smiklosovic):
trunk https://github.com/apache/cassandra/pull/2309
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/c0b0e974-fdb1-4410-a180-fc8890c9a7e5
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/4fc8308c-3f07-4b41-9ad3-3a20a547c0e9
> nodetool rebuild from DC lets you pass invalid datacenters
> ---
>
> Key: CASSANDRA-14319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14319
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: CASSANDRA-14319-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you pass an invalid datacenter to nodetool rebuild, you'll get an error
> like this:
> {code}
> Unable to find sufficient sources for streaming range
> (3074457345618258602,-9223372036854775808] in keyspace system_distributed
> {code}
> Unfortunately, this is a rabbit hole of frustration if you are using caps for
> your DC names and you pass in a lowercase DC name, or you just typo the DC.
> Let's do the following:
> # Check the DC name that's passed in against the list of DCs we know about
> # If we don't find it, let's output a reasonable error, and list all the DCs
> someone could put in.
> # Ideally we indicate which keyspaces are set to replicate to this DC and
> which aren't
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18507) Partial compaction can resurrect deleted data
[
https://issues.apache.org/jira/browse/CASSANDRA-18507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721799#comment-17721799
]
Marcus Eriksson edited comment on CASSANDRA-18507 at 5/11/23 2:22 PM:
--
+1 on the patch, very nice catch
pushed an alternative/additional test here:
https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.1
https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.0
but the existing test is fine as well I think (though we might have a general
problem running tests with java11 on macos?)
running cci:
https://app.circleci.com/pipelines/github/krummas/cassandra/868/workflows/0ab45cff-4d06-4f25-ba55-e19a8dcb1ad2
https://app.circleci.com/pipelines/github/krummas/cassandra/869/workflows/a7502533-0524-4669-b450-a8bd3897cb34
was (Author: krummas):
+1 on the patch, very nice catch
pushed an alternative/additional test here:
https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.1
https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.0
but the existing test is fine as well I think (though we might have a general
problem running tests with java11 on macos?)
running cci:
https://app.circleci.com/pipelines/github/krummas/cassandra/868/workflows/0ab45cff-4d06-4f25-ba55-e19a8dcb1ad2
https://app.circleci.com/pipelines/github/krummas/cassandra/867/workflows/bcb1a019-8576-46cb-8e97-b900c31e27ee
> Partial compaction can resurrect deleted data
> -
>
> Key: CASSANDRA-18507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18507
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Tobias Lindaaker
>Assignee: Tobias Lindaaker
>Priority: Normal
>
> If there isn't enough disk space available to compact all existing sstables,
> Cassandra will attempt to perform a partial compaction by removing sstables
> from the set of candidate sstables to be compacted, starting with the largest
> one. It is possible that the sstable removed from the set of sstables to
> compact contains data for which there are tombstones in another (more recent)
> sstable. Since the overlaps between sstables is computed when the
> {{CompactionController}} is created, and the {{CompactionController}} is
> created before the removal of any sstables from the set of sstables to be
> compacted this computed overlap will be outdated when checking which sstables
> are covered by certain tombstones. This leads to the faulty conclusion that
> the tombstones can be pruned during the compaction, causing the data to be
> resurrected.
> The issue is present in Cassandra 4.0 and 4.1. Cassandra 3.11 creates the
> {{CompactionController}} after the set of sstables to compact has been
> reduced, and is thus not affected. {{trunk}} does not appear to support
> partial compactions at all, but instead refuses to compact when the disk is
> full.
> This regression appears to have been introduced by CASSANDRA-13068.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12937:
--
Status: Review In Progress (was: Changes Suggested)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18507) Partial compaction can resurrect deleted data
[
https://issues.apache.org/jira/browse/CASSANDRA-18507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721799#comment-17721799
]
Marcus Eriksson commented on CASSANDRA-18507:
-
+1 on the patch, very nice catch
pushed an alternative/additional test here:
https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.1
https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.0
but the existing test is fine as well I think (though we might have a general
problem running tests with java11 on macos?)
running cci:
https://app.circleci.com/pipelines/github/krummas/cassandra/868/workflows/0ab45cff-4d06-4f25-ba55-e19a8dcb1ad2
https://app.circleci.com/pipelines/github/krummas/cassandra/867/workflows/bcb1a019-8576-46cb-8e97-b900c31e27ee
> Partial compaction can resurrect deleted data
> -
>
> Key: CASSANDRA-18507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18507
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Tobias Lindaaker
>Assignee: Tobias Lindaaker
>Priority: Normal
>
> If there isn't enough disk space available to compact all existing sstables,
> Cassandra will attempt to perform a partial compaction by removing sstables
> from the set of candidate sstables to be compacted, starting with the largest
> one. It is possible that the sstable removed from the set of sstables to
> compact contains data for which there are tombstones in another (more recent)
> sstable. Since the overlaps between sstables is computed when the
> {{CompactionController}} is created, and the {{CompactionController}} is
> created before the removal of any sstables from the set of sstables to be
> compacted this computed overlap will be outdated when checking which sstables
> are covered by certain tombstones. This leads to the faulty conclusion that
> the tombstones can be pruned during the compaction, causing the data to be
> resurrected.
> The issue is present in Cassandra 4.0 and 4.1. Cassandra 3.11 creates the
> {{CompactionController}} after the set of sstables to compact has been
> reduced, and is thus not affected. {{trunk}} does not appear to support
> partial compactions at all, but instead refuses to compact when the disk is
> full.
> This regression appears to have been introduced by CASSANDRA-13068.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17918:
--
Fix Version/s: 4.0.10
4.1.2
5.0
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
Since Version: 4.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/75194201f1f06d120f246f6fad025ca5f672943d
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.10, 4.1.2, 5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> SchemaElement.toCqlString}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (ae995eb3d3 -> 75194201f1)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from ae995eb3d3 NPE when deserializing malformed collections from client add 75194201f1 Fix quoting in toCqlString methods of UDTs and aggregates No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/cql3/functions/UDAggregate.java | 4 +- .../org/apache/cassandra/db/marshal/UserType.java | 2 +- .../cql3/statements/DescribeStatementTest.java | 130 + 4 files changed, 134 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (f650908648 -> 290bd0d337)
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 f650908648 Moved system properties and envs to CassandraRelevantProperties and CassandraRelevantEnv respectively add 75194201f1 Fix quoting in toCqlString methods of UDTs and aggregates add d7917a5144 Merge branch 'cassandra-4.0' into cassandra-4.1 new 290bd0d337 Merge branch 'cassandra-4.1' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../cassandra/cql3/functions/UDAggregate.java | 4 +- .../org/apache/cassandra/db/marshal/UserType.java | 2 +- .../cql3/statements/DescribeStatementTest.java | 130 + 4 files changed, 134 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository.
smiklosovic pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 290bd0d337dfc1d669344ec4b59098db79ef9b04
Merge: f650908648 d7917a5144
Author: Stefan Miklosovic
AuthorDate: Thu May 11 15:59:14 2023 +0200
Merge branch 'cassandra-4.1' into trunk
CHANGES.txt| 1 +
.../cassandra/cql3/functions/UDAggregate.java | 4 +-
.../org/apache/cassandra/db/marshal/UserType.java | 2 +-
.../cql3/statements/DescribeStatementTest.java | 130 +
4 files changed, 134 insertions(+), 3 deletions(-)
diff --cc CHANGES.txt
index abeb753658,52510028bf..e495dda4f2
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -143,6 -6,8 +143,7 @@@
* Fix COPY ... TO STDOUT behavior in cqlsh (CASSANDRA-18353)
* Remove six and Py2SaferScanner merge cruft (CASSANDRA-18354)
Merged from 4.0:
+ * Fix quoting in toCqlString methods of UDTs and aggregates (CASSANDRA-17918)
- * NPE when deserializing malformed collections from client (CASSANDRA-18505)
* Improve 'Not enough space for compaction' logging messages
(CASSANDRA-18260)
* Incremental repairs fail on mixed IPv4/v6 addresses serializing
SyncRequest (CASSANDRA-18474)
* Deadlock updating sstable metadata if disk boundaries need reloading
(CASSANDRA-18443)
diff --cc
test/unit/org/apache/cassandra/cql3/statements/DescribeStatementTest.java
index 6bf7008a69,52bb3c3d5e..422fcd4cdc
--- a/test/unit/org/apache/cassandra/cql3/statements/DescribeStatementTest.java
+++ b/test/unit/org/apache/cassandra/cql3/statements/DescribeStatementTest.java
@@@ -759,56 -789,104 +791,154 @@@ public class DescribeStatementTest exte
row(KEYSPACE_PER_TEST, "index", indexWithOptions,
expectedIndexStmtWithOptions));
}
+@Test
+public void testDescribeTableWithColumnMasks() throws Throwable
+{
+requireNetwork();
+DatabaseDescriptor.setDynamicDataMaskingEnabled(true);
+
+String table = createTable(KEYSPACE_PER_TEST,
+ "CREATE TABLE %s (" +
+ " pk1 text, " +
+ " pk2 int MASKED WITH DEFAULT, " +
+ " ck1 int, " +
+ " ck2 int MASKED WITH mask_default()," +
+ " s1 decimal static, " +
+ " s2 decimal static MASKED WITH
mask_null(), " +
+ " v1 text, " +
+ " v2 text MASKED WITH mask_inner(1,
null), " +
+ "PRIMARY KEY ((pk1, pk2), ck1, ck2 ))");
+
+TableMetadata tableMetadata =
Schema.instance.getTableMetadata(KEYSPACE_PER_TEST, table);
+assertNotNull(tableMetadata);
+
+String tableCreateStatement = "CREATE TABLE " + KEYSPACE_PER_TEST +
"." + table + " (\n" +
+ "pk1 text,\n" +
+ "pk2 int MASKED WITH
system.mask_default(),\n" +
+ "ck1 int,\n" +
+ "ck2 int MASKED WITH
system.mask_default(),\n" +
+ "s1 decimal static,\n" +
+ "s2 decimal static MASKED WITH
system.mask_null(),\n" +
+ "v1 text,\n" +
+ "v2 text MASKED WITH
system.mask_inner(1, null),\n" +
+ "PRIMARY KEY ((pk1, pk2), ck1,
ck2)\n" +
+ ") WITH ID = " + tableMetadata.id +
"\n" +
+ "AND CLUSTERING ORDER BY (ck1 ASC,
ck2 ASC)\n" +
+ "AND " + tableParametersCql();
+
+assertRowsNet(executeDescribeNet("DESCRIBE TABLE " +
KEYSPACE_PER_TEST + "." + table + " WITH INTERNALS"),
+ row(KEYSPACE_PER_TEST,
+ "table",
+ table,
+ tableCreateStatement));
+
+// masks should be listed even if DDM is disabled
+DatabaseDescriptor.setDynamicDataMaskingEnabled(false);
+assertRowsNet(executeDescribeNet("DESCRIBE TABLE " +
KEYSPACE_PER_TEST + "." + table + " WITH INTERNALS"),
+ row(KEYSPACE_PER_TEST,
+ "table",
+ table,
+ tableCreateStatement));
+}
+
+ @Test
+ public void testUsingReservedInCreateType() throws Throwable
+ {
+ String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
(\"token\" text, \"desc\" text);");
+
[cassandra] branch cassandra-4.1 updated (7f4e9bb67b -> d7917a5144)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 7f4e9bb67b Merge branch 'cassandra-4.0' into cassandra-4.1 add 75194201f1 Fix quoting in toCqlString methods of UDTs and aggregates add d7917a5144 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/cql3/functions/UDAggregate.java | 4 +- .../org/apache/cassandra/db/marshal/UserType.java | 2 +- .../cql3/statements/DescribeStatementTest.java | 130 + 4 files changed, 134 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17918:
--
Status: Ready to Commit (was: Review In Progress)
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> SchemaElement.toCqlString}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721769#comment-17721769
]
Anthony Grasso commented on CASSANDRA-18508:
The way I am thinking of fixing this issue is adding a new system property
called {{cassandra.jmx.remote.ssl.config.file}}. This property would specify a
path to a file containing only the {{javax.net.ssl.*}} properties.
> Sensitive JMX SSL configuration options can be easily exposed
> -
>
> Key: CASSANDRA-18508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Anthony Grasso
>Assignee: Anthony Grasso
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> We need a way to specify sensitive JMX SSL configuration options to avoid
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores
> must be specified using the {{javax.net.ssl.keyStorePassword}} and
> {{javax.net.ssl.trustStorePassword}} options respectively in the
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these
> security sensitive settings using the {{com.sun.management.config.file}}
> argument. However, despite what the documentation
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
> says, both the {{com.sun.management.jmxremote}} and
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the
> port numbers are different, attempting an encrypted JMX connection using
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a
> file to be passed containing the JMX encryption options.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (962cf11a -> b391473b)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 962cf11a generate docs for 8b85ed85 new b391473b generate docs for 8b85ed85 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (962cf11a) \ N -- N -- N refs/heads/asf-staging (b391473b) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../4.2/cassandra/tools/nodetool/bootstrap.html| 6 +- .../doc/4.2/cassandra/tools/nodetool/nodetool.html | 5 +- .../4.2/cassandra/tools/nodetool/repair_admin.html | 74 ++--- .../trunk/cassandra/tools/nodetool/bootstrap.html | 6 +- .../trunk/cassandra/tools/nodetool/nodetool.html | 5 +- .../cassandra/tools/nodetool/repair_admin.html | 74 ++--- content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4796900 -> 4796900 bytes 8 files changed, 81 insertions(+), 91 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18500) Add guardrail for partition size
[
https://issues.apache.org/jira/browse/CASSANDRA-18500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18500:
--
Change Category: Operability
Complexity: Low Hanging Fruit
Fix Version/s: 5.x
Status: Open (was: Triage Needed)
> Add guardrail for partition size
>
>
> Key: CASSANDRA-18500
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18500
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add a guardrail for max partition size, for example:
> {code:java}
> partition_size_warn_threshold: 50MiB
> partition_size_fail_threshold: 100MiB
> {code}
> Most probably this guardrail would only be checked when writing a new sstable
> to disk (fush/compact). Triggering the guardrail on sstable write would emit
> a log message and a diagnostic event, but it wouldn't reject the write.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18500) Add guardrail for partition size
[
https://issues.apache.org/jira/browse/CASSANDRA-18500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18500:
--
Test and Documentation Plan:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2321]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2890/workflows/3702a648-179c-4536-b004-bd8297c34a53]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2890/workflows/301bdae4-0683-40d1-8939-6a2d2ac0edcb]|
Status: Patch Available (was: Open)
> Add guardrail for partition size
>
>
> Key: CASSANDRA-18500
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18500
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add a guardrail for max partition size, for example:
> {code:java}
> partition_size_warn_threshold: 50MiB
> partition_size_fail_threshold: 100MiB
> {code}
> Most probably this guardrail would only be checked when writing a new sstable
> to disk (fush/compact). Triggering the guardrail on sstable write would emit
> a log message and a diagnostic event, but it wouldn't reject the write.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18500) Add guardrail for partition size
[
https://issues.apache.org/jira/browse/CASSANDRA-18500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721750#comment-17721750
]
Andres de la Peña commented on CASSANDRA-18500:
---
The proposed patch adds a new guardrail for partition size that is checked when
writing a sstable (flush, compaction, etc.):
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2321]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2890/workflows/3702a648-179c-4536-b004-bd8297c34a53]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2890/workflows/301bdae4-0683-40d1-8939-6a2d2ac0edcb]|
Triggering the failure threshold will emit an ERROR log message and a
diagnostic event, but it won't abort the sstable write operation.
This guardrail replaces the current
{{compaction_large_partition_warning_threshold}} property, which is now marked
as deprecated. Both checks will exist until we remove
{{compaction_large_partition_warning_threshold}} on the next major. The reason
for keeping both properties and not just renaming
{{compaction_large_partition_warning_threshold}} to
{{partition_size_warn_threshold}} is that the behaviour, log messages, etc. are
slightly different.
It's worth mentioning that the previously existing
{{compaction_large_partition_warning_threshold}}:
* Isn't actually triggered only on compaction, but on any sstable write.
* Cannot be dynamically updated.
* Doesn't emit any kind of diagnostic events.
The new guardrail uses standarized guardrail config, messages and JMX methods.
It can be dynamically updated and it emits diagnostic events on triggering.
> Add guardrail for partition size
>
>
> Key: CASSANDRA-18500
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18500
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add a guardrail for max partition size, for example:
> {code:java}
> partition_size_warn_threshold: 50MiB
> partition_size_fail_threshold: 100MiB
> {code}
> Most probably this guardrail would only be checked when writing a new sstable
> to disk (fush/compact). Triggering the guardrail on sstable write would emit
> a log message and a diagnostic event, but it wouldn't reject the write.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manish Ghildiyal reassigned CASSANDRA-18305:
Assignee: Manish Ghildiyal
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18504) Added support for type VECTOR
[ https://issues.apache.org/jira/browse/CASSANDRA-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18504: - Status: Review In Progress (was: Patch Available) > Added support for type VECTOR > -- > > Key: CASSANDRA-18504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18504 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema, CQL/Syntax >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > Time Spent: 2h > Remaining Estimate: 0h > > Based off several mailing list threads (see "[POLL] Vector type for ML”, > "[DISCUSS] New data type for vector search”, and "Adding vector search to SAI > with heirarchical navigable small world graph index”), its desirable to add a > new type “VECTOR” that has the following properties > 1) fixed length array > 2) elements may not be null > 3) flatten array (aka multi-cell = false) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18361) Test Failure: secondary_indexes_test.py::TestSecondaryIndexes::test_failing_manual_rebuild_index
[
https://issues.apache.org/jira/browse/CASSANDRA-18361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18361:
-
Complexity: Normal
Discovered By: DTest
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure:
> secondary_indexes_test.py::TestSecondaryIndexes::test_failing_manual_rebuild_index
>
>
> Key: CASSANDRA-18361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18361
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
>
> The Python dtest
> {{secondary_indexes_test.py::TestSecondaryIndexes::test_failing_manual_rebuild_index}}
> is flaky, at least for trunk:
> *
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/secondary_indexes_test/TestSecondaryIndexes/test_failing_manual_rebuild_index
> *
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1501/testReport/dtest.secondary_indexes_test/TestSecondaryIndexes/test_failing_manual_rebuild_index/
> {code}
> Error Message
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node1] 'ERROR [Reference-Reaper] 2023-03-23
> 00:23:43,597 Ref.java:237 - LEAK DETECTED: a reference (class
> org.apache.cassandra.io.util.FileHandle$Cleanup@967019010:/home/cassandra/cassandra/cassandra-dtest/tmp/dtest-hgjoy8rq/test/node1/data0/k/t-b7dae870c91011eda58f05bc40bfcaa1/nc-1-big-Index.db)
> to class
> org.apache.cassandra.io.util.FileHandle$Cleanup@967019010:/home/cassandra/cassandra/cassandra-dtest/tmp/dtest-hgjoy8rq/test/node1/data0/k/t-b7dae870c91011eda58f05bc40bfcaa1/nc-1-big-Index.db
> was not released before the reference was garbage collected']"
> Stacktrace
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Reference-Reaper] 2023-03-23 00:23:43,597 Ref.java:237 -
> LEAK DETECTED: a reference (class
> org.apache.cassandra.io.util.FileHandle$Cleanup@967019010:/home/cassandra/cassandra/cassandra-dtest/tmp/dtest-hgjoy8rq/test/node1/data0/k/t-b7dae870c91011eda58f05bc40bfcaa1/nc-1-big-Index.db)
> to class
> org.apache.cassandra.io.util.FileHandle$Cleanup@967019010:/home/cassandra/cassandra/cassandra-dtest/tmp/dtest-hgjoy8rq/test/node1/data0/k/t-b7dae870c91011eda58f05bc40bfcaa1/nc-1-big-Index.db
> was not released before the reference was garbage collected']
> {code}
> The failure can be reproduced in CircleCI:
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/2732/workflows/829434ab-2d1a-4e1c-8c7f-42449fcfda22
> The CircleCI config I used to reproduce the test failure can be generated
> with:
> {code}
> .circleci/generate.sh -p \
> -e REPEATED_DTESTS_COUNT=200 \
> -e
> REPEATED_DTESTS=secondary_indexes_test.py::TestSecondaryIndexes::test_failing_manual_rebuild_index
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18522) LEAK DETECTED: org.apache.cassandra.io.util.FileHandle$Cleanup in TestSecondaryIndexes.test_failing_manual_rebuild_index
[
https://issues.apache.org/jira/browse/CASSANDRA-18522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18522:
-
Resolution: Duplicate
Status: Resolved (was: Triage Needed)
> LEAK DETECTED: org.apache.cassandra.io.util.FileHandle$Cleanup in
> TestSecondaryIndexes.test_failing_manual_rebuild_index
>
>
> Key: CASSANDRA-18522
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18522
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jakub Zytka
>Priority: Normal
>
> A leak was detected in CI run:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2344/workflows/1f57b9a0-3fc9-49c7-a821-52e24b025056/jobs/22547/parallel-runs/4/steps/4-106{{{}
> ERRORS
> {}}}
> {{_ ERROR at teardown of
> TestSecondaryIndexes.test_failing_manual_rebuild_index __}}
> {{Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Reference-Reaper] 2023-05-05 17:57:29,429 Ref.java:237 -
> LEAK DETECTED: a reference (class
> org.apache.cassandra.io.util.FileHandle$Cleanup@1392096802:/tmp/dtest-nl3k0_2v/test/node1/data0/k/t-4374ee60eb6e11ed99961b44b0ab6f7e/nc-1-big-Index.db)
> to class
> org.apache.cassandra.io.util.FileHandle$Cleanup@1392096802:/tmp/dtest-nl3k0_2v/test/node1/data0/k/t-4374ee60eb6e11ed99961b44b0ab6f7e/nc-1-big-Index.db
> was not released before the reference was garbage collected', [node1] 'ERROR
> [Reference-Reaper] 2023-05-05 17:57:29,430 Ref.java:237 - LEAK DETECTED: a
> reference (class
> org.apache.cassandra.io.util.FileHandle$Cleanup@1379143890:/tmp/dtest-nl3k0_2v/test/node1/data1/k/t-4374ee60eb6e11ed99961b44b0ab6f7e/nc-2-big-Index.db)
> to class
> org.apache.cassandra.io.util.FileHandle$Cleanup@1379143890:/tmp/dtest-nl3k0_2v/test/node1/data1/k/t-4374ee60eb6e11ed99961b44b0ab6f7e/nc-2-big-Index.db
> was not released before the reference was garbage collected']}}
> {{==}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17797) All system properties and environment variables should be accessed via the new CassandraRelevantProperties and CassandraRelevantEnv classes
[
https://issues.apache.org/jira/browse/CASSANDRA-17797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721727#comment-17721727
]
Maxim Muzafarov commented on CASSANDRA-17797:
-
[~jlewandowski], [~smiklosovic]
Thanks so much for your help and review. As a follow-up, and with the intention
of not losing the key takeaways after the review, I can propose the
{{ConfigurationSource}} interface as an idea of how we can treat system
variables, environment variables and configuration parameters as a single set
of configuration parameters read from different sources.
Here is my post on the dev-list:
https://lists.apache.org/thread/gdtr3vp375d3nyj6h8xo7owth1s556lz
> All system properties and environment variables should be accessed via the
> new CassandraRelevantProperties and CassandraRelevantEnv classes
> ---
>
> Key: CASSANDRA-17797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17797
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Maxim Muzafarov
>Priority: Low
> Fix For: 5.0
>
> Time Spent: 33.5h
> Remaining Estimate: 0h
>
> Follow up ticket for CASSANDRA-15876 -
> "Always access system properties and environment variables via the new
> CassandraRelevantProperties and CassandraRelevantEnv classes"
> As part of that ticket we moved to the two new classes only
> properties/variables that were currently listed in System Properties Virtual
> Table.
> We have to move to those classes the rest of the properties around the code
> and start using those classes to access all of them.
> +Additional information for newcomers:+
> You might want to start by getting acquainted with
> CassandraRelevantProperties and CassandraRelevantEnv classes. Also, you might
> want to check what changes were done and how the first batch was transferred
> to this new framework as part of
> [CASSANDRA-15876|https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e]
> We are interested into the properties accessed currently through
> getProperties around the code.
> As part of CASSANDRA-15876 relevant unit tests were added
> (CassandraRelevantPropertiesTest). To verify the new patch we need to ensure
> that all tests Cassandra pass and also to think about potential update of the
> mentioned test class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Grasso updated CASSANDRA-18508:
---
Complexity: Normal (was: Low Hanging Fruit)
> Sensitive JMX SSL configuration options can be easily exposed
> -
>
> Key: CASSANDRA-18508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Anthony Grasso
>Assignee: Anthony Grasso
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> We need a way to specify sensitive JMX SSL configuration options to avoid
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores
> must be specified using the {{javax.net.ssl.keyStorePassword}} and
> {{javax.net.ssl.trustStorePassword}} options respectively in the
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these
> security sensitive settings using the {{com.sun.management.config.file}}
> argument. However, despite what the documentation
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
> says, both the {{com.sun.management.jmxremote}} and
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the
> port numbers are different, attempting an encrypted JMX connection using
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a
> file to be passed containing the JMX encryption options.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Grasso updated CASSANDRA-18508:
---
Summary: Sensitive JMX SSL configuration options can be easily exposed
(was: Allow JMX SSL configuration options to be passed via file)
> Sensitive JMX SSL configuration options can be easily exposed
> -
>
> Key: CASSANDRA-18508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Anthony Grasso
>Assignee: Anthony Grasso
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> We need a way to specify sensitive JMX SSL configuration options to avoid
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores
> must be specified using the {{javax.net.ssl.keyStorePassword}} and
> {{javax.net.ssl.trustStorePassword}} options respectively in the
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these
> security sensitive settings using the {{com.sun.management.config.file}}
> argument. However, despite what the documentation
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
> says, both the {{com.sun.management.jmxremote}} and
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the
> port numbers are different, attempting an encrypted JMX connection using
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a
> file to be passed containing the JMX encryption options.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18508) Allow JMX SSL configuration options to be passed via file
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Grasso updated CASSANDRA-18508:
---
Change Category: Operability
Complexity: Low Hanging Fruit
Fix Version/s: 4.0.x
4.1.x
5.0
Platform: (was: All)
Status: Open (was: Triage Needed)
> Allow JMX SSL configuration options to be passed via file
> -
>
> Key: CASSANDRA-18508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Anthony Grasso
>Assignee: Anthony Grasso
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> We need a way to specify sensitive JMX SSL configuration options to avoid
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores
> must be specified using the {{javax.net.ssl.keyStorePassword}} and
> {{javax.net.ssl.trustStorePassword}} options respectively in the
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these
> security sensitive settings using the {{com.sun.management.config.file}}
> argument. However, despite what the documentation
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
> says, both the {{com.sun.management.jmxremote}} and
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the
> port numbers are different, attempting an encrypted JMX connection using
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a
> file to be passed containing the JMX encryption options.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18522) LEAK DETECTED: org.apache.cassandra.io.util.FileHandle$Cleanup in TestSecondaryIndexes.test_failing_manual_rebuild_index
Jakub Zytka created CASSANDRA-18522:
---
Summary: LEAK DETECTED:
org.apache.cassandra.io.util.FileHandle$Cleanup in
TestSecondaryIndexes.test_failing_manual_rebuild_index
Key: CASSANDRA-18522
URL: https://issues.apache.org/jira/browse/CASSANDRA-18522
Project: Cassandra
Issue Type: Bug
Reporter: Jakub Zytka
A leak was detected in CI run:
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2344/workflows/1f57b9a0-3fc9-49c7-a821-52e24b025056/jobs/22547/parallel-runs/4/steps/4-106{{{}
ERRORS
{}}}
{{_ ERROR at teardown of TestSecondaryIndexes.test_failing_manual_rebuild_index
__}}
{{Unexpected error found in node logs (see stdout for full details). Errors:
[[node1] 'ERROR [Reference-Reaper] 2023-05-05 17:57:29,429 Ref.java:237 - LEAK
DETECTED: a reference (class
org.apache.cassandra.io.util.FileHandle$Cleanup@1392096802:/tmp/dtest-nl3k0_2v/test/node1/data0/k/t-4374ee60eb6e11ed99961b44b0ab6f7e/nc-1-big-Index.db)
to class
org.apache.cassandra.io.util.FileHandle$Cleanup@1392096802:/tmp/dtest-nl3k0_2v/test/node1/data0/k/t-4374ee60eb6e11ed99961b44b0ab6f7e/nc-1-big-Index.db
was not released before the reference was garbage collected', [node1] 'ERROR
[Reference-Reaper] 2023-05-05 17:57:29,430 Ref.java:237 - LEAK DETECTED: a
reference (class
org.apache.cassandra.io.util.FileHandle$Cleanup@1379143890:/tmp/dtest-nl3k0_2v/test/node1/data1/k/t-4374ee60eb6e11ed99961b44b0ab6f7e/nc-2-big-Index.db)
to class
org.apache.cassandra.io.util.FileHandle$Cleanup@1379143890:/tmp/dtest-nl3k0_2v/test/node1/data1/k/t-4374ee60eb6e11ed99961b44b0ab6f7e/nc-2-big-Index.db
was not released before the reference was garbage collected']}}
{{==}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18217) Allow CQL queries on multiple indexes without ALLOW FILTERING
[ https://issues.apache.org/jira/browse/CASSANDRA-18217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721715#comment-17721715 ] Andres de la Peña commented on CASSANDRA-18217: --- Thanks for the review. I have squashed the two commits. No rebase is needed. [~maedhroz] I think this is ready to be merged into the feature branch in your repo? > Allow CQL queries on multiple indexes without ALLOW FILTERING > - > > Key: CASSANDRA-18217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18217 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Andres de la Peña >Priority: Normal > Labels: SAI > > The Index Group index was added by > [CASSANDRA-16092|https://issues.apache.org/jira/browse/CASSANDRA-16092] to > allow indexes to be grouped and have more than one index expression in a > query. This did not make any changes to StatementRestrictions so CQL queries > using multiple index expression still need to add ALLOW FILTERING to the > query to be valid. > This restriction should be removed such that any number of index expressions > can be used on a CQL query without needing ALLOW FILTERING. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18521) Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
Andres de la Peña created CASSANDRA-18521:
-
Summary: Unify CQLTester#waitForIndex and
SAITester#waitForIndexQueryable
Key: CASSANDRA-18521
URL: https://issues.apache.org/jira/browse/CASSANDRA-18521
Project: Cassandra
Issue Type: Improvement
Components: Feature/SAI
Reporter: Andres de la Peña
Assignee: Andres de la Peña
It has been
[mentioned|https://github.com/maedhroz/cassandra/pull/11#discussion_r1190166765]
in CASSANDRA-18217 that {{CQLTester#waitForIndex}} and
{{SAITester#waitForIndexQueryable}} can be unified into a single method.
The same discussion mentions that it's easy to forget to call those methods
after calling {{CQLTester#createIndex}}. So that method can be renamed to
{{createIndexAsync}}, and we can create a new method that creates the index and
waits for it ({{createIndexSync}}, {{createIndexAndWaitForQueryable}}, or
something like that).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18467) Update generate-idea-files for J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakub Zytka updated CASSANDRA-18467: Test and Documentation Plan: Described in: https://issues.apache.org/jira/browse/CASSANDRA-18467?focusedCommentId=17720607=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17720607 Status: Patch Available (was: In Progress) > Update generate-idea-files for J17 > -- > > Key: CASSANDRA-18467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18467 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Jakub Zytka >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > There was a discussion in CASSANDRA-18258 how to update generate-idea-files. > The final agreement was to create one target to cover both Java 11 and Java > 17. > It will be good to figure out CASSANDRA-18263 and reshuffle arguments and > tasks based on what we decide to use as gc in testing for both Java 11 and > Java 17. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18490) Add checksum validation to all index components on startup, full rebuild and streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-18490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18490: - Change Category: Operability Complexity: Normal Assignee: Mike Adamson Status: Open (was: Triage Needed) > Add checksum validation to all index components on startup, full rebuild and > streaming > -- > > Key: CASSANDRA-18490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18490 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: NA > > > The SAI code currently does not checksum validate per-column index data files > at any point. It does checksum validate per-sstable components after a full > rebuild and it checksum validates the per-column metadata on opening. > We should checksum validate all index components on startup, full rebuild and > streaming. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18515) Optimize Initial Concurrency Selection for Range Read Algorithm During SAI Queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Adamson updated CASSANDRA-18515:
-
Test and Documentation Plan: The latest circle-ci test run is here:
https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/154/workflows/b22cf67c-1e71-4c93-bdc8-c2c1ab6c3773
Status: Patch Available (was: In Progress)
> Optimize Initial Concurrency Selection for Range Read Algorithm During SAI
> Queries
> --
>
> Key: CASSANDRA-18515
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18515
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Mike Adamson
>Assignee: Mike Adamson
>Priority: Normal
>
> The range read algorithm relies on the Index API’s notion of estimated result
> rows to decide how many replicas to contact in parallel during its first
> round of requests. The more results expected from a replica for a token
> range, the fewer replicas the range read will initially try to contact. Like
> SASI, SAI floors that estimate to a huge negative number to make sure it’s
> selected over other indexes, and this floors the concurrency factor to 1. The
> actual formula looks like this:
> {code:java}
> // resultsPerRange, from SAI, is a giant negative number
> concurrencyFactor = Math.max(1, Math.min(ranges.rangeCount(), (int)
> Math.ceil(command.limits().count() / resultsPerRange)));
> {code}
> Although that concurrency factor is updated as actual results stream in, only
> sending a single range request to a single replica in every case for SAI is
> not ideal. For example, assume I have a 3 node cluster and a keyspace at
> RF=1, with 10 rows spread across the 3 nodes, without vnodes. Issuing a query
> that matches all 10 rows with a LIMIT of 10 will make 2 or 3 serial range
> requests from the coordinator, one to each of the 3 nodes.
> This can be fixed by allowing indexes to bypass the initial concurrency
> calculation allowing SAI queries to contact the entire ring in a single round
> of queries, or at worst the minimum number of rounds as bounded by the
> existing statutory maximum ranges per round.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18515) Optimize Initial Concurrency Selection for Range Read Algorithm During SAI Queries
[
https://issues.apache.org/jira/browse/CASSANDRA-18515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Adamson updated CASSANDRA-18515:
-
Source Control Link: https://github.com/maedhroz/cassandra/pull/13
> Optimize Initial Concurrency Selection for Range Read Algorithm During SAI
> Queries
> --
>
> Key: CASSANDRA-18515
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18515
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Mike Adamson
>Assignee: Mike Adamson
>Priority: Normal
>
> The range read algorithm relies on the Index API’s notion of estimated result
> rows to decide how many replicas to contact in parallel during its first
> round of requests. The more results expected from a replica for a token
> range, the fewer replicas the range read will initially try to contact. Like
> SASI, SAI floors that estimate to a huge negative number to make sure it’s
> selected over other indexes, and this floors the concurrency factor to 1. The
> actual formula looks like this:
> {code:java}
> // resultsPerRange, from SAI, is a giant negative number
> concurrencyFactor = Math.max(1, Math.min(ranges.rangeCount(), (int)
> Math.ceil(command.limits().count() / resultsPerRange)));
> {code}
> Although that concurrency factor is updated as actual results stream in, only
> sending a single range request to a single replica in every case for SAI is
> not ideal. For example, assume I have a 3 node cluster and a keyspace at
> RF=1, with 10 rows spread across the 3 nodes, without vnodes. Issuing a query
> that matches all 10 rows with a LIMIT of 10 will make 2 or 3 serial range
> requests from the coordinator, one to each of the 3 nodes.
> This can be fixed by allowing indexes to bypass the initial concurrency
> calculation allowing SAI queries to contact the entire ring in a single round
> of queries, or at worst the minimum number of rounds as bounded by the
> existing statutory maximum ranges per round.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18346) Error Unknown column during deserialization missing keyspace and table name
[
https://issues.apache.org/jira/browse/CASSANDRA-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721638#comment-17721638
]
Manish Ghildiyal edited comment on CASSANDRA-18346 at 5/11/23 6:00 AM:
---
Created a tentative PR:
[https://github.com/apache/cassandra/pull/2319]]
was (Author: manish.c.ghildi...@gmail.com):
Created a tentative [PR|[https://github.com/apache/cassandra/pull/2319]]
> Error Unknown column during deserialization missing keyspace and table name
> ---
>
> Key: CASSANDRA-18346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18346
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Low
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The ERROR message generated in ColumnSubselection.java when a column name is
> not found only prints the column name, not the keyspace and table. It can be
> difficult to track down the source when more than one table uses the same
> name. E.g., 'id'.
> {quote}{{if (column == null)}}
> {
> {{ column = metadata.getDroppedColumn(name);}}
> {{ if (column == null)}}
> {{ throw new UnknownColumnException("Unknown column " +
> UTF8Type.instance.getString(name) + " during deserialization");}}
> {{}}}
> {quote}
> Example:
> [ERROR] cluster_id=15 ip_address=192.168.65.10 java.lang.RuntimeException:
> Unknown column id during deserialization
> Proposed:
> [ERROR] cluster_id=15 ip_address=192.168.65.10 java.lang.RuntimeException:
> Unknown column id in table cycling.route during deserialization
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18346) Error Unknown column during deserialization missing keyspace and table name
[
https://issues.apache.org/jira/browse/CASSANDRA-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721638#comment-17721638
]
Manish Ghildiyal edited comment on CASSANDRA-18346 at 5/11/23 6:00 AM:
---
Created a tentative [PR|[https://github.com/apache/cassandra/pull/2319]]
was (Author: manish.c.ghildi...@gmail.com):
Created a tentative [PR|[https://github.com/apache/cassandra/pull/2319].]
> Error Unknown column during deserialization missing keyspace and table name
> ---
>
> Key: CASSANDRA-18346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18346
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Low
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The ERROR message generated in ColumnSubselection.java when a column name is
> not found only prints the column name, not the keyspace and table. It can be
> difficult to track down the source when more than one table uses the same
> name. E.g., 'id'.
> {quote}{{if (column == null)}}
> {
> {{ column = metadata.getDroppedColumn(name);}}
> {{ if (column == null)}}
> {{ throw new UnknownColumnException("Unknown column " +
> UTF8Type.instance.getString(name) + " during deserialization");}}
> {{}}}
> {quote}
> Example:
> [ERROR] cluster_id=15 ip_address=192.168.65.10 java.lang.RuntimeException:
> Unknown column id during deserialization
> Proposed:
> [ERROR] cluster_id=15 ip_address=192.168.65.10 java.lang.RuntimeException:
> Unknown column id in table cycling.route during deserialization
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18346) Error Unknown column during deserialization missing keyspace and table name
[
https://issues.apache.org/jira/browse/CASSANDRA-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721638#comment-17721638
]
Manish Ghildiyal commented on CASSANDRA-18346:
--
Created a tentative [PR|[https://github.com/apache/cassandra/pull/2319].]
> Error Unknown column during deserialization missing keyspace and table name
> ---
>
> Key: CASSANDRA-18346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18346
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Low
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The ERROR message generated in ColumnSubselection.java when a column name is
> not found only prints the column name, not the keyspace and table. It can be
> difficult to track down the source when more than one table uses the same
> name. E.g., 'id'.
> {quote}{{if (column == null)}}
> {
> {{ column = metadata.getDroppedColumn(name);}}
> {{ if (column == null)}}
> {{ throw new UnknownColumnException("Unknown column " +
> UTF8Type.instance.getString(name) + " during deserialization");}}
> {{}}}
> {quote}
> Example:
> [ERROR] cluster_id=15 ip_address=192.168.65.10 java.lang.RuntimeException:
> Unknown column id during deserialization
> Proposed:
> [ERROR] cluster_id=15 ip_address=192.168.65.10 java.lang.RuntimeException:
> Unknown column id in table cycling.route during deserialization
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
