[cassandra-website] branch asf-staging updated (d6882a540 -> 0155f5f49)
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 d6882a540 generate docs for 52f24b20 new 0155f5f49 generate docs for 52f24b20 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (d6882a540) \ N -- N -- N refs/heads/asf-staging (0155f5f49) 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] [Comment Edited] (CASSANDRA-18398) CEP-25: Trie-indexed SSTable format
[ https://issues.apache.org/jira/browse/CASSANDRA-18398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718749#comment-17718749 ] David Capwell edited comment on CASSANDRA-18398 at 5/2/23 10:50 PM: bq. Let's make it a separate JIRA Works for me. In talking with Caleb it sounds like SAI will have similar issues, so it may be good to flesh out how to detect this for both, but primary index is more important than SAI so if w/e the solution is is localized to primary index; progress. was (Author: dcapwell): bq. Let's make it a separate JIRA Works for me > 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: 30h 50m > Remaining Estimate: 0h > > Implementation of Big Trie-Indexed (BTI) SSTable format, per > [CEP-25|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18398) CEP-25: Trie-indexed SSTable format
[ https://issues.apache.org/jira/browse/CASSANDRA-18398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718749#comment-17718749 ] David Capwell commented on CASSANDRA-18398: --- bq. Let's make it a separate JIRA Works for me > 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: 30h 50m > 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
[cassandra-website] branch asf-staging updated (d47693d7b -> d6882a540)
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 d47693d7b generate docs for 52f24b20 new d6882a540 generate docs for 52f24b20 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (d47693d7b) \ N -- N -- N refs/heads/asf-staging (d6882a540) 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 | 10 +-- .../4.2/cassandra/tools/nodetool/repair_admin.html | 89 ++--- .../trunk/cassandra/tools/nodetool/bootstrap.html | 6 +- .../trunk/cassandra/tools/nodetool/nodetool.html | 10 +-- .../cassandra/tools/nodetool/repair_admin.html | 89 ++--- site-ui/build/ui-bundle.zip| Bin 4796900 -> 4796900 bytes 7 files changed, 104 insertions(+), 106 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13981) Enable Cassandra for Persistent Memory
[ https://issues.apache.org/jira/browse/CASSANDRA-13981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-13981: - Resolution: Abandoned Status: Resolved (was: Open) Resolving as abandoned, though the work is there it will never be added. > Enable Cassandra for Persistent Memory > --- > > Key: CASSANDRA-13981 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13981 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core >Reporter: Preetika Tyagi >Assignee: Preetika Tyagi >Priority: Normal > Fix For: 5.x > > Attachments: in-mem-cassandra-1.0.patch, in-mem-cassandra-2.0.patch, > in-mem-cassandra-2.1.patch, readme.txt, readme2.1.txt, readme2_0.txt > > > Currently, Cassandra relies on disks for data storage and hence it needs data > serialization, compaction, bloom filters and partition summary/index for > speedy access of the data. However, with persistent memory, data can be > stored directly in the form of Java objects and collections, which can > greatly simplify the retrieval mechanism of the data. What we are proposing > is to make use of faster and scalable B+ tree-based data collections built > for persistent memory in Java (PCJ: https://github.com/pmem/pcj) and enable a > complete in-memory version of Cassandra, while still keeping the data > persistent. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13981) Enable Cassandra for Persistent Memory
[ https://issues.apache.org/jira/browse/CASSANDRA-13981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718713#comment-17718713 ] Jonathan Ellis commented on CASSANDRA-13981: I'm not aware of any mainstream persistent memory now that Optane is dead. > Enable Cassandra for Persistent Memory > --- > > Key: CASSANDRA-13981 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13981 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core >Reporter: Preetika Tyagi >Assignee: Preetika Tyagi >Priority: Normal > Fix For: 5.x > > Attachments: in-mem-cassandra-1.0.patch, in-mem-cassandra-2.0.patch, > in-mem-cassandra-2.1.patch, readme.txt, readme2.1.txt, readme2_0.txt > > > Currently, Cassandra relies on disks for data storage and hence it needs data > serialization, compaction, bloom filters and partition summary/index for > speedy access of the data. However, with persistent memory, data can be > stored directly in the form of Java objects and collections, which can > greatly simplify the retrieval mechanism of the data. What we are proposing > is to make use of faster and scalable B+ tree-based data collections built > for persistent memory in Java (PCJ: https://github.com/pmem/pcj) and enable a > complete in-memory version of Cassandra, while still keeping the data > persistent. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16855: -- Fix Version/s: 5.0 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/73da05f83ba2547662e6320cb2cb3576bf82c15f Resolution: Fixed Status: Resolved (was: Ready to Commit) > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Fix For: 5.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (22329ee0be -> 73da05f83b)
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 22329ee0be Deprecate/forbid constructors for Integer, Long, Float, Byte, Double, and Short add 73da05f83b Replace usages of json-simple dependency by Jackson No new revisions were added by this update. Summary of changes: .build/cassandra-deps-template.xml | 4 - .build/parent-pom-template.xml | 5 - CHANGES.txt| 1 + checkstyle.xml | 2 +- checkstyle_test.xml| 2 +- src/java/org/apache/cassandra/cql3/Json.java | 90 +++-- .../cassandra/cql3/functions/FromJsonFct.java | 4 +- .../apache/cassandra/cql3/selection/Selection.java | 3 +- .../org/apache/cassandra/db/ColumnFamilyStore.java | 10 +- .../db/commitlog/CommitLogDescriptor.java | 6 +- .../org/apache/cassandra/db/marshal/AsciiType.java | 4 +- .../org/apache/cassandra/db/marshal/ListType.java | 4 +- .../org/apache/cassandra/db/marshal/MapType.java | 6 +- .../org/apache/cassandra/db/marshal/SetType.java | 4 +- .../org/apache/cassandra/db/marshal/TupleType.java | 3 +- .../org/apache/cassandra/db/marshal/UTF8Type.java | 4 +- .../org/apache/cassandra/db/marshal/UserType.java | 7 +- .../apache/cassandra/hints/HintsDescriptor.java| 37 +++- .../cassandra/service/DataResurrectionCheck.java | 6 +- .../service/snapshot/SnapshotManifest.java | 6 +- src/java/org/apache/cassandra/tools/JMXTool.java | 8 +- .../tools/nodetool/stats/StatsPrinter.java | 26 +-- .../org/apache/cassandra/utils/FBUtilities.java| 65 --- src/java/org/apache/cassandra/utils/JsonUtils.java | 211 + .../cassandra/config/ConfigCompatabilityTest.java | 4 +- .../cql3/validation/entities/JsonTest.java | 10 +- .../apache/cassandra/db/SchemaCQLHelperTest.java | 11 +- .../cassandra/db/marshal/JsonConversionTest.java | 6 +- .../service/snapshot/SnapshotManifestTest.java | 7 +- .../tools/SSTableExportSchemaLoadingTest.java | 3 +- .../cassandra/tools/nodetool/TableStatsTest.java | 4 +- .../cassandra/tools/nodetool/TpStatsTest.java | 5 +- .../nodetool/stats/TableStatsPrinterTest.java | 61 +- .../org/apache/cassandra/stress/StressGraph.java | 61 +++--- 34 files changed, 439 insertions(+), 251 deletions(-) create mode 100644 src/java/org/apache/cassandra/utils/JsonUtils.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-8720) Provide tools for finding wide row/partition keys
[ https://issues.apache.org/jira/browse/CASSANDRA-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718699#comment-17718699 ] Stefan Miklosovic commented on CASSANDRA-8720: -- This is a great effort, thank you for doing this. I am looking into that table and I see that, for example for the partition 8, size is 356.067MiB and there is 932118 cells and 310706 rows but in the bottom table for "max" line, there are different figures. What is the source of this discrepancy? Thanks. > Provide tools for finding wide row/partition keys > - > > Key: CASSANDRA-8720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8720 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: J.B. Langston >Assignee: Andres de la Peña >Priority: Normal > Fix For: 5.x > > Attachments: 8720.txt > > > Multiple users have requested some sort of tool to help identify wide row > keys. They get into a situation where they know a wide row/partition has been > inserted and it's causing problems for them but they have no idea what the > row key is in order to remove it. > Maintaining the widest row key currently encountered and displaying it in > cfstats would be one possible approach. > Another would be an offline tool (possibly an enhancement to sstablekeys) to > show the number of columns/bytes per key in each sstable. If a tool to > aggregate the information at a CF-level could be provided that would be a > bonus, but it shouldn't be too hard to write a script wrapper to aggregate > them if not. -- 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-8720) Provide tools for finding wide row/partition keys
[ https://issues.apache.org/jira/browse/CASSANDRA-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-8720: Reviewers: Brandon Williams Status: Review In Progress (was: Patch Available) > Provide tools for finding wide row/partition keys > - > > Key: CASSANDRA-8720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8720 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: J.B. Langston >Assignee: Andres de la Peña >Priority: Normal > Fix For: 5.x > > Attachments: 8720.txt > > > Multiple users have requested some sort of tool to help identify wide row > keys. They get into a situation where they know a wide row/partition has been > inserted and it's causing problems for them but they have no idea what the > row key is in order to remove it. > Maintaining the widest row key currently encountered and displaying it in > cfstats would be one possible approach. > Another would be an offline tool (possibly an enhancement to sstablekeys) to > show the number of columns/bytes per key in each sstable. If a tool to > aggregate the information at a CF-level could be provided that would be a > bonus, but it shouldn't be too hard to write a script wrapper to aggregate > them if not. -- 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-18475) Formatting looks broken on the metrics page
[ https://issues.apache.org/jira/browse/CASSANDRA-18475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-18475: -- Component/s: Documentation (was: Documentation/Website) > Formatting looks broken on the metrics page > --- > > Key: CASSANDRA-18475 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18475 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Yury Vidineev >Assignee: Lorina Poland >Priority: Normal > > [https://cassandra.apache.org/doc/latest/cassandra/operating/metrics.html] > > Things like "[cols=",,",options="header",]" look odd, and I believe is a > part of some format setting (row HTML?) and isn't supposed to be displayed. > I'm willing to help if there is a place where I can send a merge request. -- 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-18475) Formatting looks broken on the metrics page
[ https://issues.apache.org/jira/browse/CASSANDRA-18475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland reassigned CASSANDRA-18475: - Assignee: Lorina Poland > Formatting looks broken on the metrics page > --- > > Key: CASSANDRA-18475 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18475 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Yury Vidineev >Assignee: Lorina Poland >Priority: Normal > > [https://cassandra.apache.org/doc/latest/cassandra/operating/metrics.html] > > Things like "[cols=",,",options="header",]" look odd, and I believe is a > part of some format setting (row HTML?) and isn't supposed to be displayed. > I'm willing to help if there is a place where I can send a merge request. -- 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-18494) Upgrade lucene-core library to the latest stable version
Mike Adamson created CASSANDRA-18494: Summary: Upgrade lucene-core library to the latest stable version Key: CASSANDRA-18494 URL: https://issues.apache.org/jira/browse/CASSANDRA-18494 Project: Cassandra Issue Type: Task Components: Feature/2i Index Reporter: Mike Adamson The lucene-core library is currently at 7.5. This should be updated to whatever the latest stable version of lucene is. -- 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-18493) Add LIKE prefix/suffix support
Mike Adamson created CASSANDRA-18493: Summary: Add LIKE prefix/suffix support Key: CASSANDRA-18493 URL: https://issues.apache.org/jira/browse/CASSANDRA-18493 Project: Cassandra Issue Type: Improvement Components: Feature/2i Index Reporter: Mike Adamson This should provide the following functionality: * LIKE abc% - prefix support * LIKE %bcd - suffix support * LIKE %bc% - prefix/suffix support -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18492) Allow full indexing on frozen collections
Mike Adamson created CASSANDRA-18492: Summary: Allow full indexing on frozen collections Key: CASSANDRA-18492 URL: https://issues.apache.org/jira/browse/CASSANDRA-18492 Project: Cassandra Issue Type: Improvement Components: Feature/2i Index Reporter: Mike Adamson SAI currently indexes frozen collections as blobs of the whole collection. It would be nice to index frozen collections such that they can be searched on elements in the collection like non-frozen collections. -- 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-18491) Investigate the sizing of BlockPackedReader and MonotonicBlockPackedReader
Mike Adamson created CASSANDRA-18491: Summary: Investigate the sizing of BlockPackedReader and MonotonicBlockPackedReader Key: CASSANDRA-18491 URL: https://issues.apache.org/jira/browse/CASSANDRA-18491 Project: Cassandra Issue Type: Task Components: Feature/2i Index Reporter: Mike Adamson BlockPackedWriter uses a block size of 128 bytes and MonotonicBlockPackedWriter uses a block size of 16384. There is no documentation about the reasons for choosing these particular sizes. We should add a micro benchmark to test these classes with different block sizes to show impact of changing them on read and write performance. -- 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-8720) Provide tools for finding wide row/partition keys
[ https://issues.apache.org/jira/browse/CASSANDRA-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-8720: - Fix Version/s: 5.x (was: 3.11.x) (was: 4.0.x) > Provide tools for finding wide row/partition keys > - > > Key: CASSANDRA-8720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8720 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: J.B. Langston >Assignee: Andres de la Peña >Priority: Normal > Fix For: 5.x > > Attachments: 8720.txt > > > Multiple users have requested some sort of tool to help identify wide row > keys. They get into a situation where they know a wide row/partition has been > inserted and it's causing problems for them but they have no idea what the > row key is in order to remove it. > Maintaining the widest row key currently encountered and displaying it in > cfstats would be one possible approach. > Another would be an offline tool (possibly an enhancement to sstablekeys) to > show the number of columns/bytes per key in each sstable. If a tool to > aggregate the information at a CF-level could be provided that would be a > bonus, but it shouldn't be too hard to write a script wrapper to aggregate > them if not. -- 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-8720) Provide tools for finding wide row/partition keys
[ https://issues.apache.org/jira/browse/CASSANDRA-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-8720: - Test and Documentation Plan: ||PR||CI|| |[trunk|https://github.com/apache/cassandra/pull/2303]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2877/workflows/e683e442-fa86-4fe5-af6c-6a57665b3a93] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2877/workflows/53f41727-77d8-494c-a2d1-ca4b1c71d4eb]| Status: Patch Available (was: In Progress) > Provide tools for finding wide row/partition keys > - > > Key: CASSANDRA-8720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8720 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: J.B. Langston >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: 8720.txt > > > Multiple users have requested some sort of tool to help identify wide row > keys. They get into a situation where they know a wide row/partition has been > inserted and it's causing problems for them but they have no idea what the > row key is in order to remove it. > Maintaining the widest row key currently encountered and displaying it in > cfstats would be one possible approach. > Another would be an offline tool (possibly an enhancement to sstablekeys) to > show the number of columns/bytes per key in each sstable. If a tool to > aggregate the information at a CF-level could be provided that would be a > bonus, but it shouldn't be too hard to write a script wrapper to aggregate > them if not. -- 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-8720) Provide tools for finding wide row/partition keys
[
https://issues.apache.org/jira/browse/CASSANDRA-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718664#comment-17718664
]
Andres de la Peña commented on CASSANDRA-8720:
--
Here is the {{sstablepartitions}} offline tool originally written by [~snazy]:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2303]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2877/workflows/e683e442-fa86-4fe5-af6c-6a57665b3a93]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2877/workflows/53f41727-77d8-494c-a2d1-ca4b1c71d4eb]|
I have adapted it to the current codebase, fixed a couple of bugs and added
tests for it.
It can be used for finding large partitions in sstables. For example, to find
partitions over 100MiB:
{code}
> sstablepartitions
> data/data/k/t-d7be5e90e90111ed8b54efe3c39cb0bb/nc-8-big-Data.db --min-size
> 100MiB
Processing k.t-d7be5e90e90111ed8b54efe3c39cb0bb #8 (big-nc) (1.368 GiB
uncompressed, 534.979 MiB on disk)
Partition: '13' (000d) live, size: 105.056 MiB, rows: 91490, cells:
274470, tombstones: 50 (row:50, range:0, complex:0, cell:0, row-TTLd:0,
cell-TTLd:0)
Partition: '1' (0001) live, size: 127.241 MiB, rows: 111065, cells:
333195, tombstones: 50 (row:50, range:0, complex:0, cell:0, row-TTLd:0,
cell-TTLd:0)
Partition: '8' (0008) live, size: 356.067 MiB, rows: 310706, cells:
932118, tombstones: 0 (row:0, range:0, complex:0, cell:0, row-TTLd:0,
cell-TTLd:0)
Partition: '2' (0002) live, size: 213.341 MiB, rows: 186582, cells:
559125, tombstones: 978 (row:978, range:0, complex:0, cell:0, row-TTLd:0,
cell-TTLd:0)
Summary of k.t-d7be5e90e90111ed8b54efe3c39cb0bb #8 (big-nc):
File:
/Users/adelapena/src/cassandra/trunk/data/data/k/t-d7be5e90e90111ed8b54efe3c39cb0bb/nc-8-big-Data.db
4 partitions match
Keys: 13 1 8 2
Partition sizeRow count Cell count
Tombstone count
p50767.519 KiB 770 1916
1
p75 2.238 MiB 2299 5722
1
p90 3.867 MiB 3311 9887
50
p95 16.629 MiB1423742510
446
p99148.267 MiB 126934 379022
1331
p999 368.936 MiB 315852 943127
2759
min 49.817 KiB 87 150
0
max368.936 MiB 315852 943127
2759
count 210
{code}
> Provide tools for finding wide row/partition keys
> -
>
> Key: CASSANDRA-8720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8720
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: J.B. Langston
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
> Attachments: 8720.txt
>
>
> Multiple users have requested some sort of tool to help identify wide row
> keys. They get into a situation where they know a wide row/partition has been
> inserted and it's causing problems for them but they have no idea what the
> row key is in order to remove it.
> Maintaining the widest row key currently encountered and displaying it in
> cfstats would be one possible approach.
> Another would be an offline tool (possibly an enhancement to sstablekeys) to
> show the number of columns/bytes per key in each sstable. If a tool to
> aggregate the information at a CF-level could be provided that would be a
> bonus, but it shouldn't be too hard to write a script wrapper to aggregate
> them if not.
--
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 ] Caleb Rackliffe updated CASSANDRA-18490: Fix Version/s: NA > 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 >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-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: - Description: 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. was: 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 and full rebuild. > 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 >Priority: Normal > > 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-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: - Summary: Add checksum validation to all index components on startup, full rebuild and streaming (was: Add checksum validation to all index components on startup and full rebuild) > 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 >Priority: Normal > > 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 and full rebuild. -- 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-18490) Add checksum validation to all index components on startup and full rebuild
Mike Adamson created CASSANDRA-18490: Summary: Add checksum validation to all index components on startup and full rebuild Key: CASSANDRA-18490 URL: https://issues.apache.org/jira/browse/CASSANDRA-18490 Project: Cassandra Issue Type: Improvement Components: Feature/2i Index Reporter: Mike Adamson 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 and full rebuild. -- 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-18489) CEP 15: Accord - Add a new Status of PreAcceptedInvalidated
David Capwell created CASSANDRA-18489: - Summary: CEP 15: Accord - Add a new Status of PreAcceptedInvalidated Key: CASSANDRA-18489 URL: https://issues.apache.org/jira/browse/CASSANDRA-18489 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: David Capwell If an invalidation is started and a replica does not know the transaction, then we get into a state of NotWitnessed(promised=[1, 2, 3, 4]). The issue with this is that all logic relies on Status checks, so they hit NotWitnessed and do not treat this as Invalidated; this confusion causes bugs in different code paths. -- 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-18489) CEP 15: Accord - Add a new Status of PreAcceptedInvalidated
[ https://issues.apache.org/jira/browse/CASSANDRA-18489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18489: -- Change Category: Code Clarity Complexity: Normal Fix Version/s: 5.x Status: Open (was: Triage Needed) > CEP 15: Accord - Add a new Status of PreAcceptedInvalidated > --- > > Key: CASSANDRA-18489 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18489 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Priority: Normal > Fix For: 5.x > > > If an invalidation is started and a replica does not know the transaction, > then we get into a state of NotWitnessed(promised=[1, 2, 3, 4]). The issue > with this is that all logic relies on Status checks, so they hit NotWitnessed > and do not treat this as Invalidated; this confusion causes bugs in different > code paths. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18398) CEP-25: Trie-indexed SSTable format
[ https://issues.apache.org/jira/browse/CASSANDRA-18398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718624#comment-17718624 ] Caleb Rackliffe commented on CASSANDRA-18398: - bq. Let's make it a separate JIRA; this can be done post 5.0. If it is a startup check (which may have the side effect of warming up the cache for indexes), the CRCs can be in a different file. If not, they need to be stored with the page to avoid costly additional page fetches. WFM [~dcapwell] has already done some test infrastructure around this in CASSANDRA-18485, although we still need the separate Jira I think to figure out exactly what kind of check we want an where. > 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: 27h 20m > Remaining Estimate: 0h > > Implementation of Big Trie-Indexed (BTI) SSTable format, per > [CEP-25|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16555) Add out-of-the-box snitch for Ec2 IMDSv2
[ https://issues.apache.org/jira/browse/CASSANDRA-16555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718593#comment-17718593 ] Brandon Williams commented on CASSANDRA-16555: -- [~jlewandowski] I think we should commit what we have here so we can get it into active branch releases and create a follow up ticket for any refactoring in trunk. > Add out-of-the-box snitch for Ec2 IMDSv2 > > > Key: CASSANDRA-16555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16555 > Project: Cassandra > Issue Type: New Feature > Components: Consistency/Coordination >Reporter: Paul Rütter (BlueConic) >Assignee: fulco taen >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > In order to patch a vulnerability, Amazon came up with a new version of their > metadata service. > It's no longer unrestricted but now requires a token (in a header), in order > to access the metadata service. > See > [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html] > for more information. > Cassandra currently doesn't offer an out-of-the-box snitch class to support > this. > See > [https://cassandra.apache.org/doc/latest/operating/snitch.html#snitch-classes] > This issue asks to add support for this as a separate snitch class. > We'll probably do a PR for this, as we are in the process of developing one. -- 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-16555) Add out-of-the-box snitch for Ec2 IMDSv2
[ https://issues.apache.org/jira/browse/CASSANDRA-16555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718590#comment-17718590 ] Thomas Steinmaurer commented on CASSANDRA-16555: As there was a "VOTE on 3.11.15" sent out today in dev mailing list, I guess this addition won't make it into 3.11.15. > Add out-of-the-box snitch for Ec2 IMDSv2 > > > Key: CASSANDRA-16555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16555 > Project: Cassandra > Issue Type: New Feature > Components: Consistency/Coordination >Reporter: Paul Rütter (BlueConic) >Assignee: fulco taen >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > In order to patch a vulnerability, Amazon came up with a new version of their > metadata service. > It's no longer unrestricted but now requires a token (in a header), in order > to access the metadata service. > See > [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html] > for more information. > Cassandra currently doesn't offer an out-of-the-box snitch class to support > this. > See > [https://cassandra.apache.org/doc/latest/operating/snitch.html#snitch-classes] > This issue asks to add support for this as a separate snitch class. > We'll probably do a PR for this, as we are in the process of developing one. -- 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-18449) Integer(int), Long(long), Float(double) were deprecated in JDK9
[ https://issues.apache.org/jira/browse/CASSANDRA-18449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18449: - Authors: Brandon Williams, Ekaterina Dimitrova (was: Brandon Williams) Fix Version/s: 5.0 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/22329ee0be7cba8807717ab18f845e1631fa4118 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thanks. > Integer(int), Long(long), Float(double) were deprecated in JDK9 > --- > > Key: CASSANDRA-18449 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18449 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0 > > > Now when we are moving with Cassandra 5.0 to 11+17, it is good to declutter > at least a bit our build log which contains 76 deprecation warnings. > Half of them are for deprecation of Integer(int), Long(long) and > Float(double). > Oracle advises to use factory methods which are likely to yield significantly > better space and time performance too. The factory methods are also marked > with > @IntrinsicCandidate > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Deprecate/forbid constructors for Integer, Long, Float, Byte, Double, and Short
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 22329ee0be Deprecate/forbid constructors for Integer, Long, Float,
Byte, Double, and Short
22329ee0be is described below
commit 22329ee0be7cba8807717ab18f845e1631fa4118
Author: Ekaterina Dimitrova
AuthorDate: Fri Sep 10 12:26:39 2021 -0400
Deprecate/forbid constructors for Integer, Long, Float, Byte, Double, and
Short
Patch by edimitrova and brandonwilliams; reviewed by bereng for
CASSANDRA-18449
---
checkstyle.xml | 43 ++
checkstyle_test.xml| 43 ++
.../cassandra/dht/ByteOrderedPartitioner.java | 4 +-
.../org/apache/cassandra/dht/LocalPartitioner.java | 2 +-
.../apache/cassandra/dht/Murmur3Partitioner.java | 2 +-
.../cassandra/dht/OrderPreservingPartitioner.java | 4 +-
.../apache/cassandra/dht/RandomPartitioner.java| 2 +-
.../org/apache/cassandra/utils/LongBTreeTest.java | 8 ++--
.../db/compaction/CompactionAllocationTest.java| 2 +-
.../test/microbench/btree/BTreeTransformBench.java | 2 +-
.../test/microbench/btree/BTreeUpdateBench.java| 2 +-
.../SizeTieredCompactionStrategyTest.java | 11 +++---
.../apache/cassandra/db/lifecycle/HelpersTest.java | 8 ++--
.../apache/cassandra/db/marshal/TimeTypeTest.java | 7 ++--
.../db/rows/ThrottledUnfilteredIteratorTest.java | 2 +-
.../apache/cassandra/dht/LengthPartitioner.java| 10 ++---
.../diag/store/DiagnosticEventMemoryStoreTest.java | 22 +--
.../apache/cassandra/utils/btree/BTreeTest.java| 2 +-
18 files changed, 132 insertions(+), 44 deletions(-)
diff --git a/checkstyle.xml b/checkstyle.xml
index 053cc735ab..f5eb4cf1f4 100644
--- a/checkstyle.xml
+++ b/checkstyle.xml
@@ -106,6 +106,49 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/checkstyle_test.xml b/checkstyle_test.xml
index d237827f44..a2f679e5a2 100644
--- a/checkstyle_test.xml
+++ b/checkstyle_test.xml
@@ -57,6 +57,49 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java
b/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java
index 2b0e2a2861..ae929c8c01 100644
--- a/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java
+++ b/src/java/org/apache/cassandra/dht/ByteOrderedPartitioner.java
@@ -301,7 +301,7 @@ public class ByteOrderedPartitioner implements IPartitioner
Token lastToken = sortedTokens.get(sortedTokens.size() - 1);
for (Token node : sortedTokens)
{
-allTokens.put(node, new Float(0.0));
+allTokens.put(node, 0.0F);
sortedRanges.add(new Range(lastToken, node));
lastToken = node;
}
@@ -319,7 +319,7 @@ public class ByteOrderedPartitioner implements IPartitioner
}
// Sum every count up and divide count/total for the fractional
ownership.
-Float total = new Float(0.0);
+Float total = 0.0F;
for (Float f : allTokens.values())
total += f;
for (Map.Entry row : allTokens.entrySet())
diff --git a/src/java/org/apache/cassandra/dht/LocalPartitioner.java
b/src/java/org/apache/cassandra/dht/LocalPartitioner.java
index 127c5b7ded..74a1264c8d 100644
--- a/src/java/org/apache/cassandra/dht/LocalPartitioner.java
+++ b/src/java/org/apache/cassandra/dht/LocalPartitioner.java
@@ -125,7 +125,7 @@ public class LocalPartitioner implements IPartitioner
public Map describeOwnership(List sortedTokens)
{
-return Collections.singletonMap((Token)getMinimumToken(), new
Float(1.0));
+return Collections.singletonMap((Token)getMinimumToken(), 1.0F);
}
public AbstractType getTokenValidator()
diff --git a/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java
b/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java
index 015610fb53..57993a69a6 100644
--- a/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java
+++ b/src/java/org/apache/cassandra/dht/Murmur3Partitioner.java
@@ -303,7 +303,7 @@ public class Murmur3Partitioner implements IPartitioner
throw new Runtim
[jira] [Commented] (CASSANDRA-18260) Add details to Error message: Not enough space for compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-18260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718549#comment-17718549
]
Brad Schoening commented on CASSANDRA-18260:
+1 on this patch
> Add details to Error message: Not enough space for compaction
> --
>
> Key: CASSANDRA-18260
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18260
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction, Observability/Logging
>Reporter: Brad Schoening
>Assignee: Henrik Ingo
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> When compaction fails, the log message should list a) the free space
> available on disk at that point in time and b) perhaps the number and/or size
> of the source sstables being compacted.
> Free space can change from one moment to the next, so when the below
> compaction failed because it needed 161GB, upon checking the server a few
> minutes later, it had 184GB free. Similarly, the error message mentions it
> was writing out one SSTable on this STCS table, but its not clear if it was
> combining X -> 1 tables, or something else.
> {noformat}
> [INFO ] [CompactionExecutor:77758] cluster_id=87 ip_address=127.1.1.1
> CompactionTask.java:241 - Compacted (8a1cffe0-abb5-11ed-b3fc-8d2ac2c52f0d) 1
> sstables to [...] to level=0. 86.997GiB to 86.997GiB (~99% of original) in
> 1,508,155ms. Read Throughput = 59.069MiB/s, Write Throughput = 59.069MiB/s,
> Row Throughput = ~20,283/s. 21,375 total partitions merged to 21,375.
> Partition merge counts were \{1:21375, }
> [ERROR] [CompactionExecutor:4] cluster_id=87 ip_address=127.1.1.1
> CassandraDaemon.java:581 - Exception in thread
> Thread[CompactionExecutor:4,1,main]
> java.lang.RuntimeException: Not enough space for compaction, estimated
> sstables = 1, expected write size = 161228934093
> at
> org.apache.cassandra.db.compaction.CompactionTask.buildCompactionCandidatesForAvailableDiskSpace(CompactionTask.java:386)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:126)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:77)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
> at
> org.apache.cassandra.db.compaction.CompactionManager$7.execute(CompactionManager.java:613)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:377)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18190) ECJ upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718320#comment-17718320
]
Ekaterina Dimitrova edited comment on CASSANDRA-18190 at 5/2/23 10:14 AM:
--
If I use source and target 1.8 to compile with ecj and Java 11, I reduce the
errors to only 327 (from 57 676). Most of them for:
{code:java}
Potential resource leak: '' may not be closed{code}
It seems that the moment we change source and target to 11 that change triggers
this issue to be caught - in the [Java Platform Module System
(JPMS)|https://en.wikipedia.org/wiki/Java_Platform_Module_System] it is not
allowed to use the same package in more than one module.
Many of the errors I was initially getting were "accessible from more than one
module" which is enforced by newer Java versions.
was (Author: e.dimitrova):
If I use source and target 1.8 to compile with ecj and Java 11, I reduce the
errors to only 327 (from 57 676). Most of them for:
{code:java}
Potential resource leak: '' may not be closed{code}
It seems that the moment we change source and target to 11 owe trigger this -
in the [Java Platform Module System
(JPMS)|https://en.wikipedia.org/wiki/Java_Platform_Module_System] it is not
allowed to use the same package in more than one module.
Many of the errors I was initially getting were "accessible from more than one
module" which is enforced by newer Java versions.
> ECJ upgrade
> ---
>
> Key: CASSANDRA-18190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18190
> Project: Cassandra
> Issue Type: Task
> Components: Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> During testing it was identified that we will need to update ECJ for the Java
> UDF functions in order to bring Java 17 in.
> It seems the compiler artifacts are moved from
> [here|https://mvnrepository.com/artifact/org.eclipse.jdt.core.compiler/ecj ]
> to [here|https://mvnrepository.com/artifact/org.eclipse.jdt/ecj] and there is
> change of license from EPL1.0 to EPL2.0 too. But if I read correctly
> [here|https://www.apache.org/legal/resolved.html#weak-copyleft-licenses] that
> should not affect us
> Further testing and review of all changes between artifacts to be done.
> ECJ is used for the eclipse-warnings and Java UDFs
--
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-18190) ECJ upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718213#comment-17718213
]
Ekaterina Dimitrova edited comment on CASSANDRA-18190 at 5/2/23 10:13 AM:
--
We were considering to compare and possibly substitute with Google ErrorProne.
According to the ErrorProne instruction
[here|https://errorprone.info/docs/installation], we would need these artifacts:
* {{error_prone_core-${EP_VERSION?}-with-dependencies.jar}}
from[https://repo1.maven.org/maven2/com/google/errorprone/error_prone_core/]
* {{dataflow-errorprone-${DATAFLOW_VERSION}.jar}}
from[https://repo1.maven.org/maven2/org/checkerframework/dataflow-errorprone/]
Unfortunately dataflow-errorprovne is GPL2 license so I think in this case we
are not allowed to use ErrorProne if I am reading correctly
[here|https://www.apache.org/licenses/GPL-compatibility.html]
According to the ECJ issues I was seeing, except asking about our setup, I did
not receive an advice at the eclipse forum. Though after experimenting and
reading more I think the syntax errors are probably only because of not
properly set compiler options/filtering properties. I will try to deal with that
was (Author: e.dimitrova):
We were considering to compare and possibly substitute with Google ErrorProne.
According to the ErrorProne instruction
[here|https://errorprone.info/docs/installation], we would need these artifacts:
* {{error_prone_core-${EP_VERSION?}-with-dependencies.jar}}
from[https://repo1.maven.org/maven2/com/google/errorprone/error_prone_core/]
* {{dataflow-errorprone-${DATAFLOW_VERSION}.jar}}
from[https://repo1.maven.org/maven2/org/checkerframework/dataflow-errorprone/]
Unfortunately dataflow-errorprovne is GPL2 license so I think in this case we
are not allowed to use ErrorProne if I am reading correctly
[here|https://www.apache.org/licenses/GPL-compatibility.html]
According to the ECJ issues I was seeing, except asking about our setup, I did
not receive an advice at the eclipse forum. Though after experimenting and
reading more I think the syntax errors are probably only because of not
properly set properties. I will try to deal with that
> ECJ upgrade
> ---
>
> Key: CASSANDRA-18190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18190
> Project: Cassandra
> Issue Type: Task
> Components: Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> During testing it was identified that we will need to update ECJ for the Java
> UDF functions in order to bring Java 17 in.
> It seems the compiler artifacts are moved from
> [here|https://mvnrepository.com/artifact/org.eclipse.jdt.core.compiler/ecj ]
> to [here|https://mvnrepository.com/artifact/org.eclipse.jdt/ecj] and there is
> change of license from EPL1.0 to EPL2.0 too. But if I read correctly
> [here|https://www.apache.org/legal/resolved.html#weak-copyleft-licenses] that
> should not affect us
> Further testing and review of all changes between artifacts to be done.
> ECJ is used for the eclipse-warnings and Java UDFs
--
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-18190) ECJ upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718213#comment-17718213
]
Ekaterina Dimitrova edited comment on CASSANDRA-18190 at 5/2/23 10:13 AM:
--
We were considering to compare and possibly substitute with Google ErrorProne.
According to the ErrorProne instruction
[here|https://errorprone.info/docs/installation], we would need these artifacts:
* {{error_prone_core-${EP_VERSION?}-with-dependencies.jar}}
from[https://repo1.maven.org/maven2/com/google/errorprone/error_prone_core/]
* {{dataflow-errorprone-${DATAFLOW_VERSION}.jar}}
from[https://repo1.maven.org/maven2/org/checkerframework/dataflow-errorprone/]
Unfortunately dataflow-errorprovne is GPL2 license so I think in this case we
are not allowed to use ErrorProne if I am reading correctly
[here|https://www.apache.org/licenses/GPL-compatibility.html]
According to the ECJ issues I was seeing, except asking about our setup, I did
not receive an advice at the eclipse forum. Though after experimenting and
reading more I think the syntax errors are probably only because of not
properly set properties. I will try to deal with that
was (Author: e.dimitrova):
We were considering to compare and possibly substitute with Google ErrorProne.
According to the ErrorProne instruction
[here|https://errorprone.info/docs/installation], we would need these artifacts:
* {{error_prone_core-${EP_VERSION?}-with-dependencies.jar}}
from[https://repo1.maven.org/maven2/com/google/errorprone/error_prone_core/]
* {{dataflow-errorprone-${DATAFLOW_VERSION}.jar}}
from[https://repo1.maven.org/maven2/org/checkerframework/dataflow-errorprone/]
Unfortunately dataflow-errorprovne is GPL2 license so I think in this case we
are not allowed to use ErrorProne if I am reading correctly
[here|https://www.apache.org/licenses/GPL-compatibility.html]
According to the ECJ issues I was seeing, except asking about our setup, I did
not receive an advice. Though after experimenting and reading more I think the
syntax errors are probably only because of not properly set properties. I will
try to deal with that
> ECJ upgrade
> ---
>
> Key: CASSANDRA-18190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18190
> Project: Cassandra
> Issue Type: Task
> Components: Feature/UDF
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> During testing it was identified that we will need to update ECJ for the Java
> UDF functions in order to bring Java 17 in.
> It seems the compiler artifacts are moved from
> [here|https://mvnrepository.com/artifact/org.eclipse.jdt.core.compiler/ecj ]
> to [here|https://mvnrepository.com/artifact/org.eclipse.jdt/ecj] and there is
> change of license from EPL1.0 to EPL2.0 too. But if I read correctly
> [here|https://www.apache.org/legal/resolved.html#weak-copyleft-licenses] that
> should not affect us
> Further testing and review of all changes between artifacts to be done.
> ECJ is used for the eclipse-warnings and Java UDFs
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18398) CEP-25: Trie-indexed SSTable format
[ https://issues.apache.org/jira/browse/CASSANDRA-18398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718487#comment-17718487 ] Branimir Lambov commented on CASSANDRA-18398: - bq. This is more venting than constructive feedback, but there are certainly parts of this patch that would be simpler without early open in play. Are there any active proposals to remove it for 5.0? At this point there is little hope to achieve what early open does without it. bq. RE checksumming on the partition/row index files, would a reasonable path forward for now be to spin off a separate Jira where we look into at least verifying integrity on startup (and streaming?), sort of like what we do w/ DIGEST? Let's make it a separate JIRA; this can be done post 5.0. If it is a startup check (which may have the side effect of warming up the cache for indexes), the CRCs can be in a different file. If not, they need to be stored with the page to avoid costly additional page fetches. > 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: 27h 10m > 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
