[jira] [Commented] (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=17691425#comment-17691425
]
Jacek Lewandowski commented on CASSANDRA-18134:
---
Regarding upgrading/downgrading discussion and the ability to support multiple
formats - we should consider also CEP-17 here as when it is merged, we will
have the ability to define separate formats with their own identifiers. If we
agree, we can follow up it with extending its functionality to define separate
implementations for version ranges - like we have one implementation for BIG
format from {{ma-nz}} and different for {{oa+}}. All in all that would allow us
to not mix the implementation with several ifs to handle downgrading.
> 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] [Commented] (CASSANDRA-17056) CEP-17 – Pluggable SSTable format (SSTable format API)
[ https://issues.apache.org/jira/browse/CASSANDRA-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691423#comment-17691423 ] Jacek Lewandowski commented on CASSANDRA-17056: --- [~benedict] this is just a key cache file. Perhaps unless we have a non-bigtable-only configuration we can keep the old format but this would introduce additional mess in the code as we would have to deal with two formats. IMO autosaving cache is not worth it - new cache files will be ignored by the old version when downgrading as the version is included in the file path. > CEP-17 – Pluggable SSTable format (SSTable format API) > -- > > Key: CASSANDRA-17056 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17056 > Project: Cassandra > Issue Type: New Feature > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.x > > Time Spent: 18.5h > Remaining Estimate: 0h > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API -- 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-18240) Using SELECT COUNT(*) FROM... LIMIT 1 in the returning section results in ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-18240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691418#comment-17691418
]
Jacek Lewandowski commented on CASSANDRA-18240:
---
thanks [~maedhroz], I'll rebase and test
> Using SELECT COUNT(*) FROM... LIMIT 1 in the returning section results in
> ClassCastException
>
>
> Key: CASSANDRA-18240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18240
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> {noformat}
> cqlsh>
> BEGIN TRANSACTION
> LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 5);
> SELECT COUNT(*) FROM ks.tbl1 LIMIT 1;
> IF row1 IS NULL THEN
> INSERT INTO ks.tbl1 (k, v) VALUES (5, 10);
> END IF
> COMMIT TRANSACTION;
> NoHostAvailable: ('Unable to complete the operation against any hosts',
> {: error] message="java.lang.ClassCastException:
> org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to
> org.apache.cassandra.db.SinglePartitionReadQuery$Group">})
> {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] [Commented] (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 commented on CASSANDRA-18134:
---
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
[jira] [Updated] (CASSANDRA-18275) Harry model and in-JVM test for partition-restricted 2i queries
[ https://issues.apache.org/jira/browse/CASSANDRA-18275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18275: Change Category: Quality Assurance Complexity: Challenging Component/s: Feature/2i Index Test/fuzz Fix Version/s: NA Status: Open (was: Triage Needed) > Harry model and in-JVM test for partition-restricted 2i queries > --- > > Key: CASSANDRA-18275 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18275 > Project: Cassandra > Issue Type: Task > Components: Feature/2i Index, Test/fuzz >Reporter: Caleb Rackliffe >Priority: Normal > Fix For: NA > > > The smallest useful scope for Harry testing w/ 2i would be to cover queries > within large partitions. Creating a model to do this should also be easier > than it would be for the “global” query case, so it seems like a good place > to start. The goal here should be to create something that can simply be run > for a specified amount of time as an in-JVM test and be run going forward as > part of our normal CI process. -- 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-18275) Harry model and in-JVM test for partition-restricted 2i queries
Caleb Rackliffe created CASSANDRA-18275: --- Summary: Harry model and in-JVM test for partition-restricted 2i queries Key: CASSANDRA-18275 URL: https://issues.apache.org/jira/browse/CASSANDRA-18275 Project: Cassandra Issue Type: Task Reporter: Caleb Rackliffe The smallest useful scope for Harry testing w/ 2i would be to cover queries within large partitions. Creating a model to do this should also be easier than it would be for the “global” query case, so it seems like a good place to start. The goal here should be to create something that can simply be run for a specified amount of time as an in-JVM test and be run going forward as part of our normal CI process. -- 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-18240) Using SELECT COUNT(*) FROM... LIMIT 1 in the returning section results in ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-18240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691297#comment-17691297
]
Caleb Rackliffe commented on CASSANDRA-18240:
-
[~jlewandowski] btw, CASSANDRA-18223 just merged, which should clean up the
Python dtest failures you might have seen in CI runs
> Using SELECT COUNT(*) FROM... LIMIT 1 in the returning section results in
> ClassCastException
>
>
> Key: CASSANDRA-18240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18240
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> {noformat}
> cqlsh>
> BEGIN TRANSACTION
> LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 5);
> SELECT COUNT(*) FROM ks.tbl1 LIMIT 1;
> IF row1 IS NULL THEN
> INSERT INTO ks.tbl1 (k, v) VALUES (5, 10);
> END IF
> COMMIT TRANSACTION;
> NoHostAvailable: ('Unable to complete the operation against any hosts',
> {: error] message="java.lang.ClassCastException:
> org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to
> org.apache.cassandra.db.SinglePartitionReadQuery$Group">})
> {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] [Updated] (CASSANDRA-18223) Byteman rule in stop_data_reads.btm cannot compile against accord.messages.ReplyContext
[
https://issues.apache.org/jira/browse/CASSANDRA-18223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18223:
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/33ff84a396c9d5b9a9be574be50dbb2ea9c9ded0
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Byteman rule in stop_data_reads.btm cannot compile against
> accord.messages.ReplyContext
> ---
>
> Key: CASSANDRA-18223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18223
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Caleb Rackliffe
>Assignee: Youki Shiraishi
>Priority: Normal
> Labels: byteman, dtest, python
> Fix For: NA
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The Python {{read_repair_test}} relies on a Byteman rule on the {{doVerb()}}
> method in {{ReadCommandVerbHandler}}, but {{accord.messages.ReplyContext}}
> isn’t on the classpath. This is probably because we don't include it in the
> list of jars created in {{byteman_validate}}.
> {noformat}
> AssertionError: byteman script didn't compile
> Checking rule disable data reads against class
> org.apache.cassandra.db.ReadCommandVerbHandler
> Parsed rule "disable data reads" for class
> org.apache.cassandra.db.ReadCommandVerbHandler
> ERROR : Failed to check rule "disable data reads" loaded from
> /home/cassandra/cassandra-dtest/byteman/read_repair/stop_data_reads.btm line
> 8 against method doVerb(org.apache.cassandra.net.Message) void
> java.lang.NoClassDefFoundError: accord/messages/ReplyContext
> {noformat}
> ex.
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/686/workflows/ffd1e528-b8ec-4534-a333-ab450e110e89/jobs/6481/tests#failed-test-0
> It might make sense to fix this after CASSANDRA-18204 wraps up, so we know
> exactly how the Accord library is pulled into C*. Then, once we do fix it, we
> should fix in a way that still works w/ 4.0 and 4.1, etc. (i.e. Don't assume
> the Accord library must be present.)
--
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-dtest] branch trunk updated: Add Accord library to Byteman classpath
This is an automated email from the ASF dual-hosted git repository.
maedhroz pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 33ff84a3 Add Accord library to Byteman classpath
33ff84a3 is described below
commit 33ff84a396c9d5b9a9be574be50dbb2ea9c9ded0
Author: Youki Shiraishi
AuthorDate: Sun Feb 19 18:46:48 2023 +0900
Add Accord library to Byteman classpath
patch by Youki Shiraishi; reviewed by Caleb Rackliffe for CASSANDRA-18223
---
read_repair_test.py | 4
1 file changed, 4 insertions(+)
diff --git a/read_repair_test.py b/read_repair_test.py
index f58d9f50..fbdcaf35 100644
--- a/read_repair_test.py
+++ b/read_repair_test.py
@@ -34,6 +34,10 @@ def byteman_validate(node, script, verbose=False, opts=None):
glob.glob(os.path.join(cdir, 'build', 'lib', 'jars',
'byteman-[0-9]*.jar'))[0],
os.path.join(cdir, 'build', '*'),
]
+
+if os.path.exists(os.path.join(cdir, 'modules', 'accord')):
+jars.append(glob.glob(os.path.join(cdir, 'modules', 'accord',
'accord-core', 'build', 'libs', 'accord-core-[0-9].[0-9]-SNAPSHOT.jar'))[0])
+
byteman_cmd.append(':'.join(jars))
byteman_cmd.append('org.jboss.byteman.check.TestScript')
byteman_cmd.append('-p')
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18223) Byteman rule in stop_data_reads.btm cannot compile against accord.messages.ReplyContext
[
https://issues.apache.org/jira/browse/CASSANDRA-18223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18223:
Status: Ready to Commit (was: Review In Progress)
Nice. Python dtests are looking clean. I'll commit this soon.
Thanks for the patch!
> Byteman rule in stop_data_reads.btm cannot compile against
> accord.messages.ReplyContext
> ---
>
> Key: CASSANDRA-18223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18223
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Caleb Rackliffe
>Assignee: Youki Shiraishi
>Priority: Normal
> Labels: byteman, dtest, python
> Fix For: NA
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The Python {{read_repair_test}} relies on a Byteman rule on the {{doVerb()}}
> method in {{ReadCommandVerbHandler}}, but {{accord.messages.ReplyContext}}
> isn’t on the classpath. This is probably because we don't include it in the
> list of jars created in {{byteman_validate}}.
> {noformat}
> AssertionError: byteman script didn't compile
> Checking rule disable data reads against class
> org.apache.cassandra.db.ReadCommandVerbHandler
> Parsed rule "disable data reads" for class
> org.apache.cassandra.db.ReadCommandVerbHandler
> ERROR : Failed to check rule "disable data reads" loaded from
> /home/cassandra/cassandra-dtest/byteman/read_repair/stop_data_reads.btm line
> 8 against method doVerb(org.apache.cassandra.net.Message) void
> java.lang.NoClassDefFoundError: accord/messages/ReplyContext
> {noformat}
> ex.
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/686/workflows/ffd1e528-b8ec-4534-a333-ab450e110e89/jobs/6481/tests#failed-test-0
> It might make sense to fix this after CASSANDRA-18204 wraps up, so we know
> exactly how the Accord library is pulled into C*. Then, once we do fix it, we
> should fix in a way that still works w/ 4.0 and 4.1, etc. (i.e. Don't assume
> the Accord library must be present.)
--
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-18223) Byteman rule in stop_data_reads.btm cannot compile against accord.messages.ReplyContext
[
https://issues.apache.org/jira/browse/CASSANDRA-18223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18223:
Reviewers: Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe)
Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe)
Status: Review In Progress (was: Patch Available)
> Byteman rule in stop_data_reads.btm cannot compile against
> accord.messages.ReplyContext
> ---
>
> Key: CASSANDRA-18223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18223
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Caleb Rackliffe
>Assignee: Youki Shiraishi
>Priority: Normal
> Labels: byteman, dtest, python
> Fix For: NA
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The Python {{read_repair_test}} relies on a Byteman rule on the {{doVerb()}}
> method in {{ReadCommandVerbHandler}}, but {{accord.messages.ReplyContext}}
> isn’t on the classpath. This is probably because we don't include it in the
> list of jars created in {{byteman_validate}}.
> {noformat}
> AssertionError: byteman script didn't compile
> Checking rule disable data reads against class
> org.apache.cassandra.db.ReadCommandVerbHandler
> Parsed rule "disable data reads" for class
> org.apache.cassandra.db.ReadCommandVerbHandler
> ERROR : Failed to check rule "disable data reads" loaded from
> /home/cassandra/cassandra-dtest/byteman/read_repair/stop_data_reads.btm line
> 8 against method doVerb(org.apache.cassandra.net.Message) void
> java.lang.NoClassDefFoundError: accord/messages/ReplyContext
> {noformat}
> ex.
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/686/workflows/ffd1e528-b8ec-4534-a333-ab450e110e89/jobs/6481/tests#failed-test-0
> It might make sense to fix this after CASSANDRA-18204 wraps up, so we know
> exactly how the Accord library is pulled into C*. Then, once we do fix it, we
> should fix in a way that still works w/ 4.0 and 4.1, etc. (i.e. Don't assume
> the Accord library must be present.)
--
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-18223) Byteman rule in stop_data_reads.btm cannot compile against accord.messages.ReplyContext
[
https://issues.apache.org/jira/browse/CASSANDRA-18223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18223:
Test and Documentation Plan: n/a (test fix)
Status: Patch Available (was: In Progress)
dtest patch: https://github.com/apache/cassandra-dtest/pull/210
[~shiraishi] I've started a CircleCI run that points to your dtest branch
[here|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-18223].
If that's clean, we should be able to merge.
> Byteman rule in stop_data_reads.btm cannot compile against
> accord.messages.ReplyContext
> ---
>
> Key: CASSANDRA-18223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18223
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Caleb Rackliffe
>Assignee: Youki Shiraishi
>Priority: Normal
> Labels: byteman, dtest, python
> Fix For: NA
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The Python {{read_repair_test}} relies on a Byteman rule on the {{doVerb()}}
> method in {{ReadCommandVerbHandler}}, but {{accord.messages.ReplyContext}}
> isn’t on the classpath. This is probably because we don't include it in the
> list of jars created in {{byteman_validate}}.
> {noformat}
> AssertionError: byteman script didn't compile
> Checking rule disable data reads against class
> org.apache.cassandra.db.ReadCommandVerbHandler
> Parsed rule "disable data reads" for class
> org.apache.cassandra.db.ReadCommandVerbHandler
> ERROR : Failed to check rule "disable data reads" loaded from
> /home/cassandra/cassandra-dtest/byteman/read_repair/stop_data_reads.btm line
> 8 against method doVerb(org.apache.cassandra.net.Message) void
> java.lang.NoClassDefFoundError: accord/messages/ReplyContext
> {noformat}
> ex.
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/686/workflows/ffd1e528-b8ec-4534-a333-ab450e110e89/jobs/6481/tests#failed-test-0
> It might make sense to fix this after CASSANDRA-18204 wraps up, so we know
> exactly how the Accord library is pulled into C*. Then, once we do fix it, we
> should fix in a way that still works w/ 4.0 and 4.1, etc. (i.e. Don't assume
> the Accord library must be present.)
--
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=17691242#comment-17691242
]
Blake Eggleston commented on CASSANDRA-18258:
-
{quote}I just don't see the purpose of having a separate IDE profile for the
higher JDK{quote}
That was added because the java 11 needed --add-exports etc, and those weren't
compatible with java 8. Agree it would be best if we didn't need separate
profiles
> 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=17691224#comment-17691224
]
Benedict Elliott Smith commented on CASSANDRA-14227:
By default we should reject TTLs past 2038, and while this setting is in place
we should continue to write \-nc\- format sstables. Once the operator
configures longer TTLs, we can write \-oa\- format sstables.
> 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=17691217#comment-17691217
]
Benjamin Lerer commented on CASSANDRA-14227:
{quote} It looks like we have an option to CAP to 2038, and if we default to
this on upgrade I think a downgrade should be smooth.{quote}
[~benedict] Could you elaborate a bit what you mean? I am not sure that I am
understanding what you have in mind.
> 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-17056) CEP-17 – Pluggable SSTable format (SSTable format API)
[ https://issues.apache.org/jira/browse/CASSANDRA-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691207#comment-17691207 ] Benedict Elliott Smith commented on CASSANDRA-17056: broken record, but it looks like there's some [more|https://github.com/apache/cassandra/pull/2064/files#diff-6f9e66ac70dce5dcf64dd3563010304ddc289760cdcb04bbf039993df1a48436R86] breaking serialisation changes here that maybe don't need to be breaking - or, if they do, should be opted into by the operator to ensure they may downgrade safely. > CEP-17 – Pluggable SSTable format (SSTable format API) > -- > > Key: CASSANDRA-17056 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17056 > Project: Cassandra > Issue Type: New Feature > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.x > > Time Spent: 18.5h > Remaining Estimate: 0h > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API -- 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-17056) CEP-17 – Pluggable SSTable format (SSTable format API)
[ https://issues.apache.org/jira/browse/CASSANDRA-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17056: --- Fix Version/s: 4.x (was: 5.x) > CEP-17 – Pluggable SSTable format (SSTable format API) > -- > > Key: CASSANDRA-17056 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17056 > Project: Cassandra > Issue Type: New Feature > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.x > > Time Spent: 18.5h > Remaining Estimate: 0h > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API -- 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-17056) Pluggable SSTable format (SSTable format API)
[ https://issues.apache.org/jira/browse/CASSANDRA-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17056: --- Mentor: (was: Branimir Lambov) Reviewers: Branimir Lambov Status: Review In Progress (was: Patch Available) > Pluggable SSTable format (SSTable format API) > - > > Key: CASSANDRA-17056 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17056 > Project: Cassandra > Issue Type: New Feature > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 18.5h > Remaining Estimate: 0h > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API -- 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-17056) CEP-17 – Pluggable SSTable format (SSTable format API)
[ https://issues.apache.org/jira/browse/CASSANDRA-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17056: --- Summary: CEP-17 – Pluggable SSTable format (SSTable format API) (was: Pluggable SSTable format (SSTable format API)) > CEP-17 – Pluggable SSTable format (SSTable format API) > -- > > Key: CASSANDRA-17056 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17056 > Project: Cassandra > Issue Type: New Feature > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > Time Spent: 18.5h > Remaining Estimate: 0h > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API -- 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-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691172#comment-17691172
]
Benedict Elliott Smith edited comment on CASSANDRA-17698 at 2/20/23 2:09 PM:
-
I see, there is some string parsing from the type info in
{{SerializationHeader}}.
Like most of the other recent sstable changes, it seems pretty unnecessary to
make a major version bump here, when we could either serialise this additional
information to the end of the header, or serialise the type twice (once with
extra info).
And arguably, since this is a bug, we really _should_ be doing this so it can
be fixed in released versions (though it's a minor bug AFAICT, so probably fine
to remain unpatched)
was (Author: benedict):
I see, there is some string parsing from the type info in
{{SerializationHeader}}.
Like most of the other recent sstable changes, it seems pretty unnecessary to
make a major version bump here, when we could either serialise this additional
information to the end of the header, or serialise the type twice (once with
extra info).
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-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:
---
Fix Version/s: 4.x
(was: 5.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.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] [Comment Edited] (CASSANDRA-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691172#comment-17691172
]
Benedict Elliott Smith edited comment on CASSANDRA-17698 at 2/20/23 1:15 PM:
-
I see, there is some string parsing from the type info in
{{SerializationHeader}}.
Like most of the other recent sstable changes, it seems pretty unnecessary to
make a major version bump here, when we could either serialise this additional
information to the end of the header, or serialise the type twice (once with
extra info).
was (Author: benedict):
I see, there is some string parsing from the type info in
{{SerializationHeader}}.
Like most of the other changes it seems pretty unnecessary to make a major
version bump here, when we could either serialise this additional information
to the end of the header, or serialise the type twice (once with extra info).
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691172#comment-17691172
]
Benedict Elliott Smith commented on CASSANDRA-17698:
I see, there is some string parsing from the type info in
{{SerializationHeader}}.
Like most of the other changes it seems pretty unnecessary to make a major
version bump here, when we could either serialise this additional information
to the end of the header, or serialise the type twice (once with extra info).
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691167#comment-17691167
]
maxwellguo commented on CASSANDRA-17698:
For the original secondary index table just use the original data table's
partition key as the first clusting key , but the data type is
PartitionerDefinedOrder , but this case do not implement the toJSONString
method(I think that is not really data type can be used for this).
So at first I have got two way to fix this problem,
1: add a partitionKeyType in the PartitionerDefinedOrder as this patch
described ,but the PartitionerDefinedOrder 's toString result will be store in
the meta file of sstable, this way I changed the sstable content;
2.use the partitionkey real type as the secondary index table's first
clustering key (not PartitionerDefinedOrder), but this will also change the
content of secondary index's table 's sstable file( the old version 's sstable
file 's meta store the PartitionerDefinedOrder's toString , now change to data
table's paritition key toString )
[here|https://github.com/apache/cassandra/pull/2118/files#diff-a7e8323c9332e6c0d12b0ef92709fa241342fc505a4bdf144b146e9f22cb9adaR738]
Both can solve the problem, and both change the content of sstable.For me I
have chosen the first one ,as I use PartitionerDefinedOrder as index's table's
first clusting key, and I just want to implement the toJSONString method , for
the old version that do not have a paritionKeyType in
PartitionerDefinedOrder the original method path can be executed.
Besides, I think this is a low risk modification method, for I do not change
the original schema of secondary index(the first clustering key type is still
PartitionerDefinedOrder).
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691161#comment-17691161
]
Branimir Lambov commented on CASSANDRA-17698:
-
Before the patch, {{PartitionerDefinedOrder}} provided no information about the
type of data that is contained in the clustering key of the index table. As a
result it was not possible to print the value for {{{}sstabledump{}}}. This
patch adds a base type to the definition of the clustering column type, so that
it can be properly interpreted. Since this type definition is not readable by
older versions of the code, the header of an sstable written after this patch
that contains a clustering column of this type (i.e. a legacy secondary index
table) will not be readable by older versions, and thus they will not be able
to open the sstable.
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[ https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691151#comment-17691151 ] Stefan Miklosovic commented on CASSANDRA-17561: --- btw isnt it true that as soon as there is some topology change and nodes are not responsible for so and so ranges anymore, that information in snapshot is pretty much useless, no? [~samt] what do you think about this request? > Diagnostic snapshot service should only snapshot mismatching ranges on > preview repair mismatch > -- > > Key: CASSANDRA-17561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > We currently snapshot all sstables in a table when a preview repair mismatch > occurs, we should only snapshot the sstables containing the mismatching ranges -- 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-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18270:
--
Bug Category: Parent values: Code(13163)
Complexity: Normal
Component/s: Local/Other
Discovered By: Adhoc Test
Fix Version/s: 4.1.x
4.x
Severity: Low
Status: Open (was: Triage Needed)
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
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-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691130#comment-17691130
]
Benedict Elliott Smith commented on CASSANDRA-17698:
(Copied from email reply)
{quote}for old version‘s index data using this version’s dump code ，I think
there
will not be much difference（may be only exception message‘s difference），It
is backwards compactibility I think .But I change the content of
sstable（adding a new base type for partitionordertype）.😅{quote}
Could you explain why this needs to change what is written? It's not clear to
me, nor from skimming the patch. If this does change what is written it _must_
bump the sstable version, but I'd like to understand what's changing and why,
so we can figure out if this needs to be a minor or major bump.
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [jira] [Commented] (CASSANDRA-17698) sstabledump errors when dumping data from index
for old version‘s index data using this version’s dump code ，I think there
will not be much difference（may be only exception message‘s difference），It
is backwards compactibility I think .But I change the content of
sstable（adding a new base type for partitionordertype）.😅
Benedict Elliott Smith (Jira) 于2023年2月20日 周一下午5:07写道：
>
> [
> https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691078#comment-17691078
> ]
>
> Benedict Elliott Smith commented on CASSANDRA-17698:
>
>
> Could somebody ELI5 why this needs to break backwards compatibility?
>
> > sstabledump errors when dumping data from index
> > ---
> >
> > Key: CASSANDRA-17698
> > URL:
> https://issues.apache.org/jira/browse/CASSANDRA-17698
> > Project: Cassandra
> > Issue Type: Bug
> > Components: Tool/sstable
> >Reporter: Stefan Miklosovic
> >Assignee: maxwellguo
> >Priority: Normal
> > Fix For: 5.x
> >
> > Time Spent: 12h 40m
> > Remaining Estimate: 0h
> >
> > {code:java}
> > cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
> > cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> > cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> > cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> > cqlsh> exit
> > ./bin/nodetool flush
> > ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
> > [
> > {
> > "partition" : {
> > "key" : [ "Joe" ],
> > "position" : 0
> > },
> > "rows" : [
> > {
> > "type" : "row",
> > "position" : 17,
> > "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> > at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> > at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> > at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> > at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> > at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> > at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> > at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> > at java.util.Iterator.forEachRemaining(Iterator.java:116)
> > at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> > at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> > at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> > at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> > at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> > at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> > at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> > at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> > at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {code}
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.10#820010)
>
> -
> To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: commits-h...@cassandra.apache.org
>
> --
you are the apple of my eye !
[jira] [Commented] (CASSANDRA-18068) Allow to attach native masking functions to table columns
[
https://issues.apache.org/jira/browse/CASSANDRA-18068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691102#comment-17691102
]
Benjamin Lerer commented on CASSANDRA-18068:
[~adelapena] I am not entirely convinced about the static change. `STATIC` is a
critical piece of information much more important than the masking one. Putting
it after the mask makes it much less visible.
> Allow to attach native masking functions to table columns
> -
>
> Key: CASSANDRA-18068
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18068
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 8h
> Remaining Estimate: 0h
>
> Allow to attach the native masking functions added by CASSANDRA-17941 to
> table columns, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> {{CREATE TABLE}} statements would look like:
> {code}
> > CREATE TABLE patients (
> id timeuuid PRIMARY KEY,
> name text MASKED WITH partial(2, 1),
> birth date MASKED WITH default()
> );
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21);
>
> > SELECT name, birth FROM patients;
>
> name| birth
> -+
> ale | 1900-01-01
> {code}
> {{ALTER TABLE}} statements would look like:
> {code}
> > ALTER TABLE patients ALTER name MASKED WITH partial(2, 1);
> > ALTER TABLE patients ALTER name WITHOUT MASK;
> {code}
> It won't be possible to use masked columns in the WHERE and IF clauses of
> SELECT and UPDATE statements.
--
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=17691101#comment-17691101
]
Michael Semb Wever commented on CASSANDRA-18258:
bq. Yes, until then and the drop of JDK8 I guess we should say "Cassandra 5.0
requires Java 8 or Java 11". 17 is still not really supported so I guess we can
skip mentioning it for now? WDYT? Or we can add also "Java 17 experimental" or
so?
Yes to your suggestions, like (so to keep the code as close to post-18255 as
possible):
{noformat}
elif [ "$JVM_VERSION" \< "17" ] ; then
echo "Cassandra 5.0 requires Java 11 or Java 17."
#exit 1; # TODO – uncomment when CASSANDRA-18255 lands
else
echo "Java 17 is experimental in Cassandra 5.0"
fi
{noformat}
{quote}
bq. nit: regarding target name="_maybe_update_idea_to_java17"
if="java.version.17"
That is nothing more than using an equivalent to Java 11 target name but a new
one for 17, but I am open for suggestions.
{quote}
Didn't mean to imply you were encouraging anything :-)
I just don't see the purpose of having a separate IDE profile for the higher
JDK, because you have to code against the lowest supported JDK anyway. Maybe
[~bdeggleston] knows from when CASSANDRA-15108 was introduced, but I suspect it
was just added without much discussion.
bq. We need to have it with the three options so people can easily debug JDK
specific issues, no?
Good question. This code looks only to flip the language level from one jdk to
the other. Changing the runtime jdk used, and just general custom jdk17 editing
if that's what you really want, should just be done by editing the settings
manually, IMHO.
So my suggestion is to remove both {{_maybe_update_idea_to_java11}} and
{{_maybe_update_idea_to_java17}} targets and see if anyone complains…
> 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-18125) AssertionError on thread MemtableReclaimMemory in MemtablePool$SubPool.released(MemtablePool.java:193)
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691099#comment-17691099
]
Benjamin Lerer commented on CASSANDRA-18125:
Thanks [~benedict], I will look at it today.
> AssertionError on thread MemtableReclaimMemory in
> MemtablePool$SubPool.released(MemtablePool.java:193)
> --
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Nicolas Henneaux
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18247) Add CircleCI config file for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691086#comment-17691086 ] Michael Semb Wever commented on CASSANDRA-18247: bq. I have a preliminary patch for this one, but then it seems we might want to rework it for CASSANDRA-18133. Let's do that in a separate (improvement) ticket. 18133 won't land in time for this (and we don't want to block jdk17 work on it). > Add CircleCI config file for J11+J17 > > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose a CircleCI config file which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- 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-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691078#comment-17691078
]
Benedict Elliott Smith commented on CASSANDRA-17698:
Could somebody ELI5 why this needs to break backwards compatibility?
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18274) org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-18274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691075#comment-17691075
]
Michael Semb Wever commented on CASSANDRA-18274:
Correct link is
https://ci-cassandra.apache.org/job/Cassandra-4.1/277/testReport/org.apache.cassandra.utils.binlog/BinLogTest/testTruncationReleasesLogSpace_compression/
(bug in jenkins)
And via the console log you can see which the stage build number for this stage
(test-compression) was, and navigate to the original build and test failure
which will provide more logs, e.g.
https://ci-cassandra.apache.org/job/Cassandra-4.1-test-compression/240/jdk=jdk_11_latest,label=cassandra,split=2/testReport/junit/org.apache.cassandra.utils.binlog/BinLogTest/testTruncationReleasesLogSpace_compression/
Failed 2 times in the last 30 runs. Flakiness: 6%, Stability: 93%
Error Message
{noformat}
Assertion condition defined as a lambda expression in org.apache.cassandra.Util
that uses java.lang.String, java.lang.Stringjava.util.function.Supplier,
java.util.function.Supplierjava.lang.Object null
Expected: <2>
but: was <3> within 1 minutes.
{noformat}
Stacktrace
{noformat}
org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a
lambda expression in org.apache.cassandra.Util that uses java.lang.String,
java.lang.Stringjava.util.function.Supplier,
java.util.function.Supplierjava.lang.Object null
Expected: <2>
but: was <3> within 1 minutes.
at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
at org.apache.cassandra.Util.spinAssertEquals(Util.java:684)
at org.apache.cassandra.Util.spinAssertEquals(Util.java:675)
at
org.apache.cassandra.utils.binlog.BinLogTest.flakyTestTruncationReleasesLogSpace(BinLogTest.java:466)
at org.apache.cassandra.Util.runCatchingAssertionError(Util.java:696)
at org.apache.cassandra.Util.flakyTest(Util.java:721)
at
org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace(BinLogTest.java:433)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Caused by: java.lang.AssertionError: null
Expected: <2>
but: was <3>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.apache.cassandra.Util.lambda$spinAssertEquals$0(Util.java:684)
at
org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53)
at
org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:222)
at
org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:209)
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 java.base/java.lang.Thread.run(Thread.java:829)
{noformat}
> org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression
> ---
>
> Key: CASSANDRA-18274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18274
> Project: Cassandra
> Issue Type: Bug
>Reporter: maxwellguo
>Assignee: maxwellguo
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.1/277/testReport/org.apache.cassandra.utils.binlog/BinLogTest/testTruncationReleasesLogSpace_compression/
--
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-18272) dtest-large.consistency_test.TestAccuracy.test_simple_strategy_users
[
https://issues.apache.org/jira/browse/CASSANDRA-18272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18272:
---
Resolution: Won't Fix
Status: Resolved (was: Triage Needed)
Same as CASSANDRA-18273
> dtest-large.consistency_test.TestAccuracy.test_simple_strategy_users
>
>
> Key: CASSANDRA-18272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18272
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: maxwellguo
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1460/testReport/dtest-large.consistency_test/TestAccuracy/test_simple_strategy_users/
> self =
> @pytest.mark.resource_intensive
> def test_simple_strategy_users(self):
> """
> Test for a single datacenter, users table, only the each quorum reads.
> """
> self.nodes = 5
> self.rf = 3
>
> combinations = [
> (ConsistencyLevel.ALL, ConsistencyLevel.ALL),
> (ConsistencyLevel.QUORUM, ConsistencyLevel.QUORUM),
> (ConsistencyLevel.ALL, ConsistencyLevel.ONE),
> (ConsistencyLevel.ONE, ConsistencyLevel.ALL),
> (ConsistencyLevel.QUORUM, ConsistencyLevel.ONE),
> (ConsistencyLevel.ONE, ConsistencyLevel.QUORUM),
> (ConsistencyLevel.TWO, ConsistencyLevel.TWO),
> (ConsistencyLevel.ONE, ConsistencyLevel.THREE),
> (ConsistencyLevel.THREE, ConsistencyLevel.ONE),
> (ConsistencyLevel.ANY, ConsistencyLevel.ONE),
> (ConsistencyLevel.ONE, ConsistencyLevel.ONE),
> (ConsistencyLevel.ONE, ConsistencyLevel.TWO),
> (ConsistencyLevel.TWO, ConsistencyLevel.ONE),
> # These are multi-DC consistency levels that should default to
> quorum calls
> (ConsistencyLevel.EACH_QUORUM, ConsistencyLevel.LOCAL_QUORUM),
> (ConsistencyLevel.LOCAL_QUORUM, ConsistencyLevel.LOCAL_QUORUM),
> (ConsistencyLevel.QUORUM, ConsistencyLevel.SERIAL,
> ConsistencyLevel.SERIAL),
> (ConsistencyLevel.QUORUM, ConsistencyLevel.LOCAL_SERIAL,
> ConsistencyLevel.SERIAL),
> ]
>
> logger.debug("Testing single dc, users")
> >
> > self._run_test_function_in_parallel(TestAccuracy.Validation.validate_users,
> > [self.nodes], [self.rf], combinations)
> consistency_test.py:596:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> consistency_test.py:528: in _run_test_function_in_parallel
> self._start_cluster(save_sessions=True,
> requires_local_reads=requires_local_reads)
> consistency_test.py:135: in _start_cluster
> cluster.start()
> ../venv/lib/python3.8/site-packages/ccmlib/cluster.py:548: in start
> node.watch_log_for(start_message, timeout=timeout, process=p,
> verbose=verbose, from_mark=mark,
> ../venv/lib/python3.8/site-packages/ccmlib/node.py:589: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1676474289.4235764, timeout = 120
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\n Head: INFO [main] 2023-02-15
> 15:18:03,417...f5f11f/nb-1-big-Data.db (0.097KiB) for commitlog position
> CommitLogPosition(segmentId=1676474297753, position=37210)\n"
> node = 'node1'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 15 Feb 2023 15:20:09 [node1] after
> 120.48/120 seconds Missing: ['Starting listening for CQL clients'] not found
> in system.log:
> EHead: INFO [main] 2023-02-15 15:18:03,417 YamlConfigura
> ETail:
> ...olumns-5e7583b5f3f43af19a39b7e1d6f5f11f/nb-1-big-Data.db (0.097KiB) for
> commitlog position CommitLogPosition(segmentId=1676474297753, position=37210)
> ../venv/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> This error occurs tiwce of same error message of timeout.
--
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-18273) Timeout occurred. Please note the time in the report does not reflect the time until the timeout.
[ https://issues.apache.org/jira/browse/CASSANDRA-18273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18273: --- Resolution: Won't Fix Status: Resolved (was: Triage Needed) > Timeout occurred. Please note the time in the report does not reflect the > time until the timeout. > - > > Key: CASSANDRA-18273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18273 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: maxwellguo >Priority: Normal > > https://ci-cassandra.apache.org/job/Cassandra-4.0/544/testReport/org.apache.cassandra.service/ClientWarningsTest/terminated_successfully/ > https://ci-cassandra.apache.org/job/Cassandra-trunk/1462/testReport/org.apache.cassandra.service.paxos/PaxosRepairHistoryTest/testRandomTrims/ -- 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-18273) Timeout occurred. Please note the time in the report does not reflect the time until the timeout.
[
https://issues.apache.org/jira/browse/CASSANDRA-18273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691071#comment-17691071
]
Michael Semb Wever commented on CASSANDRA-18273:
Yeah, we don't create bug tickets for these, as it's considered
test-infrastructure failures. Which we are working on separately
(CASSANDRA-18137).
The Build Lead confluence page needs to be updated to better highlight to look
for and ignore these `{{Timeout occurred. Please note the time in the report
does not reflect the time until the timeout.}}` failures.
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> -
>
> Key: CASSANDRA-18273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18273
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: maxwellguo
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/544/testReport/org.apache.cassandra.service/ClientWarningsTest/terminated_successfully/
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1462/testReport/org.apache.cassandra.service.paxos/PaxosRepairHistoryTest/testRandomTrims/
--
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-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=17691069#comment-17691069
]
Michael Semb Wever commented on CASSANDRA-18134:
bq. Can I merge it to trunk given CI is OK?
+1 [~jlewandowski]
Looks like {{\-nc\-}} is going to be temporary. CASSANDRA-17698 is going to
land in trunk before May and bump it to {{\-oa\-}} anyway.
While there's a soft leaning here towards (5) as the way to approach this
otherwise, there's a strong desire (from all?) to move ahead with
CASSANDRA-8110 which may or may not influence the need and choice(s) on how we
deal with minor format evolutions over multiple branches.
> 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: 5.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
