[jira] [Updated] (CASSANDRASC-28) Add Stream SSTable API to Sidecar to stream SSTable components through zero copy streaming
[ https://issues.apache.org/jira/browse/CASSANDRASC-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-28: Description: Create an API for streaming SSTable components using Vertx’s zero copy sendFile API https://github.com/apache/cassandra-sidecar/pull/20 was:Create an API for streaming SSTable components using Vertx’s zero copy sendFile API > Add Stream SSTable API to Sidecar to stream SSTable components through zero > copy streaming > -- > > Key: CASSANDRASC-28 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-28 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Create an API for streaming SSTable components using Vertx’s zero copy > sendFile API > https://github.com/apache/cassandra-sidecar/pull/20 -- 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] (CASSANDRASC-28) Add Stream SSTable API to Sidecar to stream SSTable components through zero copy streaming
[ https://issues.apache.org/jira/browse/CASSANDRASC-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-28: Change Category: Performance Complexity: Normal Reviewers: Dinesh Joshi, Yifan Cai Status: Open (was: Triage Needed) > Add Stream SSTable API to Sidecar to stream SSTable components through zero > copy streaming > -- > > Key: CASSANDRASC-28 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-28 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Create an API for streaming SSTable components using Vertx’s zero copy > sendFile API -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416967#comment-17416967 ] Tatu Saloranta commented on CASSANDRA-16851: Pop the champagne! Thank you again [~e.dimitrova] for getting this through; should eliminate possibility of those "busy work cve updates for jackson 2.9" popping up ever again. Plus I think there's some incremental performance work for JsonNode handling too in 2.10 and 2.11 if I remember correctly. > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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] (CASSANDRASC-28) Add Stream SSTable API to Sidecar to stream SSTable components through zero copy streaming
[ https://issues.apache.org/jira/browse/CASSANDRASC-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRASC-28: Description: Create an API for streaming SSTable components using Vertx’s zero copy sendFile API (was: We want to create an API for streaming SSTable components using Vertx’s zero copy sendFile API) > Add Stream SSTable API to Sidecar to stream SSTable components through zero > copy streaming > -- > > Key: CASSANDRASC-28 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-28 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Create an API for streaming SSTable components using Vertx’s zero copy > sendFile API -- 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-16968) Diff Job retry bug fixes in reading previous run's job parameters & marking the job status
[ https://issues.apache.org/jira/browse/CASSANDRA-16968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyothsna Konisa updated CASSANDRA-16968: Reviewers: Dinesh Joshi (was: Yifan Cai) > Diff Job retry bug fixes in reading previous run's job parameters & marking > the job status > -- > > Key: CASSANDRA-16968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16968 > Project: Cassandra > Issue Type: New Feature > Components: Tool/diff >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > Diff job retry with same jobId should avoid running diffs on the partitions > that were successfully diffed previously. The retry failed because previous > run failed to mark the job as not running on exit. This is due to a bug in > the resource try catch block where session object Is closed before marking > the job as not running. Also there is another bug in the way we get job > parameters during rerun of a failed diff job. -- 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-16968) Diff Job retry bug fixes in reading previous run's job parameters & marking the job status
[ https://issues.apache.org/jira/browse/CASSANDRA-16968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyothsna Konisa updated CASSANDRA-16968: Reviewers: Dinesh Joshi, Yifan Cai (was: Dinesh Joshi) > Diff Job retry bug fixes in reading previous run's job parameters & marking > the job status > -- > > Key: CASSANDRA-16968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16968 > Project: Cassandra > Issue Type: New Feature > Components: Tool/diff >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > Diff job retry with same jobId should avoid running diffs on the partitions > that were successfully diffed previously. The retry failed because previous > run failed to mark the job as not running on exit. This is due to a bug in > the resource try catch block where session object Is closed before marking > the job as not running. Also there is another bug in the way we get job > parameters during rerun of a failed diff job. -- 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-16968) Diff Job retry bug fixes in reading previous run's job parameters & marking the job status
[ https://issues.apache.org/jira/browse/CASSANDRA-16968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-16968: -- Reviewers: Yifan Cai Status: Review In Progress (was: Patch Available) > Diff Job retry bug fixes in reading previous run's job parameters & marking > the job status > -- > > Key: CASSANDRA-16968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16968 > Project: Cassandra > Issue Type: New Feature > Components: Tool/diff >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > Diff job retry with same jobId should avoid running diffs on the partitions > that were successfully diffed previously. The retry failed because previous > run failed to mark the job as not running on exit. This is due to a bug in > the resource try catch block where session object Is closed before marking > the job as not running. Also there is another bug in the way we get job > parameters during rerun of a failed diff job. -- 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-16968) Diff Job retry bug fixes in reading previous run's job parameters & marking the job status
[ https://issues.apache.org/jira/browse/CASSANDRA-16968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyothsna Konisa updated CASSANDRA-16968: Test and Documentation Plan: Unit tests have been added in this patch Status: Patch Available (was: Open) > Diff Job retry bug fixes in reading previous run's job parameters & marking > the job status > -- > > Key: CASSANDRA-16968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16968 > Project: Cassandra > Issue Type: New Feature > Components: Tool/diff >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > Diff job retry with same jobId should avoid running diffs on the partitions > that were successfully diffed previously. The retry failed because previous > run failed to mark the job as not running on exit. This is due to a bug in > the resource try catch block where session object Is closed before marking > the job as not running. Also there is another bug in the way we get job > parameters during rerun of a failed diff job. -- 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] (CASSANDRASC-28) Add Stream SSTable API to Sidecar to stream SSTable components through zero copy streaming
Saranya Krishnakumar created CASSANDRASC-28: --- Summary: Add Stream SSTable API to Sidecar to stream SSTable components through zero copy streaming Key: CASSANDRASC-28 URL: https://issues.apache.org/jira/browse/CASSANDRASC-28 Project: Sidecar for Apache Cassandra Issue Type: New Feature Components: Rest API Reporter: Saranya Krishnakumar Assignee: Saranya Krishnakumar We want to create an API for streaming SSTable components using Vertx’s zero copy sendFile API -- 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-16968) Diff Job retry bug fixes in reading previous run's job parameters & marking the job status
[ https://issues.apache.org/jira/browse/CASSANDRA-16968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16968: - Change Category: Operability Complexity: Normal Component/s: Tool/diff Status: Open (was: Triage Needed) > Diff Job retry bug fixes in reading previous run's job parameters & marking > the job status > -- > > Key: CASSANDRA-16968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16968 > Project: Cassandra > Issue Type: New Feature > Components: Tool/diff >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > Diff job retry with same jobId should avoid running diffs on the partitions > that were successfully diffed previously. The retry failed because previous > run failed to mark the job as not running on exit. This is due to a bug in > the resource try catch block where session object Is closed before marking > the job as not running. Also there is another bug in the way we get job > parameters during rerun of a failed diff job. -- 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-16968) Diff Job retry bug fixes in reading previous run's job parameters & marking the job status
[ https://issues.apache.org/jira/browse/CASSANDRA-16968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416948#comment-17416948 ] Jyothsna Konisa commented on CASSANDRA-16968: - [https://github.com/apache/cassandra-diff/pull/16] # The try resource block in DiffJob.java closes the session object before the code in exception or finally block gets executed. We are marking the job as not running in the exception block which throws an exception as the session object is already closed. Changing the resource try catch block to try catch finally block so that session object will not be closed until cleanup is complete. # When job_id is passed as a config property for the first time, we will not have metadata associated with job_id in metadata table but the current code attempts to get the job metadata for the passed jobId and as those details will not be present, a null pointer exception is thrown. This patch fixes this issue by getting jobParameters from the table only when they are available otherwise creates new job parameters with passed JobId or random UUID. > Diff Job retry bug fixes in reading previous run's job parameters & marking > the job status > -- > > Key: CASSANDRA-16968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16968 > Project: Cassandra > Issue Type: New Feature >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > Diff job retry with same jobId should avoid running diffs on the partitions > that were successfully diffed previously. The retry failed because previous > run failed to mark the job as not running on exit. This is due to a bug in > the resource try catch block where session object Is closed before marking > the job as not running. Also there is another bug in the way we get job > parameters during rerun of a failed diff job. -- 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] [Assigned] (CASSANDRA-16969) Scrub does not detect invalid partition keys
[ https://issues.apache.org/jira/browse/CASSANDRA-16969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-16969: Assignee: Brandon Williams > Scrub does not detect invalid partition keys > > > Key: CASSANDRA-16969 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16969 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.x, 4.0.x > > > The standalone scrubber [gets the > key|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/Scrubber.java#L202] > from the file but never validates it, and this will propagate to the new > sstable so it will be corrupted when read later. -- 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-16969) Scrub does not detect invalid partition keys
[ https://issues.apache.org/jira/browse/CASSANDRA-16969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416946#comment-17416946 ] Brandon Williams commented on CASSANDRA-16969: -- For now, [here|https://github.com/driftx/cassandra/tree/CASSANDRA-16969] is a branch against 3.11. > Scrub does not detect invalid partition keys > > > Key: CASSANDRA-16969 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16969 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: Brandon Williams >Priority: Normal > Fix For: 3.11.x, 4.0.x > > > The standalone scrubber [gets the > key|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/Scrubber.java#L202] > from the file but never validates it, and this will propagate to the new > sstable so it will be corrupted when read later. -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416943#comment-17416943 ] Ekaterina Dimitrova commented on CASSANDRA-16851: - Also, tickets opened for the flaky/failing tests: CASSANDRA-16970 - Fix org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition CASSANDRA-16971 - Fix org.apache.cassandra.distributed.test.OptimiseStreamsRepairTest.randomTest CASSANDRA-16973 - Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution CASSANDRA-16972 - Fix org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding CASSANDRA-16974 -Fix org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5] > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16974) Fix org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5]
[
https://issues.apache.org/jira/browse/CASSANDRA-16974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16974:
Fix Version/s: 4.x
> Fix
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5]
>
>
> Key: CASSANDRA-16974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16974
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5
> is
> [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/junit/org.apache.cassandra.distributed.test/UnableToParseClientMessageTest/badHeader_version_5_v5_/]
> on trunk
> {code:java}
> Error Message
> Expecting actual not to be empty
> Stacktrace
> junit.framework.AssertionFailedError:
> Expecting actual not to be empty
> at
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.test(UnableToParseClientMessageTest.java:158)
> at
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader(UnableToParseClientMessageTest.java:99)
> 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)
> {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
[jira] [Updated] (CASSANDRA-16974) Fix org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5]
[
https://issues.apache.org/jira/browse/CASSANDRA-16974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16974:
Summary: Fix
org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5]
(was: Fix )
> Fix
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5]
>
>
> Key: CASSANDRA-16974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16974
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5
> is
> [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/junit/org.apache.cassandra.distributed.test/UnableToParseClientMessageTest/badHeader_version_5_v5_/]
> on trunk
> {code:java}
> Error Message
> Expecting actual not to be empty
> Stacktrace
> junit.framework.AssertionFailedError:
> Expecting actual not to be empty
> at
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.test(UnableToParseClientMessageTest.java:158)
> at
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader(UnableToParseClientMessageTest.java:99)
> 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)
> {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
[jira] [Created] (CASSANDRA-16974) Fix
Ekaterina Dimitrova created CASSANDRA-16974:
---
Summary: Fix
Key: CASSANDRA-16974
URL: https://issues.apache.org/jira/browse/CASSANDRA-16974
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5
is
[failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/junit/org.apache.cassandra.distributed.test/UnableToParseClientMessageTest/badHeader_version_5_v5_/]
on trunk
{code:java}
Error Message
Expecting actual not to be empty
Stacktrace
junit.framework.AssertionFailedError:
Expecting actual not to be empty
at
org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.test(UnableToParseClientMessageTest.java:158)
at
org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader(UnableToParseClientMessageTest.java:99)
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)
{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
[jira] [Updated] (CASSANDRA-16974) Fix org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5]
[
https://issues.apache.org/jira/browse/CASSANDRA-16974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16974:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Test/dtest/java
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Fix
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5]
>
>
> Key: CASSANDRA-16974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16974
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5
> is
> [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/junit/org.apache.cassandra.distributed.test/UnableToParseClientMessageTest/badHeader_version_5_v5_/]
> on trunk
> {code:java}
> Error Message
> Expecting actual not to be empty
> Stacktrace
> junit.framework.AssertionFailedError:
> Expecting actual not to be empty
> at
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.test(UnableToParseClientMessageTest.java:158)
> at
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader(UnableToParseClientMessageTest.java:99)
> 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)
> {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
[jira] [Updated] (CASSANDRA-16972) Fix org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding
[
https://issues.apache.org/jira/browse/CASSANDRA-16972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16972:
Fix Version/s: 3.11.x
> Fix org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding
> -
>
> Key: CASSANDRA-16972
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16972
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.x
>
>
> [org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.cql3/ViewTest/testTruncateWhileBuilding/]
> fails in 3.11
>
> {code:java}
> Error Message
> expected:<0> but was:<1>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<0> but was:<1> at
> org.apache.cassandra.Util.spinAssertEquals(Util.java:575) at
> org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding(ViewTest.java:1656)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$9.evaluate(BMUnitRunner.java:342)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75)
> {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
[jira] [Updated] (CASSANDRA-16972) Fix org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding
[
https://issues.apache.org/jira/browse/CASSANDRA-16972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16972:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Test/unit
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Fix org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding
> -
>
> Key: CASSANDRA-16972
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16972
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> [org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.cql3/ViewTest/testTruncateWhileBuilding/]
> fails in 3.11
>
> {code:java}
> Error Message
> expected:<0> but was:<1>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<0> but was:<1> at
> org.apache.cassandra.Util.spinAssertEquals(Util.java:575) at
> org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding(ViewTest.java:1656)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$9.evaluate(BMUnitRunner.java:342)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75)
> {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
[jira] [Updated] (CASSANDRA-16973) Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
[
https://issues.apache.org/jira/browse/CASSANDRA-16973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16973:
Fix Version/s: 3.11.x
> Fix
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
>
>
> Key: CASSANDRA-16973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16973
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.x
>
>
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
> fails in
> [3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
> h3.
> {code:java}
> Stacktrace
> junit.framework.AssertionFailedError at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> Standard Output
> Completed 0K batches with 0.0M events Running for 120s with load multiplier
> 0.5
> Standard Error
> SLF4J: The following set of substitute loggers may have been accessed SLF4J:
> during the initialization phase. Logging calls during this SLF4J: phase were
> not honored. However, subsequent logging calls to these SLF4J: loggers will
> work as normally expected. SLF4J: See also
> http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.cassandra.LogbackStatusListener
> {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
[jira] [Updated] (CASSANDRA-16973) Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
[
https://issues.apache.org/jira/browse/CASSANDRA-16973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16973:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Test/unit
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Fix
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
>
>
> Key: CASSANDRA-16973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16973
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
> fails in
> [3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
> h3.
> {code:java}
> Stacktrace
> junit.framework.AssertionFailedError at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
> at
> org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
> Standard Output
> Completed 0K batches with 0.0M events Running for 120s with load multiplier
> 0.5
> Standard Error
> SLF4J: The following set of substitute loggers may have been accessed SLF4J:
> during the initialization phase. Logging calls during this SLF4J: phase were
> not honored. However, subsequent logging calls to these SLF4J: loggers will
> work as normally expected. SLF4J: See also
> http://www.slf4j.org/codes.html#substituteLogger
> SLF4J: org.apache.cassandra.LogbackStatusListener
> {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
[jira] [Created] (CASSANDRA-16973) Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
Ekaterina Dimitrova created CASSANDRA-16973:
---
Summary: Fix
org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
Key: CASSANDRA-16973
URL: https://issues.apache.org/jira/browse/CASSANDRA-16973
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
fails in
[3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
h3.
{code:java}
Stacktrace
junit.framework.AssertionFailedError at
org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169)
at
org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
Standard Output
Completed 0K batches with 0.0M events Running for 120s with load multiplier 0.5
Standard Error
SLF4J: The following set of substitute loggers may have been accessed SLF4J:
during the initialization phase. Logging calls during this SLF4J: phase were
not honored. However, subsequent logging calls to these SLF4J: loggers will
work as normally expected. SLF4J: See also
http://www.slf4j.org/codes.html#substituteLogger
SLF4J: org.apache.cassandra.LogbackStatusListener
{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
[jira] [Created] (CASSANDRA-16972) Fix org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding
Ekaterina Dimitrova created CASSANDRA-16972:
---
Summary: Fix
org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding
Key: CASSANDRA-16972
URL: https://issues.apache.org/jira/browse/CASSANDRA-16972
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
[org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.cql3/ViewTest/testTruncateWhileBuilding/]
fails in 3.11
{code:java}
Error Message
expected:<0> but was:<1>
Stacktrace
junit.framework.AssertionFailedError: expected:<0> but was:<1> at
org.apache.cassandra.Util.spinAssertEquals(Util.java:575) at
org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding(ViewTest.java:1656)
at
org.jboss.byteman.contrib.bmunit.BMUnitRunner$9.evaluate(BMUnitRunner.java:342)
at
org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241)
at
org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75)
{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
[jira] [Updated] (CASSANDRA-16971) Fix org.apache.cassandra.distributed.test.OptimiseStreamsRepairTest.randomTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16971:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Component/s: Test/dtest/java
Discovered By: User Report
Severity: Normal
Assignee: Ekaterina Dimitrova
Status: Open (was: Triage Needed)
> Fix org.apache.cassandra.distributed.test.OptimiseStreamsRepairTest.randomTest
> --
>
> Key: CASSANDRA-16971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16971
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> org.apache.cassandra.distributed.test.OptimiseStreamsRepairTest.randomTest is
> [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1120/testReport/junit/org.apache.cassandra.distributed.test/OptimiseStreamsRepairTest/randomTest/]
> on 4.0
> h3.
> {code:java}
> Error Message
> nodetool command [repair, distributed_test_keyspace, -vd] was not successful
> stdout: [2021-09-15 16:45:34,539] Starting repair command #2
> (58d1e2a0-1644-11ec-8c42-ef15a225544a), repairing keyspace
> distributed_test_keyspace with repair options (parallelism: parallel, primary
> range: false, incremental: true, job threads: 1, ColumnFamilies: [],
> dataCenters: [], hosts: [], previewKind: REPAIRED, # of ranges: 3, pull
> repair: false, force repair: false, optimise streams: false, ignore
> unreplicated keyspaces: false) [2021-09-15 16:45:34,552] Repair command #2
> failed with error Repair session 58d2cd00-1644-11ec-8c42-ef15a225544a for
> range [(-3074457345618258603,3074457345618258601],
> (9223372036854775805,-3074457345618258603],
> (3074457345618258601,9223372036854775805]] failed with error An incremental
> repair with session id 560ecb00-1644-11ec-8c42-ef15a225544a finished during
> this preview repair runtime [2021-09-15 16:45:34,552] Repair command #2
> finished with error
> {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
[jira] [Created] (CASSANDRA-16971) Fix org.apache.cassandra.distributed.test.OptimiseStreamsRepairTest.randomTest
Ekaterina Dimitrova created CASSANDRA-16971:
---
Summary: Fix
org.apache.cassandra.distributed.test.OptimiseStreamsRepairTest.randomTest
Key: CASSANDRA-16971
URL: https://issues.apache.org/jira/browse/CASSANDRA-16971
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
org.apache.cassandra.distributed.test.OptimiseStreamsRepairTest.randomTest is
[failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1120/testReport/junit/org.apache.cassandra.distributed.test/OptimiseStreamsRepairTest/randomTest/]
on 4.0
h3.
{code:java}
Error Message
nodetool command [repair, distributed_test_keyspace, -vd] was not successful
stdout: [2021-09-15 16:45:34,539] Starting repair command #2
(58d1e2a0-1644-11ec-8c42-ef15a225544a), repairing keyspace
distributed_test_keyspace with repair options (parallelism: parallel, primary
range: false, incremental: true, job threads: 1, ColumnFamilies: [],
dataCenters: [], hosts: [], previewKind: REPAIRED, # of ranges: 3, pull repair:
false, force repair: false, optimise streams: false, ignore unreplicated
keyspaces: false) [2021-09-15 16:45:34,552] Repair command #2 failed with error
Repair session 58d2cd00-1644-11ec-8c42-ef15a225544a for range
[(-3074457345618258603,3074457345618258601],
(9223372036854775805,-3074457345618258603],
(3074457345618258601,9223372036854775805]] failed with error An incremental
repair with session id 560ecb00-1644-11ec-8c42-ef15a225544a finished during
this preview repair runtime [2021-09-15 16:45:34,552] Repair command #2
finished with error
{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
[jira] [Updated] (CASSANDRA-16970) Fix org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
[
https://issues.apache.org/jira/browse/CASSANDRA-16970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16970:
Fix Version/s: 4.x
> Fix
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
> -
>
> Key: CASSANDRA-16970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16970
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
> is
> [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/org.apache.cassandra.distributed.test/ClientTombstoneWarningTest/failThresholdSinglePartition_2/]
> {code:java}
> Error Message
> expected:<0.1=1, /127.0.0.2=1[, /127.0.0.3=1]}> but was:<0.1=1,
> /127.0.0.2=1[]}>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<0.1=1, /127.0.0.2=1[,
> /127.0.0.3=1]}> but was:<0.1=1, /127.0.0.2=1[]}>
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThreshold(ClientTombstoneWarningTest.java:227)
> at
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition(ClientTombstoneWarningTest.java:180)
> 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){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
[jira] [Created] (CASSANDRA-16970) Fix org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
Ekaterina Dimitrova created CASSANDRA-16970:
---
Summary: Fix
org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
Key: CASSANDRA-16970
URL: https://issues.apache.org/jira/browse/CASSANDRA-16970
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
is
[failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/org.apache.cassandra.distributed.test/ClientTombstoneWarningTest/failThresholdSinglePartition_2/]
{code:java}
Error Message
expected:<0.1=1, /127.0.0.2=1[, /127.0.0.3=1]}> but was:<0.1=1,
/127.0.0.2=1[]}>
Stacktrace
junit.framework.AssertionFailedError: expected:<0.1=1, /127.0.0.2=1[,
/127.0.0.3=1]}> but was:<0.1=1, /127.0.0.2=1[]}>
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThreshold(ClientTombstoneWarningTest.java:227)
at
org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition(ClientTombstoneWarningTest.java:180)
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){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
[jira] [Updated] (CASSANDRA-16970) Fix org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
[
https://issues.apache.org/jira/browse/CASSANDRA-16970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16970:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Test/dtest/java
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Fix
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
> -
>
> Key: CASSANDRA-16970
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16970
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
> is
> [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/org.apache.cassandra.distributed.test/ClientTombstoneWarningTest/failThresholdSinglePartition_2/]
> {code:java}
> Error Message
> expected:<0.1=1, /127.0.0.2=1[, /127.0.0.3=1]}> but was:<0.1=1,
> /127.0.0.2=1[]}>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<0.1=1, /127.0.0.2=1[,
> /127.0.0.3=1]}> but was:<0.1=1, /127.0.0.2=1[]}>
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThreshold(ClientTombstoneWarningTest.java:227)
> at
> org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition(ClientTombstoneWarningTest.java:180)
> 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){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
[jira] [Updated] (CASSANDRA-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16851: Source Control Link: https://github.com/apache/cassandra/commit/e4d2802276a2ebfc2e3b7b0471cebf8affc8 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416935#comment-17416935 ] Ekaterina Dimitrova commented on CASSANDRA-16851: - Committed, thank you To https://github.com/apache/cassandra.git b3af67f0ee..e4d2802276 cassandra-3.11 -> cassandra-3.11 dd3d83a819..14af149ed5 cassandra-4.0 -> cassandra-4.0 7faff38826..7c3935ced3 trunk -> trunk > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- 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] branch cassandra-4.0 updated (dd3d83a -> 14af149)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from dd3d83a Upgrade Caffeine to 2.5.6 add e4d2802 Update Jackson from 2.9.10 to 2.12.5 patch by Tatu Saloranta; reviewed by Ekaterina Dimitrova, Brandon Williams, Michael Semb Wever for CASSANDRA-16851 add 14af149 Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + build.xml| 6 +++--- src/java/org/apache/cassandra/cql3/Json.java | 1 + 3 files changed, 5 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (7faff38 -> 7c3935c)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 7faff38 Upgrade Caffeiene to 2.9.2 add e4d2802 Update Jackson from 2.9.10 to 2.12.5 patch by Tatu Saloranta; reviewed by Ekaterina Dimitrova, Brandon Williams, Michael Semb Wever for CASSANDRA-16851 add 14af149 Merge branch 'cassandra-3.11' into cassandra-4.0 new 7c3935c Merge branch 'cassandra-4.0' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 1 + build.xml| 8 src/java/org/apache/cassandra/cql3/Json.java | 1 + 3 files changed, 6 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 7c3935ced35f6541dc1d8950b3e001fad8d7c17f Merge: 7faff38 14af149 Author: Ekaterina Dimitrova AuthorDate: Fri Sep 17 17:27:44 2021 -0400 Merge branch 'cassandra-4.0' into trunk CHANGES.txt | 1 + build.xml| 8 src/java/org/apache/cassandra/cql3/Json.java | 1 + 3 files changed, 6 insertions(+), 4 deletions(-) diff --cc CHANGES.txt index d72ac0a,109cff7..3c470f7 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,39 -1,14 +1,40 @@@ -4.0.2 - * Upgrade Caffeine to 2.5.6 (CASSANDRA-15153) +4.1 + * Upgrade Caffeine to 2.9.2 (CASSANDRA-15153) + * Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it (CASSANDRA-16806) * Include SASI components to snapshots (CASSANDRA-15134) * Fix missed wait latencies in the output of `nodetool tpstats -F` (CASSANDRA-16938) + * Reduce native transport max frame size to 16MB (CASSANDRA-16886) + * Add support for filtering using IN restrictions (CASSANDRA-14344) + * Provide a nodetool command to invalidate auth caches (CASSANDRA-16404) + * Catch read repair timeout exceptions and add metric (CASSANDRA-16880) + * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies (CASSANDRA-16854) + * Add client warnings and abort to tombstone and coordinator reads which go past a low/high watermark (CASSANDRA-16850) + * Add TTL support to nodetool snapshots (CASSANDRA-16789) + * Allow CommitLogSegmentReader to optionally skip sync marker CRC checks (CASSANDRA-16842) + * allow blocking IPs from updating metrics about traffic (CASSANDRA-16859) + * Request-Based Native Transport Rate-Limiting (CASSANDRA-16663) + * Implement nodetool getauditlog command (CASSANDRA-16725) + * Clean up repair code (CASSANDRA-13720) + * Background schedule to clean up orphaned hints files (CASSANDRA-16815) + * Modify SecondaryIndexManager#indexPartition() to retrieve only columns for which indexes are actually being built (CASSANDRA-16776) + * Batch the token metadata update to improve the speed (CASSANDRA-15291) + * Reduce the log level on "expected" repair exceptions (CASSANDRA-16775) + * Make JMXTimer expose attributes using consistent time unit (CASSANDRA-16760) + * Remove check on gossip status from DynamicEndpointSnitch::updateScores (CASSANDRA-11671) + * Fix AbstractReadQuery::toCQLString not returning valid CQL (CASSANDRA-16510) + * Log when compacting many tombstones (CASSANDRA-16780) + * Display bytes per level in tablestats for LCS tables (CASSANDRA-16799) + * Add isolated flush timer to CommitLogMetrics and ensure writes correspond to single WaitingOnCommit data points (CASSANDRA-16701) + * Add a system property to set hostId if not yet initialized (CASSANDRA-14582) + * GossiperTest.testHasVersion3Nodes didn't take into account trunk version changes, fixed to rely on latest version (CASSANDRA-16651) +Merged from 4.0: * Remove all the state pollution between tests in SSTableReaderTest (CASSANDRA-16888) * Delay auth setup until after gossip has settled to avoid unavailables on startup (CASSANDRA-16783) - * Fix clustering order logic in CREATE MATERIALIZED VIEW (CASSANDRA-16898) * org.apache.cassandra.db.rows.ArrayCell#unsharedHeapSizeExcludingData includes data twice (CASSANDRA-16900) + * Fix clustering order logic in CREATE MATERIALIZED VIEW (CASSANDRA-16898) * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies (CASSANDRA-16854) Merged from 3.11: + * Update Jackson from 2.9.10 to 2.12.5 (CASSANDRA-16851) * Make assassinate more resilient to missing tokens (CASSANDRA-16847) Merged from 3.0: * Make the addition of regular column to COMPACT tables throw an InvalidRequestException (CASSANDRA-14564) diff --cc build.xml index 0398da2,f519547..32eba7c --- a/build.xml +++ b/build.xml @@@ -516,10 -516,9 +516,10 @@@ - - - - + + + ++ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (b3af67f -> e4d2802)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from b3af67f Add test to ensure Caffeine cache does not return stale entries add e4d2802 Update Jackson from 2.9.10 to 2.12.5 patch by Tatu Saloranta; reviewed by Ekaterina Dimitrova, Brandon Williams, Michael Semb Wever for CASSANDRA-16851 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + build.xml | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16969) Scrub does not detect invalid partition keys
[ https://issues.apache.org/jira/browse/CASSANDRA-16969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16969: - Bug Category: Parent values: Degradation(12984) Complexity: Normal Discovered By: User Report Fix Version/s: 4.0.x 3.11.x Severity: Normal Status: Open (was: Triage Needed) > Scrub does not detect invalid partition keys > > > Key: CASSANDRA-16969 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16969 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: Brandon Williams >Priority: Normal > Fix For: 3.11.x, 4.0.x > > > The standalone scrubber [gets the > key|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/Scrubber.java#L202] > from the file but never validates it, and this will propagate to the new > sstable so it will be corrupted when read later. -- 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-16969) Scrub does not detect invalid partition keys
[ https://issues.apache.org/jira/browse/CASSANDRA-16969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16969: - Summary: Scrub does not detect invalid partition keys (was: Scrub does detect invalid partition keys) > Scrub does not detect invalid partition keys > > > Key: CASSANDRA-16969 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16969 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: Brandon Williams >Priority: Normal > > The standalone scrubber [gets the > key|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/Scrubber.java#L202] > from the file but never validates it, and this will propagate to the new > sstable so it will be corrupted when read later. -- 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-16969) Scrub does detect invalid partition keys
Brandon Williams created CASSANDRA-16969: Summary: Scrub does detect invalid partition keys Key: CASSANDRA-16969 URL: https://issues.apache.org/jira/browse/CASSANDRA-16969 Project: Cassandra Issue Type: Bug Components: Tool/sstable Reporter: Brandon Williams The standalone scrubber [gets the key|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/Scrubber.java#L202] from the file but never validates it, and this will propagate to the new sstable so it will be corrupted when read later. -- 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-15153) Ensure Caffeine cache does not return stale entries
[ https://issues.apache.org/jira/browse/CASSANDRA-15153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416878#comment-17416878 ] Brandon Williams commented on CASSANDRA-15153: -- Thanks [~ben.manes]. Luckily the impact here remained only theoretical, but we'll try to do a better job of keeping up in the future. > Ensure Caffeine cache does not return stale entries > --- > > Key: CASSANDRA-15153 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15153 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Per Otterström >Assignee: Aleksei Zotov >Priority: Normal > Labels: security > Fix For: 4.0.2, 4.1 > > > Version 2.3.5 of the Caffeine cache that we're using in various places can > hand out stale entries in some cases. This seem to happen when an update > fails repeatedly, in which case Caffeine may return a previously loaded > value. For instance, the AuthCache may hand out permissions even though the > reload operation is failing, see CASSANDRA-15041. -- 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-15153) Ensure Caffeine cache does not return stale entries
[ https://issues.apache.org/jira/browse/CASSANDRA-15153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416868#comment-17416868 ] Ben Manes commented on CASSANDRA-15153: --- Sorry for the bug here. There are so many moving parts that I probably confused myself when writing that original and obviously bad code.. I'll review the test cases to make sure that this metadata is covered and not just fixed. Please do try to keep updated to recent versions for bug fixes. > Ensure Caffeine cache does not return stale entries > --- > > Key: CASSANDRA-15153 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15153 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Per Otterström >Assignee: Aleksei Zotov >Priority: Normal > Labels: security > Fix For: 4.0.2, 4.1 > > > Version 2.3.5 of the Caffeine cache that we're using in various places can > hand out stale entries in some cases. This seem to happen when an update > fails repeatedly, in which case Caffeine may return a previously loaded > value. For instance, the AuthCache may hand out permissions even though the > reload operation is failing, see CASSANDRA-15041. -- 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-16926) Mockable FileSystem
[ https://issues.apache.org/jira/browse/CASSANDRA-16926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16926: Test and Documentation Plan: new and existing utests & dtests Status: Patch Available (was: Open) [16926-trunk|https://github.com/beobal/cassandra/tree/16926-trunk] > Mockable FileSystem > --- > > Key: CASSANDRA-16926 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16926 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > To support CEP-10 it is necessary to support alternative file system > implementations so that execution may be consistent between hosts. This > ticket introduces a new File API backed by Path objects, and all File usages > are ported to it. This necessitates the migration away from > RandomAccessReader, but otherwise the change is mostly straight-forward, if > quite expansive. -- 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-16926) Mockable FileSystem
[ https://issues.apache.org/jira/browse/CASSANDRA-16926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16926: Change Category: Quality Assurance Complexity: Normal Component/s: Legacy/Core Reviewers: Aleksey Yeschenko, Sam Tunnicliffe Assignee: Benedict Elliott Smith Status: Open (was: Triage Needed) > Mockable FileSystem > --- > > Key: CASSANDRA-16926 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16926 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > To support CEP-10 it is necessary to support alternative file system > implementations so that execution may be consistent between hosts. This > ticket introduces a new File API backed by Path objects, and all File usages > are ported to it. This necessitates the migration away from > RandomAccessReader, but otherwise the change is mostly straight-forward, if > quite expansive. -- 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-16925) Task Execution
[ https://issues.apache.org/jira/browse/CASSANDRA-16925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16925: Test and Documentation Plan: new and existing utests & dtests Status: Patch Available (was: Open) [16925-trunk|https://github.com/beobal/cassandra/tree/16925-trunk] > Task Execution > -- > > Key: CASSANDRA-16925 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16925 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > To support CEP-10 it is necessary to support alternative executor > implementations that may be externally controlled. This ticket introduces an > ExecutorFactory, and all executor creation is migrated to this facility. The > codebase’s use of executors is inconsistent, and relatedly there are > divergent Future APIs in use, with Netty, Guava and Java APIs in use in > various places. To improve consistency we introduce our own Future API that > implements all of the above, as well as providing other additional ergonomic > improvements. We introduce a new ExecutorPlus API that extends Executor to > supply this extended Future API. All executors and futures are ported to > these new APIs to improve coherency in the codebase, and to support > consistently mocking these implementations. > DebuggableThreadPoolExecutor and its hierarchy is replaced with > ThreadPoolExecutorBase, ThreadPoolExecutorPlus and extending classes with > consistent names, implementations and configurability. > Additionally the ExecutorFactory takes over the allocation of new threads, > and provides a new InfiniteLoopExecutorfacility for common paradigms. -- 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-16925) Task Execution
[ https://issues.apache.org/jira/browse/CASSANDRA-16925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16925: Change Category: Quality Assurance Complexity: Normal Component/s: Legacy/Core Reviewers: Sam Tunnicliffe Assignee: Benedict Elliott Smith Status: Open (was: Triage Needed) > Task Execution > -- > > Key: CASSANDRA-16925 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16925 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > To support CEP-10 it is necessary to support alternative executor > implementations that may be externally controlled. This ticket introduces an > ExecutorFactory, and all executor creation is migrated to this facility. The > codebase’s use of executors is inconsistent, and relatedly there are > divergent Future APIs in use, with Netty, Guava and Java APIs in use in > various places. To improve consistency we introduce our own Future API that > implements all of the above, as well as providing other additional ergonomic > improvements. We introduce a new ExecutorPlus API that extends Executor to > supply this extended Future API. All executors and futures are ported to > these new APIs to improve coherency in the codebase, and to support > consistently mocking these implementations. > DebuggableThreadPoolExecutor and its hierarchy is replaced with > ThreadPoolExecutorBase, ThreadPoolExecutorPlus and extending classes with > consistent names, implementations and configurability. > Additionally the ExecutorFactory takes over the allocation of new threads, > and provides a new InfiniteLoopExecutorfacility for common paradigms. -- 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-16924) Blocking Concurrency Primitives
[ https://issues.apache.org/jira/browse/CASSANDRA-16924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16924: Test and Documentation Plan: new and existing utests/dtests Status: Patch Available (was: Open) [16924-trunk|https://github.com/beobal/cassandra/tree/16924-trunk] > Blocking Concurrency Primitives > --- > > Key: CASSANDRA-16924 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16924 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > To support CEP-10 it is necessary to support alternative implementations of > the blocking concurrency primitives we use on the project. At the same time, > the project is very inconsistent in its usage of these APIs, so this work > includes a number of improvements to the coherency of the codebase. > This ticket introduces new abstractions and standardises old ones, migrating > all blocking concurrency operations besides Futures returned by Executors to > these new APIs. This includes a migration of SimpleCondition to a new > Conditioninterface, new CountDownLatch and Semaphore interfaces, and new > static factory methods for creating these objects (as well as WaitQueue) that > can be intercepted by byte weaving. Additionally the internal Netty Future > implementation is improved to support more general use (though this is only > fully realised in a later ticket), OpOrder is improved to more easily support > mocking WaitQueue. > Finally we standardise the propagation of InterruptedExecption, with the new > UncheckedInterruptedException, so that simulations may be terminated cleanly. -- 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-16924) Blocking Concurrency Primitives
[ https://issues.apache.org/jira/browse/CASSANDRA-16924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16924: Change Category: Quality Assurance Complexity: Normal Component/s: Legacy/Core Reviewers: Sam Tunnicliffe Assignee: Benedict Elliott Smith Status: Open (was: Triage Needed) > Blocking Concurrency Primitives > --- > > Key: CASSANDRA-16924 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16924 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > To support CEP-10 it is necessary to support alternative implementations of > the blocking concurrency primitives we use on the project. At the same time, > the project is very inconsistent in its usage of these APIs, so this work > includes a number of improvements to the coherency of the codebase. > This ticket introduces new abstractions and standardises old ones, migrating > all blocking concurrency operations besides Futures returned by Executors to > these new APIs. This includes a migration of SimpleCondition to a new > Conditioninterface, new CountDownLatch and Semaphore interfaces, and new > static factory methods for creating these objects (as well as WaitQueue) that > can be intercepted by byte weaving. Additionally the internal Netty Future > implementation is improved to support more general use (though this is only > fully realised in a later ticket), OpOrder is improved to more easily support > mocking WaitQueue. > Finally we standardise the propagation of InterruptedExecption, with the new > UncheckedInterruptedException, so that simulations may be terminated cleanly. -- 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-16923) System Clock
[ https://issues.apache.org/jira/browse/CASSANDRA-16923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16923: Test and Documentation Plan: New and existing dtests, no new functionality Status: Patch Available (was: Open) [16923-trunk|https://github.com/beobal/cassandra/tree/16923-trunk] > System Clock > > > Key: CASSANDRA-16923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16923 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > To support CEP-10 and other project testing goals, it is necessary to support > supplying a non-standard time source that can be externally controlled. This > ticket modifies existing abstractions and migrates all calls to > System.currentTimeMillis() and System.nanoTime() to these APIs. -- 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-16923) System Clock
[ https://issues.apache.org/jira/browse/CASSANDRA-16923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16923: Change Category: Quality Assurance Complexity: Normal Component/s: Legacy/Core Reviewers: Aleksey Yeschenko, Sam Tunnicliffe Assignee: Benedict Elliott Smith Status: Open (was: Triage Needed) > System Clock > > > Key: CASSANDRA-16923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16923 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > To support CEP-10 and other project testing goals, it is necessary to support > supplying a non-standard time source that can be externally controlled. This > ticket modifies existing abstractions and migrates all calls to > System.currentTimeMillis() and System.nanoTime() to these APIs. -- 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-16968) Diff Job retry bug fixes in reading previous run's job parameters & marking the job status
Jyothsna Konisa created CASSANDRA-16968: --- Summary: Diff Job retry bug fixes in reading previous run's job parameters & marking the job status Key: CASSANDRA-16968 URL: https://issues.apache.org/jira/browse/CASSANDRA-16968 Project: Cassandra Issue Type: New Feature Reporter: Jyothsna Konisa Assignee: Jyothsna Konisa Diff job retry with same jobId should avoid running diffs on the partitions that were successfully diffed previously. The retry failed because previous run failed to mark the job as not running on exit. This is due to a bug in the resource try catch block where session object Is closed before marking the job as not running. Also there is another bug in the way we get job parameters during rerun of a failed diff job. -- 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-16967) Probabilistic diff to sample partitions for diff testing based on probability.
Jyothsna Konisa created CASSANDRA-16967: --- Summary: Probabilistic diff to sample partitions for diff testing based on probability. Key: CASSANDRA-16967 URL: https://issues.apache.org/jira/browse/CASSANDRA-16967 Project: Cassandra Issue Type: New Feature Reporter: Jyothsna Konisa Assignee: Jyothsna Konisa Probabilistic diff allows us to sample partitions randomly while running diff tests. It takes new config parameter `partition_sampling_probability ` that ranges between (0-1) and samples partitions based on this probability. The default value for this config property is 1 which means that all the partitions will be diffed. The partitions that are selected are also based on the JobId, for a given sampling probability and JobId we always diff on same partitions.This helps in reproducing any issues that one might run into. Probabilistic diff allows us to run diff jobs on large clusters by sampling some partitions. -- 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-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416839#comment-17416839
]
Ekaterina Dimitrova edited comment on CASSANDRA-16862 at 9/17/21, 6:10 PM:
---
I'll look at it and test. Marking as "NEEDS COMMITTER" in the meantime as we
need second reviewer committer.
was (Author: e.dimitrova):
I'll look at it and test. Marking as "NEEDS COMMITTER" in the meantime as we
need second reviewer.
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {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
[jira] [Updated] (CASSANDRA-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16862:
Status: Needs Committer (was: Review In Progress)
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {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
[jira] [Commented] (CASSANDRA-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416839#comment-17416839
]
Ekaterina Dimitrova commented on CASSANDRA-16862:
-
I'll look at it and test. Marking as "NEEDS COMMITTER" in the meantime as we
need second reviewer.
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {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
[jira] [Updated] (CASSANDRA-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16862:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Status: Review In Progress (was: Patch Available)
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {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
[jira] [Commented] (CASSANDRA-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416808#comment-17416808
]
Blake Eggleston commented on CASSANDRA-12988:
-
I think you'd only need to special case the auto-creation of the cassandra
user, regular auth would use the configured CLs.
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
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-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416804#comment-17416804
]
Josh McKenzie commented on CASSANDRA-12988:
---
{quote}Just re-read the patch and it kept the
auth_read_consistency_level/auth_write_consistency_level settings to pick the
level in the yaml, it seemed like that was not there from the JIRA comments.
That should be fine
{quote}
So correct me if I'm misunderstanding: there's a couple things we're navigating
here.
1: How we treat the {{cassandra}} user (i.e. whether we special case it or not,
and if so, how w/out making our codebase a mess and have the special treatment
of this special user be confusing for new users and not surprising old users by
changing it /sigh ;) )
2: The implications of unifying the CL across Authorizer, RoleManager, and
PasswordAuthenticator and promoting from LOCAL_ONE / ONE to LOCAL_QUORUM (or
demoting from QUORUM to one of those, fun!) and/or EACH_QUORUM based on read
vs. write
Being able to config read/write path in the .yaml to whatever you want and
potentially changing those defaults to QUORUM vs. what's in that PR would
satisfy part of that. The broader question of "is it a good idea to unify these
and what do we do about {{cassandra}}", I'm less clear on our best worst option
here.
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
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-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416793#comment-17416793
]
Jeremiah Jordan edited comment on CASSANDRA-12988 at 9/17/21, 4:38 PM:
---
Yes, keeping QUORUM for that would solve the auto create issue.
-Just thought of another issue. In the wild people will very often set the RF
of the auth key space to be equal to the number of nodes in the DC. I have
seen people set it to 12 or even higher in a single DC. They do this to make
the LOCAL_ONE query able to always be to the current node, lowering the chances
of auth failures from other nodes being slow. Switching to always using
LOCAL_QUORUM will go very badly in these cases.-
-I would suggest we need to be able to keep the LOCAL_ONE query as an option.-
Just re-read the patch and it kept the
auth_read_consistency_level/auth_write_consistency_level settings to pick the
level in the yaml, it seemed like that was not there from the JIRA comments.
That should be fine.
was (Author: jjordan):
Yes, keeping QUORUM for that would solve the auto create issue.
-Just thought of another issue. In the wild people will very often set the RF
of the auth key space to be equal to the number of nodes in the DC. I have
seen people set it to 12 or even higher in a single DC. They do this to make
the LOCAL_ONE query able to always be to the current node, lowering the chances
of auth failures from other nodes being slow. Switching to always using
LOCAL_QUORUM will go very badly in these cases.
I would suggest we need to be able to keep the LOCAL_ONE query as an option.-
Just re-read the patch and it kept the
auth_read_consistency_level/auth_write_consistency_level settings to pick the
level in the yaml, it seemed like that was not there from the JIRA comments.
That should be fine.
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
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-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416793#comment-17416793
]
Jeremiah Jordan edited comment on CASSANDRA-12988 at 9/17/21, 4:38 PM:
---
Yes, keeping QUORUM for that would solve the auto create issue.
-Just thought of another issue. In the wild people will very often set the RF
of the auth key space to be equal to the number of nodes in the DC. I have
seen people set it to 12 or even higher in a single DC. They do this to make
the LOCAL_ONE query able to always be to the current node, lowering the chances
of auth failures from other nodes being slow. Switching to always using
LOCAL_QUORUM will go very badly in these cases.
I would suggest we need to be able to keep the LOCAL_ONE query as an option.-
Just re-read the patch and it kept the
auth_read_consistency_level/auth_write_consistency_level settings to pick the
level in the yaml, it seemed like that was not there from the JIRA comments.
That should be fine.
was (Author: jjordan):
Yes, keeping QUORUM for that would solve the auto create issue.
Just thought of another issue. In the wild people will very often set the RF
of the auth key space to be equal to the number of nodes in the DC. I have
seen people set it to 12 or even higher in a single DC. They do this to make
the LOCAL_ONE query able to always be to the current node, lowering the chances
of auth failures from other nodes being slow. Switching to always using
LOCAL_QUORUM will go very badly in these cases.
I would suggest we need to be able to keep the LOCAL_ONE query as an option.
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
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-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416793#comment-17416793
]
Jeremiah Jordan commented on CASSANDRA-12988:
-
Yes, keeping QUORUM for that would solve the auto create issue.
Just thought of another issue. In the wild people will very often set the RF
of the auth key space to be equal to the number of nodes in the DC. I have
seen people set it to 12 or even higher in a single DC. They do this to make
the LOCAL_ONE query able to always be to the current node, lowering the chances
of auth failures from other nodes being slow. Switching to always using
LOCAL_QUORUM will go very badly in these cases.
I would suggest we need to be able to keep the LOCAL_ONE query as an option.
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
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-13460) Diag. Events: Add local persistency
[ https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416781#comment-17416781 ] Stefan Miklosovic edited comment on CASSANDRA-13460 at 9/17/21, 4:34 PM: - Hi [~mck], I have implemented diagnostic events logging into Chronicle queues in this branch (1), it is quite a big patch and it is not finished yet fully but I think this is enough for the first evaluation and to discuss this earlier to avoid any communication and expectation issues. The main "work" is done in DiagnosticEventService and DiagnosticEventPersistence.. DiagnosticEventPersistence is based on "consumers" which are used for subscription. Implementation-wise, before this patch, there was already a consumer which was putting everything into memory. I implement diagnostic event logger on Chronicle queues in such a way that it is just another consumer but by consuming these events we are putting them into Chronicle queue instead to some in-memory structures. Upon disabling this diagnostic logger, this consumer is just unsubscribed. >From user's point of view, diagnostic events functionality has to be enabled >in order to be able to enable diagnostic logging. Logging into Chronicle >queues is not possible if diagnostic framework is disabled. On the other hand, >diagnostic logging into Chronicle queues might be enabled and disabled on >demand, similarly as it is done for audit. However, regardless of diagnostic >logging into Chronicle queues being enabled or disabled, they are always put >into the memory as it was before. There is a JMX method via which a user may >read these events on demand but they can not be read on demand from arbitrary >position from Chronicle queue if they are written to disk. Hence user can >still inspect these events on the fly from in-memory buffer, as it was before, >but they are all persisted to disk if he choose so. I have also extracted the common parts of BinLogger into separate abstract class and I created org.apache.cassandra.log package where it is located. Audit logging and Diagnostic logging is very similar and I found myself repeating a lot of code all over again in order to implement this so I simplified it a lot. I have also extracted commont stuff for options (audit and diagnostic). Options for audit and diagnostics are extending BinLogOptions and BinLogOptions have its own builder. I wanted to do some simplification in composite data but it seems to be more complicated than I expected so I left it be. I have also implemented diagnosticlogviewer tool, similar to auditlogviewer - my question here is if we want to also make some "generic" tool which would audit and diagnostic viewers extend because right now it is basically the same stuff except few changes which are mostly cosmetic. Hence I would like to know if you think it makes sense to try to extract common parts. I have also implemented nodetool commands for disable, enable diagnostic logging and for its status, similar to audit log. I would love to hear your feedback here, especially about the overall high-level implementation I did here so I am not doing something which is might be eventually rejected because of different expectations. (1) [https://github.com/instaclustr/cassandra/tree/CASSANDRA-13460-2] was (Author: stefan.miklosovic): Hi [~mck], I have implemented diagnostic events logging into Chronicle queues in this branch (1), it is quite a big patch and it is not finished yet fully but I think this is enough for the first evaluation and to discuss this earlier to avoid any communication and expectation issues. The main "work" is done in DiagnosticEventService and DiagnosticEventPersistence.. DiagnosticEventPersistence is based on "consumers" which are used for subscription. Implementation-wise, before this patch, there was already a consumer which was putting everything into memory. I implement diagnostic event logger on Chronicle queues in such a way that it is just another consumer but by consuming these events we are putting them into Chronicle queue instead to some in-memory structures. Upon disabling this diagnostic logger, this consumer is just unsubscribed. >From user's point of view, diagnostic events functionality has to be enabled >in order to be able to enable diagnostic logging. Logging into Chronicle >queues is not possible if diagnostic framework is disabled. On the other hand, >diagnostic logging into Chronicle queues might be enabled and disabled on >demand, similarly as it is done for audit. However, regardless of diagnostic >logging into Chronicle queues being enabled or disabled, they are always put >into the memory as it was before. There is a JMX method via which a user may >read these events on demand but they can not be read on demand from arbitrary >position from Chronicle queue if they are written to
[jira] [Comment Edited] (CASSANDRA-13460) Diag. Events: Add local persistency
[ https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416781#comment-17416781 ] Stefan Miklosovic edited comment on CASSANDRA-13460 at 9/17/21, 4:30 PM: - Hi [~mck], I have implemented diagnostic events logging into Chronicle queues in this branch (1), it is quite a big patch and it is not finished yet fully but I think this is enough for the first evaluation and to discuss this earlier to avoid any communication and expectation issues. The main "work" is done in DiagnosticEventService and DiagnosticEventPersistence.. DiagnosticEventPersistence is based on "consumers" which are used for subscription. Implementation-wise, before this patch, there was already a consumer which was putting everything into memory. I implement diagnostic event logger on Chronicle queues in such a way that it is just another consumer but by consuming these events we are putting them into Chronicle queue instead to some in-memory structures. Upon disabling this diagnostic logger, this consumer is just unsubscribed. >From user's point of view, diagnostic events functionality has to be enabled >in order to be able to enable diagnostic logging. Logging into Chronicle >queues is not possible if diagnostic framework is disabled. On the other hand, >diagnostic logging into Chronicle queues might be enabled and disabled on >demand, similarly as it is done for audit. However, regardless of diagnostic >logging into Chronicle queues being enabled or disabled, they are always put >into the memory as it was before. There is a JMX method via which a user may >read these events on demand but they can not be read on demand from arbitrary >position from Chronicle queue if they are written to disk. Hence user can >still inspect these events on the fly from in-memory buffer, as it was before, >but they are all persisted to disk if he choose so. I have also extracted the common parts of BinLogger into separate abstract class and I created org.apache.cassandra.log package where it is located. Audit logging and Diagnostic logging is very similar and I found myself repeating a lot of code all over again in order to implement this so I simplified it a lot. -I have also extracted commont stuff for options too.- I wanted to do that but it seems to be more complicated than it seems especially in connection with composite data for JMX so I left it be. I have also implemented diagnosticlogviewer tool, similar to auditlogviewer - my question here is if we want to also make some "generic" tool which would audit and diagnostic viewers extend because right now it is basically the same stuff except few changes which are mostly cosmetic. Hence I would like to know if you think it makes sense to try to extract common parts. I have also implemented nodetool commands for disable, enable diagnostic logging and for its status, similar to audit log. I would love to hear your feedback here, especially about the overall high-level implementation I did here so I am not doing something which is might be eventually rejected because of different expectations. (1) [https://github.com/instaclustr/cassandra/tree/CASSANDRA-13460-2] was (Author: stefan.miklosovic): Hi [~mck], I have implemented diagnostic events logging into Chronicle queues in this branch (1), it is quite a big patch and it is not finished yet fully but I think this is enough for the first evaluation and to discuss this earlier to avoid any communication and expectation issues. The main "work" is done in DiagnosticEventService and DiagnosticEventPersistence.. DiagnosticEventPersistence is based on "consumers" which are used for subscription. Implementation-wise, before this patch, there was already a consumer which was putting everything into memory. I implement diagnostic event logger on Chronicle queues in such a way that it is just another consumer but by consuming these events we are putting them into Chronicle queue instead to some in-memory structures. Upon disabling this diagnostic logger, this consumer is just unsubscribed. >From user's point of view, diagnostic events functionality has to be enabled >in order to be able to enable diagnostic logging. Logging into Chronicle >queues is not possible if diagnostic framework is disabled. On the other hand, >diagnostic logging into Chronicle queues might be enabled and disabled on >demand, similarly as it is done for audit. However, regardless of diagnostic >logging into Chronicle queues being enabled or disabled, they are always put >into the memory as it was before. There is a JMX method via which a user may >read these events on demand but they can not be read on demand from arbitrary >position from Chronicle queue if they are written to disk. Hence user can >still inspect these events on the fly from in-memory buffer, as it was before,
[jira] [Comment Edited] (CASSANDRA-13460) Diag. Events: Add local persistency
[ https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416781#comment-17416781 ] Stefan Miklosovic edited comment on CASSANDRA-13460 at 9/17/21, 4:07 PM: - Hi [~mck], I have implemented diagnostic events logging into Chronicle queues in this branch (1), it is quite a big patch and it is not finished yet fully but I think this is enough for the first evaluation and to discuss this earlier to avoid any communication and expectation issues. The main "work" is done in DiagnosticEventService and DiagnosticEventPersistence.. DiagnosticEventPersistence is based on "consumers" which are used for subscription. Implementation-wise, before this patch, there was already a consumer which was putting everything into memory. I implement diagnostic event logger on Chronicle queues in such a way that it is just another consumer but by consuming these events we are putting them into Chronicle queue instead to some in-memory structures. Upon disabling this diagnostic logger, this consumer is just unsubscribed. >From user's point of view, diagnostic events functionality has to be enabled >in order to be able to enable diagnostic logging. Logging into Chronicle >queues is not possible if diagnostic framework is disabled. On the other hand, >diagnostic logging into Chronicle queues might be enabled and disabled on >demand, similarly as it is done for audit. However, regardless of diagnostic >logging into Chronicle queues being enabled or disabled, they are always put >into the memory as it was before. There is a JMX method via which a user may >read these events on demand but they can not be read on demand from arbitrary >position from Chronicle queue if they are written to disk. Hence user can >still inspect these events on the fly from in-memory buffer, as it was before, >but they are all persisted to disk if he choose so. I have also extracted the common parts of BinLogger into separate abstract class and I created org.apache.cassandra.log package where it is located. Audit logging and Diagnostic logging is very similar and I found myself repeating a lot of code all over again in order to implement this so I simplified it a lot. I have also extracted commont stuff for options too. I have also implemented diagnosticlogviewer tool, similar to auditlogviewer - my question here is if we want to also make some "generic" tool which would audit and diagnostic viewers extend because right now it is basically the same stuff except few changes which are mostly cosmetic. Hence I would like to know if you think it makes sense to try to extract common parts. I have also implemented nodetool commands for disable, enable diagnostic logging and for its status, similar to audit log. I would love to hear your feedback here, especially about the overall high-level implementation I did here so I am not doing something which is might be eventually rejected because of different expectations. (1) [https://github.com/instaclustr/cassandra/tree/CASSANDRA-13460-2] was (Author: stefan.miklosovic): Hi [~mck], I have implemented diagnostic events logging into Chronicle queues in this branch (1), it is quite a big patch and it is not finished yet fully but I think this is enough for the first evaluation and to discuss this earlier to avoid any communication and expectation issues. The main "work" is done in DiagnosticEventService and DiagnosticEventPersistence.. DiagnosticEventPersistence is based on "consumers" which are used for subscription. Implementation-wise, before this patch, there was already a consumer which was putting everything into memory. I implement diagnostic event logger on Chronicle queues in such a way that it is just another consumer but by consuming these events we are putting them into Chronicle queue instead to some in-memory structures. Upon disabling this diagnostic logger, this consumer is just unsubscribed. >From user's point of view, diagnostic events functionality has to be enabled >in order to be able to enable diagnostic logging. Logging into Chronicle >queues is not possible if diagnostic framework is disabled. On the other hand, >diagnostic logging into Chronicle queues might be enabled and disabled on >demand, similarly as it is done for audit. However, regardless of diagnostic >logging into Chronicle queues being enabled on disabled, they are always put >into the memory as it was before. There is a JMX method via which a user may >read these events on demand but they can not be read on demand from arbitrary >position from Chronicle queue if they are written to disk. Hence user can >still inspect these events on the fly from in-memory buffer, as it was before, >but they are all persisted to disk if he choose so. I have also extracted the common parts of BinLogger into separate abstract class and I
[jira] [Commented] (CASSANDRA-13460) Diag. Events: Add local persistency
[
https://issues.apache.org/jira/browse/CASSANDRA-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416781#comment-17416781
]
Stefan Miklosovic commented on CASSANDRA-13460:
---
Hi [~mck], I have implemented diagnostic events logging into Chronicle queues
in this branch (1), it is quite a big patch and it is not finished yet fully
but I think this is enough for the first evaluation and to discuss this earlier
to avoid any communication and expectation issues.
The main "work" is done in DiagnosticEventService and
DiagnosticEventPersistence.. DiagnosticEventPersistence is based on "consumers"
which are used for subscription. Implementation-wise, before this patch, there
was already a consumer which was putting everything into memory. I implement
diagnostic event logger on Chronicle queues in such a way that it is just
another consumer but by consuming these events we are putting them into
Chronicle queue instead to some in-memory structures. Upon disabling this
diagnostic logger, this consumer is just unsubscribed.
>From user's point of view, diagnostic events functionality has to be enabled
>in order to be able to enable diagnostic logging. Logging into Chronicle
>queues is not possible if diagnostic framework is disabled. On the other hand,
>diagnostic logging into Chronicle queues might be enabled and disabled on
>demand, similarly as it is done for audit. However, regardless of diagnostic
>logging into Chronicle queues being enabled on disabled, they are always put
>into the memory as it was before. There is a JMX method via which a user may
>read these events on demand but they can not be read on demand from arbitrary
>position from Chronicle queue if they are written to disk. Hence user can
>still inspect these events on the fly from in-memory buffer, as it was before,
>but they are all persisted to disk if he choose so.
I have also extracted the common parts of BinLogger into separate abstract
class and I created org.apache.cassandra.log package where it is located. Audit
logging and Diagnostic logging is very similar and I found myself repeated a
lot of code all over again in order to implement this so I simplified it a lot.
I have also extracted commont stuff for options too.
I have also implemented diagnosticlogviewer tool, similar to auditlogviewer -
my question here is if we want to also make some "generic" tool which would
audit and diagnostic viewers extend because right now it is basically the same
stuff except few changes which are mostly cosmetic. Hence I would like to know
if you think it makes sense to try to extract common parts.
I have also implemented nodetool commands for disable, enable diagnostic
logging and for its status, similar to audit log.
I would love to hear your feedback here, especially about the overall
high-level implementation I did here so I am not doing something which is might
be eventually rejected because of different expectations.
(1) https://github.com/instaclustr/cassandra/tree/CASSANDRA-13460-2
> Diag. Events: Add local persistency
> ---
>
> Key: CASSANDRA-13460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13460
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Observability
>Reporter: Stefan Podkowinski
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 0001-Add-persistency-for-events-to-system-keyspace.patch
>
>
> Some generated events will be rather less frequent but very useful for
> retroactive troubleshooting. E.g. all events related to bootstraping and
> gossip would probably be worth saving, as they might provide valuable
> insights and will consume very little resources in low quantities. Imaging if
> we could e.g. in case of CASSANDRA-13348 just ask the user to -run a tool
> like {{./bin/diagdump BootstrapEvent}} on each host, to get us a detailed log
> of all relevant events- provide a dump of all events as described in the
> [documentation|https://github.com/spodkowinski/cassandra/blob/WIP-13460/doc/source/operating/diag_events.rst].
>
> This could be done by saving events white-listed in cassandra.yaml to a local
> table. Maybe using a TTL.
--
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-16966) Avoid rewriting all sstables during nodetool cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-16966:
Bug Category: Parent values: Degradation(12984)Level 1 values: Slow Use
Case(12996)
Complexity: Low Hanging Fruit
Discovered By: Adhoc Test
Fix Version/s: 4.0.x
Severity: Normal
Status: Open (was: Triage Needed)
> Avoid rewriting all sstables during nodetool cleanup
>
>
> Key: CASSANDRA-16966
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16966
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x
>
>
> {{nodetool cleanup}} does not skip repaired sstables if transient replication
> is disabled
--
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-16966) Avoid rewriting all sstables during nodetool cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-16966:
Test and Documentation Plan: updated jvm dtest + cci run
Status: Patch Available (was: Open)
https://github.com/krummas/cassandra/commits/marcuse/16966
https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F16966
> Avoid rewriting all sstables during nodetool cleanup
>
>
> Key: CASSANDRA-16966
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16966
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x
>
>
> {{nodetool cleanup}} does not skip repaired sstables if transient replication
> is disabled
--
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-16966) Avoid rewriting all sstables during nodetool cleanup
Marcus Eriksson created CASSANDRA-16966:
---
Summary: Avoid rewriting all sstables during nodetool cleanup
Key: CASSANDRA-16966
URL: https://issues.apache.org/jira/browse/CASSANDRA-16966
Project: Cassandra
Issue Type: Bug
Components: Local/SSTable
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
{{nodetool cleanup}} does not skip repaired sstables if transient replication
is disabled
--
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-16965) Avoid returning null in RangesAtEndpoint
[ https://issues.apache.org/jira/browse/CASSANDRA-16965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16965: Test and Documentation Plan: cci run Status: Patch Available (was: Open) https://github.com/krummas/cassandra/commits/marcuse/16965 https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F16965 > Avoid returning null in RangesAtEndpoint > > > Key: CASSANDRA-16965 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16965 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x > > > A race in RangesAtEndpoint can cause us to return null -- 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-16965) Avoid returning null in RangesAtEndpoint
[ https://issues.apache.org/jira/browse/CASSANDRA-16965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16965: Bug Category: Parent values: Degradation(12984)Level 1 values: Other Exception(12998) Complexity: Low Hanging Fruit Discovered By: Adhoc Test Fix Version/s: 4.0.x Severity: Low Status: Open (was: Triage Needed) > Avoid returning null in RangesAtEndpoint > > > Key: CASSANDRA-16965 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16965 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x > > > A race in RangesAtEndpoint can cause us to return null -- 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-16965) Avoid returning null in RangesAtEndpoint
Marcus Eriksson created CASSANDRA-16965: --- Summary: Avoid returning null in RangesAtEndpoint Key: CASSANDRA-16965 URL: https://issues.apache.org/jira/browse/CASSANDRA-16965 Project: Cassandra Issue Type: Bug Components: Local/Other Reporter: Marcus Eriksson Assignee: Marcus Eriksson A race in RangesAtEndpoint can cause us to return null -- 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-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416765#comment-17416765
]
Blake Eggleston commented on CASSANDRA-12988:
-
What if we didn't auto create the cassandra user unless a QUORUM read confirmed
it wasn't there?
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
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-16963) Flaky test: repair_tests/repair_test.py::TestRepair::test_local_dc_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-16963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416762#comment-17416762
]
Caleb Rackliffe commented on CASSANDRA-16963:
-
+1
(I do have a local trunk run of {{repair_tests/repair_test.py}} in flight, but
I assume it'll be fine now. I'll post if it isn't.)
> Flaky test: repair_tests/repair_test.py::TestRepair::test_local_dc_repair
> -
>
> Key: CASSANDRA-16963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16963
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
>
> Sometimes we get “ID mismatch while trying to reprepare” after node restart
> on write workload in dtests, which we can avoid by using fully qualified cf
> names.
--
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-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416761#comment-17416761
]
Jeremiah Jordan commented on CASSANDRA-12988:
-
I have not gone through the implications of this change extensively, but from
past experience with auth bootstrapping and multiple DC's, I do not know
changing away from QUORUM is safe.
Because of the way people bring up new datacenter with bootstrap off, combined
with the way we auto create the "cassandra" users, I do not think it is safe to
stop using QUORUM for that user. A read at LOCAL_QUORUM will not find any
users and the nodes would then "create" the "cassandra" user, possibly over
writing or bringing that user back if it removed.
I hate the fact that the "cassandra" user uses QUORUM as much as the next
person, but until we have a way to create that user which is not "try to do it
automatically during first startup", or we don't have "auto bootstrap:false" as
an option, I think the use of QUORUM is actually needed.
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
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-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416761#comment-17416761
]
Jeremiah Jordan edited comment on CASSANDRA-12988 at 9/17/21, 3:31 PM:
---
I have not gone through the implications of this change extensively, but from
past experience with auth bootstrapping and multiple DC's, I do not know
changing away from QUORUM for the default user is safe.
Because of the way people bring up new datacenter with bootstrap off, combined
with the way we auto create the "cassandra" users, I do not think it is safe to
stop using QUORUM for that user. A read at LOCAL_QUORUM will not find any
users and the nodes would then "create" the "cassandra" user, possibly over
writing or bringing that user back if it removed.
I hate the fact that the "cassandra" user uses QUORUM as much as the next
person, but until we have a way to create that user which is not "try to do it
automatically during first startup", or we don't have "auto bootstrap:false" as
an option, I think the use of QUORUM is actually needed.
was (Author: jjordan):
I have not gone through the implications of this change extensively, but from
past experience with auth bootstrapping and multiple DC's, I do not know
changing away from QUORUM is safe.
Because of the way people bring up new datacenter with bootstrap off, combined
with the way we auto create the "cassandra" users, I do not think it is safe to
stop using QUORUM for that user. A read at LOCAL_QUORUM will not find any
users and the nodes would then "create" the "cassandra" user, possibly over
writing or bringing that user back if it removed.
I hate the fact that the "cassandra" user uses QUORUM as much as the next
person, but until we have a way to create that user which is not "try to do it
automatically during first startup", or we don't have "auto bootstrap:false" as
an option, I think the use of QUORUM is actually needed.
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
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-16896) Add soft/hard limits to local reads to protect against reading too much data in a single query
[ https://issues.apache.org/jira/browse/CASSANDRA-16896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416745#comment-17416745 ] Marcus Eriksson commented on CASSANDRA-16896: - posted review on the PR > Add soft/hard limits to local reads to protect against reading too much data > in a single query > -- > > Key: CASSANDRA-16896 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16896 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Local Write-Read Paths >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 18h 20m > Remaining Estimate: 0h > > Add soft/hard limits to local reads to protect against reading too much data > in a single query. > This is an extension of the existing work to add warnings/aborts to large > partitions (CASSANDRA-16850), with the core difference is that this applies > locally rather than at the coordinator. -- 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-15153) Ensure Caffeine cache does not return stale entries
[ https://issues.apache.org/jira/browse/CASSANDRA-15153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416712#comment-17416712 ] Aleksei Zotov commented on CASSANDRA-15153: --- Great! Thanks [~brandon.williams]! And thanks to [~eperott] for spotting the problem and coming up with the unit test! > Ensure Caffeine cache does not return stale entries > --- > > Key: CASSANDRA-15153 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15153 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Per Otterström >Assignee: Aleksei Zotov >Priority: Normal > Labels: security > Fix For: 4.0.2, 4.1 > > > Version 2.3.5 of the Caffeine cache that we're using in various places can > hand out stale entries in some cases. This seem to happen when an update > fails repeatedly, in which case Caffeine may return a previously loaded > value. For instance, the AuthCache may hand out permissions even though the > reload operation is failing, see CASSANDRA-15041. -- 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-15153) Ensure Caffeine cache does not return stale entries
[ https://issues.apache.org/jira/browse/CASSANDRA-15153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416707#comment-17416707 ] Brandon Williams edited comment on CASSANDRA-15153 at 9/17/21, 2:00 PM: Looks good to me too. Committed just the test to 3.11, the test and 2.5.6 to 4.0 and the test and 2.9.2 to trunk. I broke the test out from the upgrade in separate commits and updated CHANGES where needed. Thanks! was (Author: brandon.williams): Looks good to me too. Committed just the test to 3.11, the test and 2.5.6 to 4.0 and the test and 2.9.2 to trunk. Thanks! > Ensure Caffeine cache does not return stale entries > --- > > Key: CASSANDRA-15153 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15153 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Per Otterström >Assignee: Aleksei Zotov >Priority: Normal > Labels: security > Fix For: 4.0.2, 4.1 > > > Version 2.3.5 of the Caffeine cache that we're using in various places can > hand out stale entries in some cases. This seem to happen when an update > fails repeatedly, in which case Caffeine may return a previously loaded > value. For instance, the AuthCache may hand out permissions even though the > reload operation is failing, see CASSANDRA-15041. -- 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-15153) Ensure Caffeine cache does not return stale entries
[ https://issues.apache.org/jira/browse/CASSANDRA-15153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15153: - Fix Version/s: (was: 4.0.x) (was: 4.x) 4.1 4.0.2 Source Control Link: https://github.com/apache/cassandra/commit/b3af67f0ee950bed75593e0e6ce27547375f4096 Resolution: Fixed Status: Resolved (was: Ready to Commit) Looks good to me too. Committed just the test to 3.11, the test and 2.5.6 to 4.0 and the test and 2.9.2 to trunk. Thanks! > Ensure Caffeine cache does not return stale entries > --- > > Key: CASSANDRA-15153 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15153 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Per Otterström >Assignee: Aleksei Zotov >Priority: Normal > Labels: security > Fix For: 4.0.2, 4.1 > > > Version 2.3.5 of the Caffeine cache that we're using in various places can > hand out stale entries in some cases. This seem to happen when an update > fails repeatedly, in which case Caffeine may return a previously loaded > value. For instance, the AuthCache may hand out permissions even though the > reload operation is failing, see CASSANDRA-15041. -- 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-15153) Ensure Caffeine cache does not return stale entries
[ https://issues.apache.org/jira/browse/CASSANDRA-15153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15153: - Mentor: (was: Benjamin Lerer) Status: Ready to Commit (was: Review In Progress) > Ensure Caffeine cache does not return stale entries > --- > > Key: CASSANDRA-15153 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15153 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Per Otterström >Assignee: Aleksei Zotov >Priority: Normal > Labels: security > Fix For: 4.0.x, 4.x > > > Version 2.3.5 of the Caffeine cache that we're using in various places can > hand out stale entries in some cases. This seem to happen when an update > fails repeatedly, in which case Caffeine may return a previously loaded > value. For instance, the AuthCache may hand out permissions even though the > reload operation is failing, see CASSANDRA-15041. -- 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-15153) Ensure Caffeine cache does not return stale entries
[ https://issues.apache.org/jira/browse/CASSANDRA-15153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15153: - Reviewers: Brandon Williams, Michael Semb Wever, Brandon Williams (was: Brandon Williams, Michael Semb Wever) Brandon Williams, Michael Semb Wever, Brandon Williams (was: Brandon Williams, Michael Semb Wever) Status: Review In Progress (was: Patch Available) > Ensure Caffeine cache does not return stale entries > --- > > Key: CASSANDRA-15153 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15153 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Per Otterström >Assignee: Aleksei Zotov >Priority: Normal > Labels: security > Fix For: 4.0.x, 4.x > > > Version 2.3.5 of the Caffeine cache that we're using in various places can > hand out stale entries in some cases. This seem to happen when an update > fails repeatedly, in which case Caffeine may return a previously loaded > value. For instance, the AuthCache may hand out permissions even though the > reload operation is failing, see CASSANDRA-15041. -- 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] 02/02: Upgrade Caffeiene to 2.9.2
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 7faff3882633f93cbdec12e25fdb5883a912a4a5 Author: Aleksei Zotov AuthorDate: Fri Sep 17 08:51:30 2021 -0500 Upgrade Caffeiene to 2.9.2 Patch by Aleksei Zotov; reviewed by brandonwilliams and mck for CASSANDRA-15153 --- CHANGES.txt | 1 + build.xml | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index 3fb4df5..d72ac0a 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.1 + * Upgrade Caffeine to 2.9.2 (CASSANDRA-15153) * Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it (CASSANDRA-16806) * Include SASI components to snapshots (CASSANDRA-15134) * Fix missed wait latencies in the output of `nodetool tpstats -F` (CASSANDRA-16938) diff --git a/build.xml b/build.xml index bec577a..0398da2 100644 --- a/build.xml +++ b/build.xml @@ -627,7 +627,7 @@ - + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (f7c71f6 -> 7faff38)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from f7c71f6 Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it new b3af67f Add test to ensure Caffeine cache does not return stale entries new fa6dbc4 Merge branch 'cassandra-3.11' into cassandra-4.0 new dd3d83a Upgrade Caffeine to 2.5.6 new 06ee0b3 Merge branch 'cassandra-4.0' into trunk new 7faff38 Upgrade Caffeiene to 2.9.2 The 5 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + build.xml | 2 +- .../org/apache/cassandra/auth/AuthCacheTest.java | 34 ++ 3 files changed, 36 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/02: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 06ee0b3f7b51924dd05f364fef576bb347e195a0 Merge: f7c71f6 dd3d83a Author: Brandon Williams AuthorDate: Fri Sep 17 08:49:01 2021 -0500 Merge branch 'cassandra-4.0' into trunk .../org/apache/cassandra/auth/AuthCacheTest.java | 34 ++ 1 file changed, 34 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (57c1c61 -> dd3d83a)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 57c1c61 Merge branch 'cassandra-3.11' into cassandra-4.0 new b3af67f Add test to ensure Caffeine cache does not return stale entries new fa6dbc4 Merge branch 'cassandra-3.11' into cassandra-4.0 new dd3d83a Upgrade Caffeine to 2.5.6 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + build.xml | 2 +- .../org/apache/cassandra/auth/AuthCacheTest.java | 34 ++ 3 files changed, 36 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/02: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit fa6dbc4dda3897d575a2f56542665e30336be985
Merge: 57c1c61 b3af67f
Author: Brandon Williams
AuthorDate: Fri Sep 17 08:43:48 2021 -0500
Merge branch 'cassandra-3.11' into cassandra-4.0
.../org/apache/cassandra/auth/AuthCacheTest.java | 34 ++
1 file changed, 34 insertions(+)
diff --cc test/unit/org/apache/cassandra/auth/AuthCacheTest.java
index 217821e,c99438f7..da97225
--- a/test/unit/org/apache/cassandra/auth/AuthCacheTest.java
+++ b/test/unit/org/apache/cassandra/auth/AuthCacheTest.java
@@@ -28,9 -27,7 +28,10 @@@ import org.apache.cassandra.db.Consiste
import org.apache.cassandra.exceptions.UnavailableException;
import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertNotNull;
+import static org.junit.Assert.assertNull;
+import static org.junit.Assert.assertTrue;
+ import static org.junit.Assert.fail;
public class AuthCacheTest
{
@@@ -211,6 -166,16 +235,16 @@@
return Integer.parseInt(s);
}
+ private Integer countingLoaderWithException(String s)
+ {
+ Integer loadedValue = countingLoader(s);
+
+ if (loadCounter > 1)
-throw new UnavailableException(ConsistencyLevel.QUORUM, 3, 1);
++throw UnavailableException.create(ConsistencyLevel.QUORUM, 3, 1);
+
+ return loadedValue;
+ }
+
private static class TestCache extends AuthCache
{
private static int nameCounter = 0; // Allow us to create many
instances of cache with same name prefix
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 02/02: Upgrade Caffeine to 2.5.6
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit dd3d83a819f5a513a603b8a9c2c929eff5b2fb81 Author: Aleksei Zotov AuthorDate: Fri Sep 17 08:47:11 2021 -0500 Upgrade Caffeine to 2.5.6 Patch by Aleksei Zotov; reviewed by brandonwilliams and mck for CASSANDRA-15153 --- CHANGES.txt | 1 + build.xml | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index 59d8266..a529423 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0.2 + * Upgrade Caffeine to 2.5.6 (CASSANDRA-15153) * Include SASI components to snapshots (CASSANDRA-15134) * Fix missed wait latencies in the output of `nodetool tpstats -F` (CASSANDRA-16938) * Remove all the state pollution between tests in SSTableReaderTest (CASSANDRA-16888) diff --git a/build.xml b/build.xml index ed66f63..c3f0746 100644 --- a/build.xml +++ b/build.xml @@ -626,7 +626,7 @@ - + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated: Add test to ensure Caffeine cache does not return stale entries
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
new b3af67f Add test to ensure Caffeine cache does not return stale
entries
b3af67f is described below
commit b3af67f0ee950bed75593e0e6ce27547375f4096
Author: Aleksei Zotov
AuthorDate: Sat Sep 11 23:00:53 2021 +0400
Add test to ensure Caffeine cache does not return stale entries
Patch by Aleksei Zotov; reviewed by brandonwilliams and mck for
CASSANDRA-15153
---
.../org/apache/cassandra/auth/AuthCacheTest.java | 34 ++
1 file changed, 34 insertions(+)
diff --git a/test/unit/org/apache/cassandra/auth/AuthCacheTest.java
b/test/unit/org/apache/cassandra/auth/AuthCacheTest.java
index 0030603..c99438f7 100644
--- a/test/unit/org/apache/cassandra/auth/AuthCacheTest.java
+++ b/test/unit/org/apache/cassandra/auth/AuthCacheTest.java
@@ -27,6 +27,7 @@ import org.apache.cassandra.db.ConsistencyLevel;
import org.apache.cassandra.exceptions.UnavailableException;
import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.fail;
public class AuthCacheTest
{
@@ -131,6 +132,29 @@ public class AuthCacheTest
cache.get("expect-exception");
}
+@Test
+public void testCassandraExceptionPassThroughWhenCacheRefreshed() throws
InterruptedException
+{
+setValidity(50);
+TestCache cache = new
TestCache<>(this::countingLoaderWithException, this::setValidity, () ->
validity, () -> isCacheEnabled);
+cache.get("10");
+
+// wait until the cached record expires
+Thread.sleep(60);
+
+for (int i = 1; i <= 5; i++)
+{
+try
+{
+cache.get("10");
+fail("Did not get expected Exception on attempt " + i);
+}
+catch (UnavailableException expected)
+{
+}
+}
+}
+
private void setValidity(int validity)
{
this.validity = validity;
@@ -142,6 +166,16 @@ public class AuthCacheTest
return Integer.parseInt(s);
}
+private Integer countingLoaderWithException(String s)
+{
+Integer loadedValue = countingLoader(s);
+
+if (loadCounter > 1)
+throw new UnavailableException(ConsistencyLevel.QUORUM, 3, 1);
+
+return loadedValue;
+}
+
private static class TestCache extends AuthCache
{
private static int nameCounter = 0; // Allow us to create many
instances of cache with same name prefix
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416703#comment-17416703
]
Ekaterina Dimitrova commented on CASSANDRA-16862:
-
Moved it to Patch available, I will look at it later. Thanks!!
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {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
[jira] [Updated] (CASSANDRA-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16862:
Reviewers: Ekaterina Dimitrova
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {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
[jira] [Updated] (CASSANDRA-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16862:
Test and Documentation Plan:
https://issues.apache.org/jira/browse/CASSANDRA-16862?focusedCommentId=17416550=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17416550
Status: Patch Available (was: In Progress)
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {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
[jira] [Updated] (CASSANDRA-15153) Ensure Caffeine cache does not return stale entries
[ https://issues.apache.org/jira/browse/CASSANDRA-15153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15153: - Reviewers: Brandon Williams, Michael Semb Wever > Ensure Caffeine cache does not return stale entries > --- > > Key: CASSANDRA-15153 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15153 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Per Otterström >Assignee: Aleksei Zotov >Priority: Normal > Labels: security > Fix For: 4.0.x, 4.x > > > Version 2.3.5 of the Caffeine cache that we're using in various places can > hand out stale entries in some cases. This seem to happen when an update > fails repeatedly, in which case Caffeine may return a previously loaded > value. For instance, the AuthCache may hand out permissions even though the > reload operation is failing, see CASSANDRA-15041. -- 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-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416681#comment-17416681
]
Aleksei Zotov commented on CASSANDRA-16806:
---
[~blerer] thank you so much for getting this merged and your support!
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416686#comment-17416686
]
Brandon Williams commented on CASSANDRA-16862:
--
Nice detective work! On the surface this all makes sense to me, but I will
leave review to someone who has experienced this issue.
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {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
[jira] [Updated] (CASSANDRA-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16806:
---
Fix Version/s: (was: 4.x)
4.1
Source Control Link:
https://github.com/apache/cassandra/commit/f7c71f65c000c2c3ef7df1b034b8fdd822a396d8
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Merged into trunk at f7c71f65c000c2c3ef7df1b034b8fdd822a396d8
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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] branch trunk updated: Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
This is an automated email from the ASF dual-hosted git repository. blerer pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new f7c71f6 Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it f7c71f6 is described below commit f7c71f65c000c2c3ef7df1b034b8fdd822a396d8 Author: Aleksei Zotov AuthorDate: Fri Jul 23 21:45:12 2021 +0400 Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it patch by Aleksei Zoto; reviewed by Benjamin Lerer and Chris Lohfink for CASSANDRA-16806 --- CHANGES.txt| 3 +- doc/source/new/virtualtables.rst | 22 +- .../cassandra/cql3/statements/DeleteStatement.java | 4 +- .../cql3/statements/ModificationStatement.java | 1 + .../cql3/statements/TruncateStatement.java | 31 +- .../db/virtual/AbstractMutableVirtualTable.java| 398 ++ .../cassandra/db/virtual/AbstractVirtualTable.java | 8 +- .../apache/cassandra/db/virtual/VirtualTable.java | 7 +- .../cql3/validation/entities/VirtualTableTest.java | 815 ++--- 9 files changed, 1174 insertions(+), 115 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 6b95485..3fb4df5 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.1 + * Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it (CASSANDRA-16806) * Include SASI components to snapshots (CASSANDRA-15134) * Fix missed wait latencies in the output of `nodetool tpstats -F` (CASSANDRA-16938) * Reduce native transport max frame size to 16MB (CASSANDRA-16886) @@ -38,7 +39,7 @@ Merged from 3.0: 4.0.1 * Tolerate missing DNS entry when completing a host replacement (CASSANDRA-16873) - * Harden PrunableArrayQueue against Pruner implementations that might throw exceptions (CASSANDRA-16866) + * Harden PrunableArrayQueue against Pruner implementations that might throw exceptions (CASSANDRA-16866) * Move RepairedDataInfo to the execution controller rather than the ReadCommand to avoid unintended sharing (CASSANDRA-16721) * Bump zstd-jni version to 1.5.0-4 (CASSANDRA-16884) * Remove assumption that all urgent messages are small (CASSANDRA-16877) diff --git a/doc/source/new/virtualtables.rst b/doc/source/new/virtualtables.rst index 1c8766c..0cb988f 100644 --- a/doc/source/new/virtualtables.rst +++ b/doc/source/new/virtualtables.rst @@ -38,15 +38,15 @@ How are Virtual Tables different from regular tables? Virtual tables and virtual keyspaces are quite different from regular tables and keyspaces respectively such as: -- Virtual tables are read-only, but it is likely to change +- Virtual tables support modifications only if the underlaying implementation allows it - Virtual tables are not replicated - Virtual tables are local only and non distributed - Virtual tables have no associated SSTables - Consistency level of the queries sent virtual tables are ignored -- Virtual tables are managed by Cassandra and a user cannot run DDL to create new virtual tables or DML to modify existing virtual tables +- Virtual tables are managed by Cassandra and a user cannot run DDL to create new virtual tables to modify existing virtual tables - Virtual tables are created in special keyspaces and not just any keyspace -- All existing virtual tables use ``LocalPartitioner``. Since a virtual table is not replicated the partitioner sorts in order of partition keys instead of by their hash. -- Making advanced queries with ``ALLOW FILTERING`` and aggregation functions may be used with virtual tables even though in normal tables we don't recommend it +- All existing virtual tables use ``LocalPartitioner``. Since a virtual table is not replicated the partitioner sorts in order of partition keys instead of by their hash. +- Making advanced queries with ``ALLOW FILTERING`` and aggregation functions may be used with virtual tables even though in normal tables we don't recommend it Virtual Keyspaces ^ @@ -66,21 +66,21 @@ Virtual Table Limitations Virtual tables and virtual keyspaces have some limitations initially though some of these could change such as: -- Cannot alter or drop virtual keyspaces or tables -- Cannot truncate virtual tables - Expiring columns are not supported by virtual tables +- Custom timestamps are not supported by virtual tables - Conditional updates are not supported by virtual tables -- Cannot create tables in virtual keyspaces -- Cannot perform any operations against virtual keyspace - Secondary indexes are not supported on virtual tables -- Cannot create functions in virtual keyspaces -- Cannot create types in virtual keyspaces - Materialized views are not supported on virtual tables -- Virtual tables don't support ``DELETE`` statements +- Virtual tables support
[jira] [Commented] (CASSANDRA-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416667#comment-17416667
]
Benjamin Lerer commented on CASSANDRA-16806:
Thanks [~azotcsit].
CI looks good
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/210/workflows/627e4a13-e083-47b1-95c7-c238e7fb060d],
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/210/workflows/9121931b-3c34-4de1-a6e7-c585ea08223c].
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16806:
---
Status: Ready to Commit (was: Review In Progress)
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-16674) Allow -os to be used with force repair
[
https://issues.apache.org/jira/browse/CASSANDRA-16674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416647#comment-17416647
]
Aleksei Zotov commented on CASSANDRA-16674:
---
The change looks good to me, however, it would be great to introduce a
corresponding test.
> Allow -os to be used with force repair
> --
>
> Key: CASSANDRA-16674
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16674
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> We should allow using {{-os}} (optimise repair streams, CASSANDRA-3200) with
> forced repairs
--
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-14385) Fix Some Potential NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-14385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-14385:
--
Status: Open (was: Patch Available)
> Fix Some Potential NPE
> ---
>
> Key: CASSANDRA-14385
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14385
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: lujie
>Priority: Normal
> Attachments: CA-14385_1.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have developed a static analysis tool
> [NPEDetector|https://github.com/lujiefsi/NPEDetector] to find some potential
> NPE. Our analysis shows that some callees may return null in corner case(e.g.
> node crash , IO exception), some of their callers have _!=null_ check but
> some do not have. In this issue we post a patch which can add !=null based
> on existed !=null check. For example:
> Calle Schema#getView may return null:
> {code:java}
> public ViewMetadata getView(String keyspaceName, String viewName)
> {
> assert keyspaceName != null;
> KeyspaceMetadata ksm = keyspaces.getNullable(keyspaceName);
> return (ksm == null) ? null : ksm.views.getNullable(viewName);//may
> return null
> }
> {code}
> it have 4 callers, 3 of them have !=null check, like its caller
> MigrationManager#announceViewDrop have !=null check()
> {code:java}
> public static void announceViewDrop(String ksName, String viewName, boolean
> announceLocally) throws ConfigurationException
> {
>ViewMetadata view = Schema.instance.getView(ksName, viewName);
> if (view == null)//null pointer checker
> throw new ConfigurationException(String.format("Cannot drop non
> existing materialized view '%s' in keyspace '%s'.", viewName, ksName));
>KeyspaceMetadata ksm = Schema.instance.getKeyspaceMetadata(ksName);
>logger.info("Drop table '{}/{}'", view.keyspace, view.name);
>announce(SchemaKeyspace.makeDropViewMutation(ksm, view,
> FBUtilities.timestampMicros()), announceLocally);
> }
> {code}
> but caller MigrationManager#announceMigration does not have
> We add !=null check based on MigrationManager#announceViewDrop:
> {code:java}
> if (current == null)
> throw new InvalidRequestException("There is no materialized view in
> keyspace " + keyspace());
> {code}
> But due to we are not very familiar with CASSANDRA, hope some expert can
> review it.
> Thanks
>
--
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-14385) Fix Some Potential NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-14385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416641#comment-17416641
]
Aleksei Zotov commented on CASSANDRA-14385:
---
Hi [~xiaoheipangzi]!
I'm sorry that you got no reply for a long time! There was harsh time related
to 4.0 release. But currently the community is trying to check the tickets that
were left without proper attention.
There is a conflict, so your PR needs to be updated with the recent changes.
Also I skimmed trough your changes and put a couple of comments. Please, let us
know whether you still feel the ticket is actual and you want to continue the
work.
I will move the ticket back to {{Open}} feel free to move it back to {{Patch
Available}} after rebase.
Thanks for your work and welcome to the community!
PS:
I'm not a project committer, I'm just an enthusiast like you who is hanging
around the project.
cc: [~blerer]
> Fix Some Potential NPE
> ---
>
> Key: CASSANDRA-14385
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14385
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: lujie
>Priority: Normal
> Attachments: CA-14385_1.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have developed a static analysis tool
> [NPEDetector|https://github.com/lujiefsi/NPEDetector] to find some potential
> NPE. Our analysis shows that some callees may return null in corner case(e.g.
> node crash , IO exception), some of their callers have _!=null_ check but
> some do not have. In this issue we post a patch which can add !=null based
> on existed !=null check. For example:
> Calle Schema#getView may return null:
> {code:java}
> public ViewMetadata getView(String keyspaceName, String viewName)
> {
> assert keyspaceName != null;
> KeyspaceMetadata ksm = keyspaces.getNullable(keyspaceName);
> return (ksm == null) ? null : ksm.views.getNullable(viewName);//may
> return null
> }
> {code}
> it have 4 callers, 3 of them have !=null check, like its caller
> MigrationManager#announceViewDrop have !=null check()
> {code:java}
> public static void announceViewDrop(String ksName, String viewName, boolean
> announceLocally) throws ConfigurationException
> {
>ViewMetadata view = Schema.instance.getView(ksName, viewName);
> if (view == null)//null pointer checker
> throw new ConfigurationException(String.format("Cannot drop non
> existing materialized view '%s' in keyspace '%s'.", viewName, ksName));
>KeyspaceMetadata ksm = Schema.instance.getKeyspaceMetadata(ksName);
>logger.info("Drop table '{}/{}'", view.keyspace, view.name);
>announce(SchemaKeyspace.makeDropViewMutation(ksm, view,
> FBUtilities.timestampMicros()), announceLocally);
> }
> {code}
> but caller MigrationManager#announceMigration does not have
> We add !=null check based on MigrationManager#announceViewDrop:
> {code:java}
> if (current == null)
> throw new InvalidRequestException("There is no materialized view in
> keyspace " + keyspace());
> {code}
> But due to we are not very familiar with CASSANDRA, hope some expert can
> review it.
> Thanks
>
--
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-16960) Improve MV TTL error message
[
https://issues.apache.org/jira/browse/CASSANDRA-16960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416631#comment-17416631
]
Aleksei Zotov commented on CASSANDRA-16960:
---
+1 (non-binding)
> Improve MV TTL error message
>
>
> Key: CASSANDRA-16960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16960
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> Old MVs could have been created with a {{default_time_to_live}} before the
> time of CASSANDRA-12868.
> A few years forward customers altering that MV for other reasons might get a
> very confusing message which can benefit from some clarification.
> {code}
> ALTER MATERIALIZED VIEW X_view WITH gc_grace_seconds = 10800;
> Cannot set or alter default_time_to_live for a materialized view. Data in a
> materialized view always expire at the same time than the corresponding data
> in the parent table.
> {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
