[jira] [Updated] (CASSANDRA-15583) 4.0 quality testing: Tooling, Bundled and First Party
[ https://issues.apache.org/jira/browse/CASSANDRA-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15583: Issue Type: Task (was: Epic) > 4.0 quality testing: Tooling, Bundled and First Party > - > > Key: CASSANDRA-15583 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15583 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Sam Tunnicliffe* > Test plans should cover bundled first-party tooling and CLIs such as > nodetool, cqlsh, and new tools supporting full query and audit logging > (CASSANDRA-13983, CASSANDRA-12151). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15809) ASF CI builds for JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-15809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17157153#comment-17157153 ] shylaja kokoori commented on CASSANDRA-15809: - [~mck] Your changes look good > ASF CI builds for JDK11 > --- > > Key: CASSANDRA-15809 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15809 > Project: Cassandra > Issue Type: Task > Components: Build, CI >Reporter: Michael Semb Wever >Assignee: shylaja kokoori >Priority: Normal > Fix For: 4.0-beta > > Attachments: Screenshot 2020-05-13 at 09.39.56.png, > build_with_multiple_jdk.patch > > > ASF CI builds today only run on JDK1.8 > On the Jenkins cluster JDKs from 1.4 through to 15 are available. See > attached screenshot for naming specifics. > This ticket is to add JDK11 compile and test targets on Cassandra-trunk, for > parity to CircleCI's workflows. (There is also the question about > testing/running on Cassandra-2.2 which needs to support JDK1.7, though > Cassandra-2.2 is nearing EOL.) > > The JDK is specified in the groovy DSL: > [https://github.com/apache/cassandra-builds/blob/master/jenkins-dsl/cassandra_job_dsl_seed.groovy#L11] > > > Some examples: > * CircleCI JDK1.8 workflow example. This builds with JDK1.8 and tests with > both JDK1.8 and JDK11. > ** > [https://app.circleci.com/pipelines/github/dcapwell/cassandra/259/workflows/bce6fbf9-a4a3-4bfd-be7d-3e7961b440d8] > * CircleCI JDK11 workflow example. This builds and tests only with JDK11. > ** > [https://app.circleci.com/pipelines/github/dcapwell/cassandra/259/workflows/38e7d77e-1d5e-47f7-a462-277665428306] > * Jenkins Cqlshlib tests showing matrix builds: > ** > [https://ci-cassandra.apache.org/view/Cassandra%204.0/job/Cassandra-trunk-cqlsh-tests/] > > Background > thread:[https://lists.apache.org/thread.html/rbaeb960901fa53b50227b37d64e5a456b68f749f4229c6e3e086ff85%40%3Cdev.cassandra.apache.org%3E] > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15766) NoSpamLogger arguments building objects on hot paths
[ https://issues.apache.org/jira/browse/CASSANDRA-15766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17157149#comment-17157149 ] Caleb Rackliffe commented on CASSANDRA-15766: - [~jmeredithco] I'm considering taking this over after taking a quick look at the WIP and history behind the ticket (and dropping a [quick question|https://github.com/apache/cassandra/pull/582/files#r454099460] in the PR). For what it's worth, I probably wouldn't expand the scope beyond what's already been touched...to the extent I might unmark CASSANDRA-15764 as a duplicate. Any objections? > NoSpamLogger arguments building objects on hot paths > > > Key: CASSANDRA-15766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15766 > Project: Cassandra > Issue Type: Bug > Components: Observability/Logging >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.0-beta > > > NoSpamLogger is used in hot logging paths to prevent logs being overrun. For > that to be most effective the arguments to the logger need to be cheap to > construct. During the internode messaging refactor CASSANDRA-15066, > performance changes to BufferPool for CASSANDRA-14416 > were accidentally reverted in the merge up from 3.11. > Reviewing other uses since, it looks like there are a few places where the > arguments require some form of String building. > org.apache.cassandra.net.InboundSink#accept > org.apache.cassandra.net.InboundMessageHandler#processCorruptFrame > org.apache.cassandra.net.InboundMessageHandler.LargeMessage#deserialize > org.apache.cassandra.net.OutboundConnection#onOverloaded > org.apache.cassandra.utils.memory.BufferPool.GlobalPool#allocateMoreChunks > Formatting arguments should either be precomputed, or if expensive they > should be computed after the decision on whether to noSpamLog has been made. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15941) Upgrade to lz4-java 1.7.2 when released
David Capwell created CASSANDRA-15941: - Summary: Upgrade to lz4-java 1.7.2 when released Key: CASSANDRA-15941 URL: https://issues.apache.org/jira/browse/CASSANDRA-15941 Project: Cassandra Issue Type: Improvement Components: Build Reporter: David Capwell Assignee: David Capwell After upgrading lz4-java I saw that CentOS 6 was no longer supported via native and filed a ticket https://github.com/lz4/lz4-java/issues/163 on the lz4-java project. This ticket is now closed and targeted for the next lz4 release (assume to be 1.7.2); once this release comes out we should upgrade. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15941) Upgrade to lz4-java 1.7.2 when released
[ https://issues.apache.org/jira/browse/CASSANDRA-15941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15941: -- Change Category: Performance Complexity: Low Hanging Fruit Fix Version/s: 4.x Status: Open (was: Triage Needed) > Upgrade to lz4-java 1.7.2 when released > --- > > Key: CASSANDRA-15941 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15941 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > After upgrading lz4-java I saw that CentOS 6 was no longer supported via > native and filed a ticket https://github.com/lz4/lz4-java/issues/163 on the > lz4-java project. This ticket is now closed and targeted for the next lz4 > release (assume to be 1.7.2); once this release comes out we should upgrade. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15940) Create better third-party page
Lorina Poland created CASSANDRA-15940: - Summary: Create better third-party page Key: CASSANDRA-15940 URL: https://issues.apache.org/jira/browse/CASSANDRA-15940 Project: Cassandra Issue Type: Improvement Components: Documentation/Website Reporter: Lorina Poland Assignee: Lorina Poland Create a better third-party page based on dev mailing list conversation. https://lists.apache.org/thread.html/r90076db617bf8615ae03567fa089bfe0ae31f1aa63ef8e2242bd9701%40%3Cdev.cassandra.apache.org%3E -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13994) Remove dead compact storage code before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156999#comment-17156999
]
Ekaterina Dimitrova edited comment on CASSANDRA-13994 at 7/13/20, 10:12 PM:
[~slebresne] post review changes done and committed to this [pull request |
https://github.com/ekaterinadimitrova2/cassandra/pull/30] . I didn't squash the
commits so you can easily identify the latest changes. I will do it + remove
the CircleCI custom config as soon as we agree on the final version of the
patch.
CI looks good to me:
[JAVA8 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/275/workflows/8bb7dda4-0ba2-491c-bc85-dd96814f8bfb]
[JAVA 11 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/275/workflows/e61bcd92-d57f-42e9-8771-1b883863f93d]
The failures are not related.
Unfortunately, on CircleCI this is the best we can get from the upgrade tests
due to resource allocation issues.
[~mck], is it possible to run them in Jenkins at the moment?
was (Author: e.dimitrova):
[~slebresne] post review changes done and committed to this [pull request |
https://github.com/ekaterinadimitrova2/cassandra/pull/30] .
CI looks good to me:
[JAVA8 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/275/workflows/8bb7dda4-0ba2-491c-bc85-dd96814f8bfb]
[JAVA 11 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/275/workflows/e61bcd92-d57f-42e9-8771-1b883863f93d]
The failures are not related.
Unfortunately, on CircleCI this is the best we can get from the upgrade tests
due to resource allocation issues.
[~mck], is it possible to run them in Jenkins at the moment?
> Remove dead compact storage code before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13994) Remove dead compact storage code before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-13994:
Test and Documentation Plan:
Existing tests
[Patch | https://github.com/ekaterinadimitrova2/cassandra/pull/30]
was:existing tests
Status: Patch Available (was: In Progress)
> Remove dead compact storage code before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13994) Remove dead compact storage code before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156999#comment-17156999
]
Ekaterina Dimitrova commented on CASSANDRA-13994:
-
[~slebresne] post review changes done and committed to this [pull request |
https://github.com/ekaterinadimitrova2/cassandra/pull/30] .
CI looks good to me:
[JAVA8 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/275/workflows/8bb7dda4-0ba2-491c-bc85-dd96814f8bfb]
[JAVA 11 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/275/workflows/e61bcd92-d57f-42e9-8771-1b883863f93d]
The failures are not related.
Unfortunately, on CircleCI this is the best we can get from the upgrade tests
due to resource allocation issues.
[~mck], is it possible to run them in Jenkins at the moment?
> Remove dead compact storage code before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15909) Make Table/Keyspace Metric Names Consistent With Each Other
[ https://issues.apache.org/jira/browse/CASSANDRA-15909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15909: -- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Make Table/Keyspace Metric Names Consistent With Each Other > --- > > Key: CASSANDRA-15909 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15909 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Stephen Mallette >Assignee: Stephen Mallette >Priority: Normal > Fix For: 4.0-beta > > > As part of CASSANDRA-15821 it became apparent that certain metric names found > in keyspace and tables had different names but were in fact the same metric - > they are as follows: > * Table.SyncTime == Keyspace.RepairSyncTime > * Table.RepairedDataTrackingOverreadRows == Keyspace.RepairedOverreadRows > * Table.RepairedDataTrackingOverreadTime == Keyspace.RepairedOverreadTime > * Table.AllMemtablesHeapSize == Keyspace.AllMemtablesOnHeapDataSize > * Table.AllMemtablesOffHeapSize == Keyspace.AllMemtablesOffHeapDataSize > * Table.MemtableOnHeapSize == Keyspace.MemtableOnHeapDataSize > * Table.MemtableOffHeapSize == Keyspace.MemtableOffHeapDataSize > Also, client metrics are the only metrics to start with a lower case letter. > Change those to upper case to match all the other metrics. > Unifying this naming would help make metrics more consistent as part of > CASSANDRA-15582 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15935) Improve machinery for testing consistency in presence of range movements
[ https://issues.apache.org/jira/browse/CASSANDRA-15935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15935: -- Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > Improve machinery for testing consistency in presence of range movements > > > Key: CASSANDRA-15935 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15935 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Currently, we can test range movements only by adding and bootstrapping a new > node. This is both inefficient and insufficient for large-scale tests. We > need a possibility to dynamically change ring ownership over the lifetime of > cluster, with a flexibility to changing gossip status of the node from > perspective of other participants, adding and removing nodes from other > nodes' views on demand. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15928) Throw FSWriteError upon write failures in order to apply DiskFailurePolicy
[ https://issues.apache.org/jira/browse/CASSANDRA-15928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-15928: -- Test and Documentation Plan: ci Status: Patch Available (was: Open) > Throw FSWriteError upon write failures in order to apply DiskFailurePolicy > -- > > Key: CASSANDRA-15928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15928 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Attachments: intellij_custom_insepction.xml > > Time Spent: 10m > Remaining Estimate: 0h > > Active handling of FSError in AbstractLocalAwareExecutorService was > introduced in CASSANDRA-14993. > > However, in the current code base, there are places that catch the > IOException but not wrap it with FSError, hence not triggering the > DiskFailurePolicy. Especially when the bad disk no longer permits write > operations, it could leads to the mutation stage backup. Therefore I propose > to fix the IOException handling in those cases. > > From the code inspection, those 6 places are current not re-throwing an > IOException with FSWriteError. > # org.apache.cassandra.triggers.CustomClassLoader#addClassPath throws > IOError. Invoked in TriggerExecutor's constructor > # org.apache.cassandra.io.util.FileUtils#renameWithConfirm throws > RuntimeException > # org.apache.cassandra.io.util.FileUtils#truncate throws RuntimeException > # org.apache.cassandra.io.util.FileUtils#write throws RuntimeException > # org.apache.cassandra.db.compaction.LeveledManifest#sendBackToL0 throws > RuntimeException. Invokes rewriteSSTableMetadata > # org.apache.cassandra.io.sstable.SSTableHeaderFix#writeNewMetadata throws > RuntimeException. Invokes rewriteSSTableMetadata -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15936) Extend IInternodeAuthenticator to inspect existing connections
[
https://issues.apache.org/jira/browse/CASSANDRA-15936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15936:
--
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Extend IInternodeAuthenticator to inspect existing connections
> --
>
> Key: CASSANDRA-15936
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15936
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> The internode authenticator ({{IInternodeAuthenticator}}) should support
> inspecting the existing connections and close the connections if no longer
> permitted.
> It would be useful and necessary for the dynamic internode authenticator
> implementations, which may stop authenticating connections between some nodes
> at a later time point.
> The current interface only authenticates on a connection during tcp/nodes
> handshake. It leaves the existing connection alive and the nodes are still
> able to communicate, after the authenticator has been updated to not permit
> connections between the nodes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15938) Fix support for adding UDT fields to clustering keys
[ https://issues.apache.org/jira/browse/CASSANDRA-15938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15938: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Unrecoverable Corruption / Loss(13161) Complexity: Challenging Component/s: Feature/UDT Discovered By: User Report Fix Version/s: 4.0-alpha 3.11.x 3.0.x Severity: Critical Status: Open (was: Triage Needed) > Fix support for adding UDT fields to clustering keys > > > Key: CASSANDRA-15938 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15938 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDT >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-alpha > > > Adding UDT fields to clustering keys is broken in all versions, however > slightly differently. > In 4.0, there will be a brief moment while schema changes are propagated > during which we won’t be able to decode and compare byte sequences. > Unfortunately, it is unclear what we should do in such cases, since we can’t > just come up with a comparator, and we can’t ignore non-null trailing values, > since this will lead to cases where compare for tuples `a;1` and `a;2` would > return 0, effectively making them equal, and we don’t know how to compare > unknown trailing values. Probably we should reject such query since we can’t > sort correctly, but we should make the error message more descriptive than > just "Index 1 out of bounds for length 1”. The only problem is that we get > this exception only on flush right now, so data already propagates to the > node by that time. > In 3.0, the problem is a bit worse than that, since in 3.0 we do not ignore > trailing nulls, so some of the values, written before `ALTER TYPE .. ADD` > become inaccessible. Both old values, and the new ones should always be > accessible. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15459) Short read protection doesn't work on group-by queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-15459:
Reviewers: Benjamin Lerer, Caleb Rackliffe (was: Benjamin Lerer)
> Short read protection doesn't work on group-by queries
> --
>
> Key: CASSANDRA-15459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15459
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination
>Reporter: ZhaoYang
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: correctness
> Fix For: 3.11.7, 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [DTest to
> reproduce|https://github.com/apache/cassandra-dtest/compare/master...jasonstack:srp_group_by_trunk?expand=1]:
> it affects all versions..
> {code}
> In a two-node cluster with RF = 2
> Execute only on Node1:
> * Insert pk=1 and ck=1 with timestamp 9
> * Delete pk=0 and ck=0 with timestamp 10
> * Insert pk=2 and ck=2 with timestamp 9
> Execute only on Node2:
> * Delete pk=1 and ck=1 with timestamp 10
> * Insert pk=0 and ck=0 with timestamp 9
> * Delete pk=2 and ck=2 with timestamp 10
> Query: "SELECT pk, c FROM %s GROUP BY pk LIMIT 1"
> * Expect no live data, but got [0, 0]
> {code}
> Note: for group-by queries, SRP should use "group counted" to calculate
> limits used for SRP query, rather than "row counted".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15833) Unresolvable false digest mismatch during upgrade due to CASSANDRA-10657
[ https://issues.apache.org/jira/browse/CASSANDRA-15833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156914#comment-17156914 ] Josh McKenzie commented on CASSANDRA-15833: --- Spoke w/Jordan and Jacek offline; this is ok to move to Beta phase. > Unresolvable false digest mismatch during upgrade due to CASSANDRA-10657 > > > Key: CASSANDRA-15833 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15833 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.11.x, 4.0-beta > > Attachments: CASSANDRA-15833-3.11.patch, CASSANDRA-15833-4.0.patch > > > CASSANDRA-10657 introduced changes in how the ColumnFilter is interpreted. > This results in digest mismatch when querying incomplete set of columns from > a table with consistency that requires reaching instances running pre > CASSANDRA-10657 from nodes that include CASSANDRA-10657 (it was introduced in > Cassandra 3.4). > The fix is to bring back the previous behaviour until there are no instances > running pre CASSANDRA-10657 version. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15833) Unresolvable false digest mismatch during upgrade due to CASSANDRA-10657
[ https://issues.apache.org/jira/browse/CASSANDRA-15833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-15833: -- Fix Version/s: (was: 4.0-alpha) 4.0-beta > Unresolvable false digest mismatch during upgrade due to CASSANDRA-10657 > > > Key: CASSANDRA-15833 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15833 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.11.x, 4.0-beta > > Attachments: CASSANDRA-15833-3.11.patch, CASSANDRA-15833-4.0.patch > > > CASSANDRA-10657 introduced changes in how the ColumnFilter is interpreted. > This results in digest mismatch when querying incomplete set of columns from > a table with consistency that requires reaching instances running pre > CASSANDRA-10657 from nodes that include CASSANDRA-10657 (it was introduced in > Cassandra 3.4). > The fix is to bring back the previous behaviour until there are no instances > running pre CASSANDRA-10657 version. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15579) 4.0 quality testing: Distributed Read/Write Path: Coordination, Replication, and Read Repair
[ https://issues.apache.org/jira/browse/CASSANDRA-15579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-15579: Reviewers: Caleb Rackliffe > 4.0 quality testing: Distributed Read/Write Path: Coordination, Replication, > and Read Repair > > > Key: CASSANDRA-15579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15579 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.0-beta > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Blake Eggleston* > Testing in this area focuses on non-node-local aspects of the read-write > path: coordination, replication, read repair, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152248#comment-17152248
]
Caleb Rackliffe edited comment on CASSANDRA-15907 at 7/13/20, 6:11 PM:
---
[~jwest] I've hopefully addressed the points from [~adelapena]'s first round of
review, so I think this is officially ready for a second reviewer.
3.0: [patch|https://github.com/apache/cassandra/pull/659],
[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/48/workflows/576994bd-0e65-4786-816f-6dfa58c9b0af]
WIP (avoid review ATM)
3.11: [patch|https://github.com/apache/cassandra/pull/665],
[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/38/workflows/c3a3b51b-d105-49d9-91f8-2a149cf211b6]
trunk: [patch|https://github.com/apache/cassandra/pull/666], [j8
CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/37/workflows/84e48d9e-f3dd-45ff-b70a-b69a86f6eb96]
[j11 Circle
CI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/37/workflows/79b581ab-94a1-4920-a894-7f0f91ef466b]
If we're happy with the implementation, the next step will be to do some basic
stress testing.
Note: Existing issues described by CASSANDRA-14595 (Thrift dtest) and
CASSANDRA-15881 (SASI memtable switching) are visible in the test results so
far.
was (Author: maedhroz):
[~jwest] I've hopefully addressed the points from [~adelapena]'s first round of
review, so I think this is officially ready for a second reviewer.
3.0: [patch|https://github.com/apache/cassandra/pull/659],
[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/48/workflows/576994bd-0e65-4786-816f-6dfa58c9b0af]
3.11: [patch|https://github.com/apache/cassandra/pull/665],
[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/38/workflows/c3a3b51b-d105-49d9-91f8-2a149cf211b6]
trunk: [patch|https://github.com/apache/cassandra/pull/666], [j8
CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/37/workflows/84e48d9e-f3dd-45ff-b70a-b69a86f6eb96]
[j11 Circle
CI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/37/workflows/79b581ab-94a1-4920-a894-7f0f91ef466b]
If we're happy with the implementation, the next step will be to do some basic
stress testing.
Note: Existing issues described by CASSANDRA-14595 (Thrift dtest) and
CASSANDRA-15881 (SASI memtable switching) are visible in the test results so
far.
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves again
[jira] [Comment Edited] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152248#comment-17152248
]
Caleb Rackliffe edited comment on CASSANDRA-15907 at 7/13/20, 6:10 PM:
---
[~jwest] I've hopefully addressed the points from [~adelapena]'s first round of
review, so I think this is officially ready for a second reviewer.
3.0: [patch|https://github.com/apache/cassandra/pull/659],
[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/48/workflows/576994bd-0e65-4786-816f-6dfa58c9b0af]
3.11: [patch|https://github.com/apache/cassandra/pull/665],
[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/38/workflows/c3a3b51b-d105-49d9-91f8-2a149cf211b6]
trunk: [patch|https://github.com/apache/cassandra/pull/666], [j8
CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/37/workflows/84e48d9e-f3dd-45ff-b70a-b69a86f6eb96]
[j11 Circle
CI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/37/workflows/79b581ab-94a1-4920-a894-7f0f91ef466b]
If we're happy with the implementation, the next step will be to do some basic
stress testing.
Note: Existing issues described by CASSANDRA-14595 (Thrift dtest) and
CASSANDRA-15881 (SASI memtable switching) are visible in the test results so
far.
was (Author: maedhroz):
[~jwest] I've hopefully addressed the points from [~adelapena]'s first round of
review, so I think this is officially ready for a second reviewer.
3.0: [patch|https://github.com/apache/cassandra/pull/659],
[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/39/workflows/a8187516-e0cd-4e06-b017-6e2e00fcfe3f]
3.11: [patch|https://github.com/apache/cassandra/pull/665],
[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/38/workflows/c3a3b51b-d105-49d9-91f8-2a149cf211b6]
trunk: [patch|https://github.com/apache/cassandra/pull/666], [j8
CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/37/workflows/84e48d9e-f3dd-45ff-b70a-b69a86f6eb96]
[j11 Circle
CI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/37/workflows/79b581ab-94a1-4920-a894-7f0f91ef466b]
If we're happy with the implementation, the next step will be to do some basic
stress testing.
Note: Existing issues described by CASSANDRA-14595 (Thrift dtest) and
CASSANDRA-15881 (SASI memtable switching) are visible in the test results so
far.
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
>
[jira] [Commented] (CASSANDRA-15928) Throw FSWriteError upon write failures in order to apply DiskFailurePolicy
[
https://issues.apache.org/jira/browse/CASSANDRA-15928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156866#comment-17156866
]
Yifan Cai commented on CASSANDRA-15928:
---
PR: [https://github.com/apache/cassandra/pull/677]
Code:
[https://github.com/yifan-c/cassandra/tree/CASSANDRA-15928-fserror-handling]
Test:
[https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=CASSANDRA-15928-fserror-handling]
Briefly, the patch re-throws {{IOException}} as {{FSWriteError}} when
applicable in the locations mentioned in the ticket.
> Throw FSWriteError upon write failures in order to apply DiskFailurePolicy
> --
>
> Key: CASSANDRA-15928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15928
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Attachments: intellij_custom_insepction.xml
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Active handling of FSError in AbstractLocalAwareExecutorService was
> introduced in CASSANDRA-14993.
>
> However, in the current code base, there are places that catch the
> IOException but not wrap it with FSError, hence not triggering the
> DiskFailurePolicy. Especially when the bad disk no longer permits write
> operations, it could leads to the mutation stage backup. Therefore I propose
> to fix the IOException handling in those cases.
>
> From the code inspection, those 6 places are current not re-throwing an
> IOException with FSWriteError.
> # org.apache.cassandra.triggers.CustomClassLoader#addClassPath throws
> IOError. Invoked in TriggerExecutor's constructor
> # org.apache.cassandra.io.util.FileUtils#renameWithConfirm throws
> RuntimeException
> # org.apache.cassandra.io.util.FileUtils#truncate throws RuntimeException
> # org.apache.cassandra.io.util.FileUtils#write throws RuntimeException
> # org.apache.cassandra.db.compaction.LeveledManifest#sendBackToL0 throws
> RuntimeException. Invokes rewriteSSTableMetadata
> # org.apache.cassandra.io.sstable.SSTableHeaderFix#writeNewMetadata throws
> RuntimeException. Invokes rewriteSSTableMetadata
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15928) Throw FSWriteError upon write failures in order to apply DiskFailurePolicy
[ https://issues.apache.org/jira/browse/CASSANDRA-15928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-15928: -- Bug Category: Parent values: Degradation(12984)Level 1 values: Resource Management(12995) Complexity: Low Hanging Fruit Discovered By: Code Inspection Severity: Low Status: Open (was: Triage Needed) > Throw FSWriteError upon write failures in order to apply DiskFailurePolicy > -- > > Key: CASSANDRA-15928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15928 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Attachments: intellij_custom_insepction.xml > > Time Spent: 10m > Remaining Estimate: 0h > > Active handling of FSError in AbstractLocalAwareExecutorService was > introduced in CASSANDRA-14993. > > However, in the current code base, there are places that catch the > IOException but not wrap it with FSError, hence not triggering the > DiskFailurePolicy. Especially when the bad disk no longer permits write > operations, it could leads to the mutation stage backup. Therefore I propose > to fix the IOException handling in those cases. > > From the code inspection, those 6 places are current not re-throwing an > IOException with FSWriteError. > # org.apache.cassandra.triggers.CustomClassLoader#addClassPath throws > IOError. Invoked in TriggerExecutor's constructor > # org.apache.cassandra.io.util.FileUtils#renameWithConfirm throws > RuntimeException > # org.apache.cassandra.io.util.FileUtils#truncate throws RuntimeException > # org.apache.cassandra.io.util.FileUtils#write throws RuntimeException > # org.apache.cassandra.db.compaction.LeveledManifest#sendBackToL0 throws > RuntimeException. Invokes rewriteSSTableMetadata > # org.apache.cassandra.io.sstable.SSTableHeaderFix#writeNewMetadata throws > RuntimeException. Invokes rewriteSSTableMetadata -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15939) Remove previously deprecated HintedHandoffManager
[
https://issues.apache.org/jira/browse/CASSANDRA-15939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated CASSANDRA-15939:
-
Fix Version/s: 4.0-beta
> Remove previously deprecated HintedHandoffManager
> -
>
> Key: CASSANDRA-15939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15939
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
> Fix For: 4.0-beta
>
>
> {{HintedHandOffManager}} was deprecated about 6 years ago:
> https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b
> with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and
> examining the published JMX elements it seemed sensible to remove this MBean
> to help clean up a bit as it appears to just be a proxy to the
> {{HintService}} at this point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15939) Remove previously deprecated HintedHandoffManager
Stephen Mallette created CASSANDRA-15939:
Summary: Remove previously deprecated HintedHandoffManager
Key: CASSANDRA-15939
URL: https://issues.apache.org/jira/browse/CASSANDRA-15939
Project: Cassandra
Issue Type: Improvement
Components: Consistency/Hints
Reporter: Stephen Mallette
Assignee: Stephen Mallette
{{HintedHandOffManager}} was deprecated about 6 years ago:
https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b
with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and
examining the published JMX elements it seemed sensible to remove this MBean to
help clean up a bit as it appears to just be a proxy to the {{HintService}} at
this point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15938) Fix support for adding UDT fields to clustering keys
Alex Petrov created CASSANDRA-15938: --- Summary: Fix support for adding UDT fields to clustering keys Key: CASSANDRA-15938 URL: https://issues.apache.org/jira/browse/CASSANDRA-15938 Project: Cassandra Issue Type: Bug Reporter: Alex Petrov Assignee: Alex Petrov Adding UDT fields to clustering keys is broken in all versions, however slightly differently. In 4.0, there will be a brief moment while schema changes are propagated during which we won’t be able to decode and compare byte sequences. Unfortunately, it is unclear what we should do in such cases, since we can’t just come up with a comparator, and we can’t ignore non-null trailing values, since this will lead to cases where compare for tuples `a;1` and `a;2` would return 0, effectively making them equal, and we don’t know how to compare unknown trailing values. Probably we should reject such query since we can’t sort correctly, but we should make the error message more descriptive than just "Index 1 out of bounds for length 1”. The only problem is that we get this exception only on flush right now, so data already propagates to the node by that time. In 3.0, the problem is a bit worse than that, since in 3.0 we do not ignore trailing nulls, so some of the values, written before `ALTER TYPE .. ADD` become inaccessible. Both old values, and the new ones should always be accessible. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] branch master updated (327c598 -> 7e1e250)
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git. from 327c598 make SimpleQueryResult a container for client warnings, and expose those warnings via QueryResult add a9f30a3 [maven-release-plugin] prepare release 0.0.4 add b481c85 [maven-release-plugin] prepare for next development iteration add 7e1e250 Add entries for 0.0.4 to the changelog No new revisions were added by this update. Summary of changes: CHANGES.txt | 4 pom.xml | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15876) Accessors for SystemProperties
[ https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15876: --- Reviewers: Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever) Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever) Status: Review In Progress (was: Patch Available) > Accessors for SystemProperties > -- > > Key: CASSANDRA-15876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15876 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0, 4.0-beta > > > As part of CASSANDRA-15234, it was suggested a class of accessors for System > properties to be created for better clarity and maintainability. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15876) Accessors for SystemProperties
[ https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156590#comment-17156590 ] Michael Semb Wever commented on CASSANDRA-15876: ci-cassandra devbranch run [here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/207/] A few small comments on the GH commit page. Otherwise it's +1 from me. > Accessors for SystemProperties > -- > > Key: CASSANDRA-15876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15876 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0, 4.0-beta > > > As part of CASSANDRA-15234, it was suggested a class of accessors for System > properties to be created for better clarity and maintainability. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15583) 4.0 quality testing: Tooling, Bundled and First Party
[ https://issues.apache.org/jira/browse/CASSANDRA-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15583: Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > 4.0 quality testing: Tooling, Bundled and First Party > - > > Key: CASSANDRA-15583 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15583 > Project: Cassandra > Issue Type: Epic > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Sam Tunnicliffe* > Test plans should cover bundled first-party tooling and CLIs such as > nodetool, cqlsh, and new tools supporting full query and audit logging > (CASSANDRA-13983, CASSANDRA-12151). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15583) 4.0 quality testing: Tooling, Bundled and First Party
[ https://issues.apache.org/jira/browse/CASSANDRA-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15583: Status: Triage Needed (was: Awaiting Feedback) > 4.0 quality testing: Tooling, Bundled and First Party > - > > Key: CASSANDRA-15583 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15583 > Project: Cassandra > Issue Type: Epic > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Sam Tunnicliffe* > Test plans should cover bundled first-party tooling and CLIs such as > nodetool, cqlsh, and new tools supporting full query and audit logging > (CASSANDRA-13983, CASSANDRA-12151). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15583) 4.0 quality testing: Tooling, Bundled and First Party
[ https://issues.apache.org/jira/browse/CASSANDRA-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156583#comment-17156583 ] Berenguer Blasi commented on CASSANDRA-15583: - Here is what I have in mind so far. I will create a 'main' feature branch where I'll merge the smaller tickets/steps I complete into. Once that main feature branch has sthg sensible we can merge it into trunk and proceed normally A. Start with 1 nodetool cmd as a POC against CQLTester. E2E testing both client and server side B. If POC is good extend to the few most 'representative/complex' nodetool cmds to make sure what we have covers the needs C. Visit the other tools in a width first based approach to extract a common base class or small lib to test tooling easily D. Add tests to uncovered parts Hope it makes sense. > 4.0 quality testing: Tooling, Bundled and First Party > - > > Key: CASSANDRA-15583 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15583 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Sam Tunnicliffe* > Test plans should cover bundled first-party tooling and CLIs such as > nodetool, cqlsh, and new tools supporting full query and audit logging > (CASSANDRA-13983, CASSANDRA-12151). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15583) 4.0 quality testing: Tooling, Bundled and First Party
[ https://issues.apache.org/jira/browse/CASSANDRA-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15583: Issue Type: Epic (was: Task) > 4.0 quality testing: Tooling, Bundled and First Party > - > > Key: CASSANDRA-15583 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15583 > Project: Cassandra > Issue Type: Epic > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Sam Tunnicliffe* > Test plans should cover bundled first-party tooling and CLIs such as > nodetool, cqlsh, and new tools supporting full query and audit logging > (CASSANDRA-13983, CASSANDRA-12151). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15857) Frozen RawTuple is not annotated with frozen in the toString method
[
https://issues.apache.org/jira/browse/CASSANDRA-15857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156549#comment-17156549
]
Robert Stupp commented on CASSANDRA-15857:
--
Not really a typo, but there's no point in freezing a tuple, as there is no
unfrozen tuple. I.e. a {{frozen<>}} around a tuple doesn't add any value. So
dealing with an unfrozen tuple is meaningless IMO.
> Frozen RawTuple is not annotated with frozen in the toString method
> ---
>
> Key: CASSANDRA-15857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15857
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0, 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> All raw types (e.g. RawCollection, RawUT) that supports freezing wraps the
> type name with 'frozen<>' in the toString method, except RawTuple.
> Therefore, the RawTuple::toString output misses the frozen wrapper.
> Tuple is always frozen. However since CASSANDRA-15035, it throws when the
> inner tuple is not explicitly wrapped with frozen within a collection.
> The method, CQL3Type.Raw::toString, is referenced at multiple places in the
> source. For example, referenced in CreateTypeStatement.Raw and involved in
> CQLSSTableWriter. Another example is that it is called to produce the
> SchemaChange at several AlterSchemaStatement implementations.
> A test can prove that missing the frozen wrapper causes exception when
> building CQLSSTableWriter for user types defined like below. Note that the
> inner tuple is wrapped with frozen in the initial CQL statement.
> {code:java}
> CREATE TYPE ks.fooType ( f list>> )
> {code}
> {code:java}
> org.apache.cassandra.exceptions.InvalidRequestException: Non-frozen tuples
> are not allowed inside collections: list>
> at
> org.apache.cassandra.cql3.CQL3Type$Raw$RawCollection.throwNestedNonFrozenError(CQL3Type.java:710)
> at
> org.apache.cassandra.cql3.CQL3Type$Raw$RawCollection.prepare(CQL3Type.java:669)
> at
> org.apache.cassandra.cql3.CQL3Type$Raw$RawCollection.prepareInternal(CQL3Type.java:661)
> at
> org.apache.cassandra.schema.Types$RawBuilder$RawUDT.lambda$prepare$1(Types.java:341)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at
> org.apache.cassandra.schema.Types$RawBuilder$RawUDT.prepare(Types.java:342)
> at org.apache.cassandra.schema.Types$RawBuilder.build(Types.java:291)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.createTypes(CQLSSTableWriter.java:551)
> at
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.build(CQLSSTableWriter.java:527)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
