[jira] [Created] (CASSANDRA-18276) Paxos read throws TimeoutException instead of retrying when contending with writes when it could retry
Ariel Weisberg created CASSANDRA-18276: -- Summary: Paxos read throws TimeoutException instead of retrying when contending with writes when it could retry Key: CASSANDRA-18276 URL: https://issues.apache.org/jira/browse/CASSANDRA-18276 Project: Cassandra Issue Type: Bug Components: Feature/Lightweight Transactions Reporter: Ariel Weisberg Assignee: Ariel Weisberg [Paxos.read currently copies the code to throw timeout exception|https://github.com/apache/cassandra/blob/ece0c4a44c9209dc64240f3f33ca7a57d7548daa/src/java/org/apache/cassandra/service/paxos/Paxos.java#L873] if the read had side effects. This doesn’t make much sense because the empty proposal doesn’t have a side effect so it should be safe to retry the empty proposal instead of throwing timeout immediately. The impact of this is a little more severe because it’s also [not waiting during propose|https://github.com/apache/cassandra/blob/ece0c4a44c9209dc64240f3f33ca7a57d7548daa/src/java/org/apache/cassandra/service/paxos/PaxosPropose.java#L166] to see if there wouldn’t have been side effects for its empty proposal so it will always think there were side effects and timeout immediately if there are any refusals. Of course this only ever happens when it thinks the read might not be linearizable because it witnessed some in progress operation during the prrepare/promise phase. This should be pretty easy to fix either by removing the side effect immediate timeout code entirely, or at least improved by actually waiting for side effects during propose. -- 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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691781#comment-17691781 ] Brandon Williams commented on CASSANDRA-18106: -- With Ariel's [PR|https://github.com/riptano/ccm/pull/746] and then [this patch|https://github.com/driftx/ccm/commit/14f2434e94b39dd51032f88e90e054c1b89ff6e3] everything will pass on java 8 and 11, and 17 only fails because C* doesn't yet run. I had to remove the cleanup calls as those actually run nodetool cleanup, which doesn't make any sense in that context. I think we should be ready to commit this, and also Ariel's PR for CASSANDRA-17861. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- 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-18261) Update and unify copyright year
[
https://issues.apache.org/jira/browse/CASSANDRA-18261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691751#comment-17691751
]
Michael Semb Wever commented on CASSANDRA-18261:
FTR https://apache.org/legal/src-headers.html
(i'm still ok with the open range)
> Update and unify copyright year
> ---
>
> Key: CASSANDRA-18261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18261
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> Stefan suggested we update the year in various place for our copyright, and I
> noticed in build.xml we do this differently between branches. In 3.0 we use
> ${YEAR} and then in later branches we have hardcoded dates. This ticket
> serves to update these and unify how we specify them across branches.
--
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-16052) CEP-7 Storage Attached Indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-16052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16052: Labels: SAI (was: ) > CEP-7 Storage Attached Indexes > -- > > Key: CASSANDRA-16052 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16052 > Project: Cassandra > Issue Type: Epic > Components: Feature/2i Index >Reporter: Zhao Yang >Assignee: Caleb Rackliffe >Priority: Normal > Labels: SAI > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > [CEP|https://docs.google.com/document/d/1V830eAMmQAspjJdjviVZIaSolVGvZ1hVsqOLWyV0DS4/edit#heading=h.67ap6rr1mxr] > - 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] [Updated] (CASSANDRA-16052) CEP-7 Storage Attached Indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-16052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16052: Component/s: Feature/SAI > CEP-7 Storage Attached Indexes > -- > > 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: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > [CEP|https://docs.google.com/document/d/1V830eAMmQAspjJdjviVZIaSolVGvZ1hVsqOLWyV0DS4/edit#heading=h.67ap6rr1mxr] > - 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-18261) Update and unify copyright year
[
https://issues.apache.org/jira/browse/CASSANDRA-18261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691722#comment-17691722
]
Brandon Williams commented on CASSANDRA-18261:
--
That makes sense, updated.
> Update and unify copyright year
> ---
>
> Key: CASSANDRA-18261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18261
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> Stefan suggested we update the year in various place for our copyright, and I
> noticed in build.xml we do this differently between branches. In 3.0 we use
> ${YEAR} and then in later branches we have hardcoded dates. This ticket
> serves to update these and unify how we specify them across branches.
--
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-18261) Update and unify copyright year
[
https://issues.apache.org/jira/browse/CASSANDRA-18261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691717#comment-17691717
]
Michael Semb Wever commented on CASSANDRA-18261:
I think you still want the dash, to indicate an open range
> Update and unify copyright year
> ---
>
> Key: CASSANDRA-18261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18261
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> Stefan suggested we update the year in various place for our copyright, and I
> noticed in build.xml we do this differently between branches. In 3.0 we use
> ${YEAR} and then in later branches we have hardcoded dates. This ticket
> serves to update these and unify how we specify them across branches.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18067) On-disk numeric index
[ https://issues.apache.org/jira/browse/CASSANDRA-18067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Fleming updated CASSANDRA-18067: - Fix Version/s: NA (was: 4.x) > 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 > 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] [Updated] (CASSANDRA-18062) On-disk string index with index building and on-disk query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Fleming updated CASSANDRA-18062: - Fix Version/s: (was: 4.x) > On-disk string index with index building and on-disk query path > --- > > Key: CASSANDRA-18062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18062 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > > An on-disk index for string (literal) datatypes. This index is used for the > following datatypes: > * UTF8Type > * AsciiType > * CompositeType > * Frozen types > This includes the ability to write the index to disk at index creation, by > specific index rebuild and during SSTable compaction. > Also the ability to query the on-disk index and combine the results with > those from the in-memory indexes created by CASSANDRA-18058. -- 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-18062) On-disk string index with index building and on-disk query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Fleming updated CASSANDRA-18062: - Fix Version/s: NA > On-disk string index with index building and on-disk query path > --- > > Key: CASSANDRA-18062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18062 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: NA > > > An on-disk index for string (literal) datatypes. This index is used for the > following datatypes: > * UTF8Type > * AsciiType > * CompositeType > * Frozen types > This includes the ability to write the index to disk at index creation, by > specific index rebuild and during SSTable compaction. > Also the ability to query the on-disk index and combine the results with > those from the in-memory indexes created by CASSANDRA-18058. -- 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-18062) On-disk string index with index building and on-disk query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691712#comment-17691712 ] Matt Fleming commented on CASSANDRA-18062: -- [~maedhroz] Sure can do. I was just monkeying about with the versions to create a simpler kanban board, but I'm happy to use NA here. > On-disk string index with index building and on-disk query path > --- > > Key: CASSANDRA-18062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18062 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 4.x > > > An on-disk index for string (literal) datatypes. This index is used for the > following datatypes: > * UTF8Type > * AsciiType > * CompositeType > * Frozen types > This includes the ability to write the index to disk at index creation, by > specific index rebuild and during SSTable compaction. > Also the ability to query the on-disk index and combine the results with > those from the in-memory indexes created by CASSANDRA-18058. -- 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 (36e45665 -> b6eb5544)
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 36e45665 generate docs for 8545a889 new b6eb5544 generate docs for 8545a889 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 (36e45665) \ N -- N -- N refs/heads/asf-staging (b6eb5544) 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 4796442 -> 4796442 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] [Updated] (CASSANDRA-18261) Update and unify copyright year
[
https://issues.apache.org/jira/browse/CASSANDRA-18261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18261:
-
Change Category: Semantic
Complexity: Low Hanging Fruit
Component/s: Build
Fix Version/s: 3.0.x
3.11.x
4.0.x
4.1.x
4.x
Status: Open (was: Triage Needed)
> Update and unify copyright year
> ---
>
> Key: CASSANDRA-18261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18261
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> Stefan suggested we update the year in various place for our copyright, and I
> noticed in build.xml we do this differently between branches. In 3.0 we use
> ${YEAR} and then in later branches we have hardcoded dates. This ticket
> serves to update these and unify how we specify them across branches.
--
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-18261) Update and unify copyright year
[
https://issues.apache.org/jira/browse/CASSANDRA-18261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691669#comment-17691669
]
Brandon Williams commented on CASSANDRA-18261:
--
Maybe we should just remove the end date?
[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18261-3.0],
[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18261-3.11],
[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18261-4.0],
[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18261-4.1],
[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18261-trunk]
> Update and unify copyright year
> ---
>
> Key: CASSANDRA-18261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18261
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Brandon Williams
>Priority: Normal
>
> Stefan suggested we update the year in various place for our copyright, and I
> noticed in build.xml we do this differently between branches. In 3.0 we use
> ${YEAR} and then in later branches we have hardcoded dates. This ticket
> serves to update these and unify how we specify them across branches.
--
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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691661#comment-17691661 ] Brandon Williams commented on CASSANDRA-18106: -- Stripping the '1.8' version down did the trick [here|https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/1dedc810-9884-42d5-9d2c-eb911dcd4495]. bq. Also, trivial, but can we remove the JAVAx_HOME lines (in just trunk): That's in the templates too, we should probably make another ticket to cleanup circle. I believe you found the root cause of CASSANDRA-18039 though. bq. CCM has its own tests and JDK tests also exist Let me take a look. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- 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-18062) On-disk string index with index building and on-disk query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691655#comment-17691655 ] Caleb Rackliffe commented on CASSANDRA-18062: - [~mfleming] Just to be clear, this is almost certainly not going to land in any 4.x release, and if [~mike_tr_adamson] is okay w/ it, I’d suggest we just use the NA version here and later inherit the main CEP-7 version when that’s finalized. > On-disk string index with index building and on-disk query path > --- > > Key: CASSANDRA-18062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18062 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 4.x > > > An on-disk index for string (literal) datatypes. This index is used for the > following datatypes: > * UTF8Type > * AsciiType > * CompositeType > * Frozen types > This includes the ability to write the index to disk at index creation, by > specific index rebuild and during SSTable compaction. > Also the ability to query the on-disk index and combine the results with > those from the in-memory indexes created by CASSANDRA-18058. -- 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-18062) On-disk string index with index building and on-disk query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691655#comment-17691655 ] Caleb Rackliffe edited comment on CASSANDRA-18062 at 2/21/23 2:58 PM: -- [~mfleming] Just to be clear, this is almost certainly not going to land in any 4.x release, and if [~mike_tr_adamson] is okay w/ it, I’d suggest we just use the NA version here and later inherit the main CEP-7 version when that’s finalized in the epic Jira/ticket. was (Author: maedhroz): [~mfleming] Just to be clear, this is almost certainly not going to land in any 4.x release, and if [~mike_tr_adamson] is okay w/ it, I’d suggest we just use the NA version here and later inherit the main CEP-7 version when that’s finalized. > On-disk string index with index building and on-disk query path > --- > > Key: CASSANDRA-18062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18062 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 4.x > > > An on-disk index for string (literal) datatypes. This index is used for the > following datatypes: > * UTF8Type > * AsciiType > * CompositeType > * Frozen types > This includes the ability to write the index to disk at index creation, by > specific index rebuild and during SSTable compaction. > Also the ability to query the on-disk index and combine the results with > those from the in-memory indexes created by CASSANDRA-18058. -- 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-18258) Add test conf for JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691630#comment-17691630
]
Ekaterina Dimitrova edited comment on CASSANDRA-18258 at 2/21/23 2:28 PM:
--
{quote}Good question. This code looks only to flip the language level from one
jdk to the other.
{quote}
No, actually what [~bdeggleston] said:
{quote}That was added because the java 11 needed --add-exports etc, and those
weren't compatible with java 8.
{quote}
And while the --add-exports to compile will be the same for 11 and 17 and
someone could probably argue we can just update the
__maybe_update_idea_to_java11__ to cover 11+17, we also add different jvmargs
in java11-jvmargs and java17-jvmargs. It is similar to us having the separate
jvm11-server.options/jvm17-server.options.
{quote}Agree it would be best if we didn't need separate profile
{quote}
Agreed, we will probably need to have again a community discussion soon after I
commit this ticket In regards to all our JDK internals accesses - Java and
Cassandra future. More to follow.
was (Author: e.dimitrova):
{quote}Good question. This code looks only to flip the language level from one
jdk to the other.
{quote}
No, actually what [~bdeggleston] said:
{quote}That was added because the java 11 needed --add-exports etc, and those
weren't compatible with java 8.
{quote}
And while the --add-exports to compile will be the same for 11 and 17 and
someone could probably argue we can just update the
_{_}maybe_update_idea_to_java11{_} to cover 11+17, we also add different
jvmargs in java11-jvmargs and java17-jvmargs. It is similar to us having the
separate jvm11-server.options/jvm17-server.options.
{quote}Agree it would be best if we didn't need separate profile
{quote}
Agreed, we will probably need to have again a community discussion soon after I
commit this ticket In regards to all our JDK internals accesses - Java and
Cassandra future. More to follow.
> Add test conf for JDK17
> ---
>
> Key: CASSANDRA-18258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18258
> Project: Cassandra
> Issue Type: Task
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> Post CASSANDRA-18252 and CASSANDRA-18179 we will be able to compile current
> trunk with JDK17 but in order to start Cassandra and test it we will need
> also our conf files updated with some preliminary conf for test purposes.
> This ticket will be used to add those to current trunk
--
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-18258) Add test conf for JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691630#comment-17691630
]
Ekaterina Dimitrova commented on CASSANDRA-18258:
-
{quote}Good question. This code looks only to flip the language level from one
jdk to the other.
{quote}
No, actually what [~bdeggleston] said:
{quote}That was added because the java 11 needed --add-exports etc, and those
weren't compatible with java 8.
{quote}
And while the --add-exports to compile will be the same for 11 and 17 and
someone could probably argue we can just update the
_{_}maybe_update_idea_to_java11{_} to cover 11+17, we also add different
jvmargs in java11-jvmargs and java17-jvmargs. It is similar to us having the
separate jvm11-server.options/jvm17-server.options.
{quote}Agree it would be best if we didn't need separate profile
{quote}
Agreed, we will probably need to have again a community discussion soon after I
commit this ticket In regards to all our JDK internals accesses - Java and
Cassandra future. More to follow.
> Add test conf for JDK17
> ---
>
> Key: CASSANDRA-18258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18258
> Project: Cassandra
> Issue Type: Task
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> Post CASSANDRA-18252 and CASSANDRA-18179 we will be able to compile current
> trunk with JDK17 but in order to start Cassandra and test it we will need
> also our conf files updated with some preliminary conf for test purposes.
> This ticket will be used to add those to current trunk
--
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-14227) Extend maximum expiration date
[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691608#comment-17691608
]
Benedict Elliott Smith commented on CASSANDRA-14227:
This is the canonical example that was given in the original thread more than a
year ago, i.e. that a cluster should not write files that are incompatible with
the version we are upgrading from until the operator agrees the upgrade has
been successful, yes. If there are performance or other regressions encountered
during an upgrade, recovery should be as simple as restarting with the prior
version (until the operator decides the new version is performing adequately).
This minimises risks, without fully eliminating them.
> Extend maximum expiration date
> --
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Paulo Motta (Deprecated)
>Assignee: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.x
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png, unnamed-1.png
>
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
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-14227) Extend maximum expiration date
[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691603#comment-17691603
]
Benjamin Lerer commented on CASSANDRA-14227:
I think, that I am misunderstanding what we call downgradability. What you
propose is some kind of feature flag that delay the problem, no? If a problem
occurs once we switch to the new sstable format then we cannot downgrade
anymore.
> Extend maximum expiration date
> --
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Paulo Motta (Deprecated)
>Assignee: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.x
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png, unnamed-1.png
>
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18067) On-disk numeric index
[ https://issues.apache.org/jira/browse/CASSANDRA-18067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Fleming updated CASSANDRA-18067: - Fix Version/s: 4.x > 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 > Fix For: 4.x > > > 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] [Updated] (CASSANDRA-18062) On-disk string index with index building and on-disk query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Fleming updated CASSANDRA-18062: - Fix Version/s: 4.x > On-disk string index with index building and on-disk query path > --- > > Key: CASSANDRA-18062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18062 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 4.x > > > An on-disk index for string (literal) datatypes. This index is used for the > following datatypes: > * UTF8Type > * AsciiType > * CompositeType > * Frozen types > This includes the ability to write the index to disk at index creation, by > specific index rebuild and during SSTable compaction. > Also the ability to query the on-disk index and combine the results with > those from the in-memory indexes created by CASSANDRA-18058. -- 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: ninjafix - add missing "resource" suppression (blame CASSANDRA-18134)
This is an automated email from the ASF dual-hosted git repository.
jlewandowski 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 ece0c4a44c ninjafix - add missing "resource" suppression (blame
CASSANDRA-18134)
ece0c4a44c is described below
commit ece0c4a44c9209dc64240f3f33ca7a57d7548daa
Author: Jacek Lewandowski
AuthorDate: Tue Feb 21 11:28:00 2023 +0100
ninjafix - add missing "resource" suppression (blame CASSANDRA-18134)
---
src/java/org/apache/cassandra/db/PartitionRangeReadCommand.java | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/java/org/apache/cassandra/db/PartitionRangeReadCommand.java
b/src/java/org/apache/cassandra/db/PartitionRangeReadCommand.java
index b3be264585..b01a79fcff 100644
--- a/src/java/org/apache/cassandra/db/PartitionRangeReadCommand.java
+++ b/src/java/org/apache/cassandra/db/PartitionRangeReadCommand.java
@@ -316,6 +316,7 @@ public class PartitionRangeReadCommand extends ReadCommand
implements PartitionR
}
@VisibleForTesting
+@SuppressWarnings("resource")
public UnfilteredPartitionIterator queryStorage(final ColumnFamilyStore
cfs, ReadExecutionController controller)
{
ColumnFamilyStore.ViewFragment view =
cfs.select(View.selectLive(dataRange().keyRange()));
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18134:
---
Resolution: (was: Fixed)
Status: Open (was: Resolved)
CI broke
https://ci-cassandra.apache.org/job/Cassandra-trunk-artifacts/1646/
{noformat}
09:47:06 eclipse-warnings:
09:47:06 [mkdir] Created dir:
/home/jenkins/jenkins-slave/workspace/Cassandra-trunk-artifacts/jdk/jdk_1.8_latest/label/cassandra/build/ecj
09:47:06 [echo] Running Eclipse Code Analysis. Output logged to
/home/jenkins/jenkins-slave/workspace/Cassandra-trunk-artifacts/jdk/jdk_1.8_latest/label/cassandra/build/ecj/eclipse_compiler_checks.txt
09:47:15 [java] --
09:47:15 [java] 1. ERROR in
/home/jenkins/jenkins-slave/workspace/Cassandra-trunk-artifacts/jdk/jdk_1.8_latest/label/cassandra/src/java/org/apache/cassandra/db/PartitionRangeReadCommand.java
(at line 365)
09:47:15 [java]return checkCacheFilter(Transformation.apply(merged,
new Transformation()
09:47:15 [java] {
09:47:15 [java] @Override
09:47:15 [java] protected void onClose()
09:47:15 [java] {
09:47:15 [java] super.onClose();
09:47:15 [java]
cfs.metric.updateSSTableIteratedInRangeRead(finalSelectedSSTables);
09:47:15 [java] }
09:47:15 [java] }), cfs);
09:47:15 [java]
09:47:15 [java] Potential resource leak: 'merged' may not be closed at
this location
09:47:15 [java] --
09:47:15 [java] 1 problem (1 error)
09:47:15
09:47:15 BUILD FAILED
09:47:15
/home/jenkins/jenkins-slave/workspace/Cassandra-trunk-artifacts/jdk/jdk_1.8_latest/label/cassandra/build.xml:1875:
Java returned: 255
{noformat}
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.2
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator o
[jira] [Updated] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18134:
--
Reviewers: Branimir Lambov, C. Scott Andreas
Source Control Link:
https://github.com/apache/cassandra/commit/24ebd24c79175f7426f4c489dc5a006e75f09dfb
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.2
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
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-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18134:
--
Resolution: Fixed
Status: Resolved (was: Open)
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
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-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18134:
--
Fix Version/s: 4.2
(was: 4.x)
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.2
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
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-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691407#comment-17691407
]
Jacek Lewandowski edited comment on CASSANDRA-18134 at 2/21/23 8:33 AM:
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2288/
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/576/workflows/1e3900c2-9d06-46a7-9314-f71921e161ae
was (Author: jlewandowski):
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2288/
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
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
